Second W3C Web Authentication (WebAuthn) Candidate Recommendation (CR)

W3C logoW3C has published a second W3C Candidate Recommendation (CR) for the Web Authentication (WebAuthn) specification. The second Candidate Recommendation is at https://www.w3.org/TR/2018/CR-webauthn-20180807/.

This draft contains a few refinements since the first candidate recommendation but no substantial changes. The new CR was needed to fulfill the W3C’s IPR protection requirements. The few changes were based, in part, upon things learned during multiple interop events for WebAuthn implementations. The working group plans to base coming the Proposed Recommendation on this draft.

IETF Token Binding specifications sent to the RFC Editor

IETF logoThe three core IETF Token Binding Specifications have been sent to the RFC Editor, which means that their normative content will no longer change. It’s time to move implementations to version 1.0! The abstract of the Token Binding over HTTP specification describes Token Binding as:

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated token bindings, on the other hand, allow Continue reading "IETF Token Binding specifications sent to the RFC Editor"

Deprecating the Password: A Progress Report

EIC logoI gave the well-received presentation “Deprecating the Password: A Progress Report” at the May 2018 European Identity and Cloud Conference (EIC). The presentation is available as PowerPoint (large because of the embedded video) and PDF.

The presentation abstract is:

If you ask almost anyone you meet if they have too many passwords, if they have trouble remembering their passwords, or if they are reusing the same passwords in multiple places, you’re likely to get an ear-full. People intuitively know that there has to be something better than having to have a password for everything they do!

The good news is that passwords are being used for fewer and fewer identity interactions. They are being replaced by biometrics (sign into your phone, your PC, or your bank with your face or fingerprint), local PINs (prove it’s you to your device and it does the rest), and federation (sign in with Facebook,

Mike presenting at EIC 2018
Continue reading "Deprecating the Password: A Progress Report"

On our journey to deprecate the password: Public Implementation Draft of FIDO2 Client to Authenticator Protocol (CTAP) specification

FIDO logoI’m pleased to report that a public Implementation Draft of the FIDO2 Client to Authenticator Protocol (CTAP) specification has been published. This specification enables FIDO2 clients, such as browsers implementing the W3C Web Authentication (WebAuthn) specification, to perform authentication using pairwise public/private key pairs securely held by authenticators speaking the CTAP protocol (rather than passwords). Use of three transports for communicating with authenticators is specified in the CTAP specification: USB Human Interface Device (USB HID), Near Field Communication (NFC), and Bluetooth Smart/Bluetooth Low Energy Technology (BLE).

This specification was developed in parallel with WebAuthn, including having a number of common authors. This CTAP version is aligned with the WebAuthn Candidate Recommendation (CR) version.

The CTAP Implementation Draft is available at:

Congratulations to the members of the FIDO2 working group for reaching this important milestone. This is a major step in our journey to deprecate the password!

W3C Web Authentication (WebAuthn) specification has achieved Candidate Recommendation (CR) status

W3C logoThe W3C Web Authentication (WebAuthn) specification is now a W3C Candidate Recommendation (CR). See the specification at https://www.w3.org/TR/2018/CR-webauthn-20180320/ and my blog post announcing this result for the WebAuthn working group at https://www.w3.org/blog/webauthn/2018/03/20/candidate-recommendation/.

This milestone represents a huge step towards enabling logins to occur using privacy-preserving public/private key pairs securely held by authenticators, rather than passwords. Its contents have been informed by what we learned during several rounds of interop testing by multiple browser and authenticator vendors. The Web Authentication spec has also progressed in parallel with and been kept in sync with the FIDO2 Client To Authenticator Protocol (CTAP) specification, so that they work well together.

W3C Web Authentication (WebAuthn) specification almost a Candidate Recommendation (CR)

W3C logoThe eighth working draft of the W3C Web Authentication (WebAuthn) specification has been published. The WebAuthn working group plans to submit this draft for approval by the W3C Director (Tim Berners-Lee) to become a W3C Candidate Recommendation (CR), after a few days’ review by the working group.

This milestone represents a huge step towards enabling logins to occur using public/private key pairs securely held by authenticators, rather than passwords. Its contents have been informed by what we learned during several rounds of interop testing by multiple browser and authenticator vendors. The Web Authentication spec has also progressed in parallel with and been kept in sync with the FIDO 2 Client To Authenticator Protocol (CTAP) specification, so that they work well together.

Strong Authentication and Token Binding Presentations at EIC 2017

EIC logoI gave two presentations at the 2017 European Identity and Cloud Conference (EIC) on progress we’re making in creating and deploying important new identity and security standards. The presentations were:
  • Strong Authentication using Asymmetric Keys on Devices Controlled by You: This presentation is about the new authentication experiences enabled by the W3C Web Authentication (WebAuthn) and FIDO 2.0 Client To Authenticator Protocol (CTAP) specifications. It describes the progress being made on the standards and shows some example user experiences logging in using authenticators. Check it out in PowerPoint or PDF.
  • Token Binding Standards and Applications: Securing what were previously bearer tokens: This presentation is about how data structures such as browser cookies, ID Tokens, and access tokens can be cryptographically bound to the TLS channels on which they are transported, making them no longer bearer tokens. It describes the state of the Token Binding standards (IETF
    Mike presenting at EIC 2017
    Continue reading "Strong Authentication and Token Binding Presentations at EIC 2017"

Initial OpenID Connect Enhanced Authentication Profile (EAP) Specifications Published

The OpenID Enhanced Authentication Profile (EAP) working group was created to enable use of the IETF Token Binding specifications with OpenID Connect and to enable integration with FIDO relying parties and/or other strong authentication technologies. The OpenID Foundation has now published the initial EAP specifications as a first step towards accomplishing these goals. See the announcement on openid.net.

OpenID Connect EAP ACR Values specification

OpenID logoThe OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been submitted to the OpenID Enhanced Authentication Profile (EAP) working group. Per the abstract:
This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators.

The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together. The specification is available at:

An update on our war against account hijackers

I recommend reading Google’s post An update on our war against account hijackers. It describes the kinds of measures taken by professionally-run Identity Providers to defend against account takeover.

A message not stated but implied is that consumers and Web sites are far better off depending upon identities provided by organizations with the resources and dedication to successfully fight takeover attempts. Sites with their own username/password login systems without these defenses are vulnerable, and would be better off using federated identities from professionally-run Identity Providers.

An Experimental Identity Selector for OpenID

OpenID logoThe OpenID community has been talking about the value that an optional active client could bring to OpenID for well over a year. To concretely explore this possibility, as many of you know by now, a team at Microsoft built a prototype multi-protocol identity selector supporting OpenID, starting with CardSpace 2, which I and others demonstrated at the OpenID Summit and the Internet Identity Workshop. We did this to stimulate discussion and engage the community about the value of adding active client support to OpenID. And I’ll say up front that enormous thanks go to Joseph Smarr at Plaxo, the team at JanRain, and Andrew Arnott for building demonstration relying parties that worked with the prototype, which made the demonstrations possible.

While you may have read about it on Kim’s blog and many of you were there in person, I wanted to capture screen shots from the demos to make them available, so those who weren’t there can join the discussion as well. Plus, I’ve posted the presentation that accompanied the demos, rather than reproducing that content here. Now, on to the demo, which closely follows the one actually given at the Summit…

 


Using a selector for the first time

I start by demonstrating the user experience for a first-time selector user at a a selector-enabled OpenID relying party.

 

Plaxo signin
The first screen shot shows a standard Plaxo login screen, but augmented behind the covers to enable it to pass its OpenID authentication request parameters to an active client, if present. I will click on the “Sign in with OpenID” button on the Plaxo signin page, invoking the selector.

In the prototype, selector-enabled relying parties use a variant of the Information Card object tag to communicate their request parameters to the selector. The object tag parameters used on Plaxo’s RP page are:
<object type="application/x-informationCard" id=infoCardObjectTag>
<param name=protocol value="http://specs.openid.net/auth/2.0"/>
<param name=tokenType value="http://specs.openid.net/auth/2.0"/>
<param name=issuer value="Google.com/accounts/o8/id Yahoo.com myOpenID.com"/>
<param name=issuerExclusive value=false/>
<param name=OpenIDAuthParameters value=
"openid.ns:http://specs.openid.net/auth/2.0
openid.return_to:http://www.plaxo.com/openid?actionType=complete
openid.realm:http://*.plaxo.com/
openid.ns.sreg:http://openid.net/extensions/sreg/1.1
openid.sreg.required:email
openid.sreg.optional:fullname,nickname,dob,gender,postcode,country,language,timezone
openid.sreg.policy_url:http://www.plaxo.com/about/privacy_policy
"/>
</object>

 

Plaxo empty selector
Here I’ve clicked on the “Sign in with OpenID” button, invoking the selector. (The “Google” and “Yahoo” buttons would have invoked the selector too.) This shows the first-time selector user experience, where it isn’t yet remembering any OpenIDs for me. The three OPs suggested by Plaxo – Google, Yahoo, and MyOpenID, are shown, as well as the option to type in a different OpenID. I click on the Yahoo suggestion.

 

Plaxo Yahoo first time
Clicking on Plaxo’s Yahoo suggestion resulted in a Yahoo OpenID card being made available for use. Note that, by default, the selector will remember this card for me. (Those of you who know OpenID well are probably thinking “Where did the selector get the Yahoo logo and friendly name string”? For this prototype, they are baked into the selector. Longer term, the right way is for the selector to retrieve these from the OP’s discovery document. The OpenID UX working group is considering defining discovery syntax for doing just that.)

Once I’ve clicked “OK” to select the identity to use, the selector (not the RP) redirects the browser to the OP – in this case, to the Yahoo login page. The selector’s work is done at this point. The remainder of the protocol flow is standard OpenID 2.0.

 

Yahoo Plaxo signin
This is the standard Yahoo OpenID signin page, which the selector redirected the browser to after I choose to use the suggested Yahoo OpenID. I sign into Yahoo.

 

Yahoo Plaxo permission
The signin page is followed by the standard Yahoo permissions page. I click “Agree”.

 

Plaxo signed in
After logging with Yahoo, I’m redirected back to Plaxo. Because I’d previously associated my Yahoo OpenID with my Plaxo account, I’m now logged into Plaxo. My status “Michael is demonstrating an OpenID selector at the OpenID Summit”, which I updated live during the demo at the OpenID Summit, is shown.

 


Selector defaults to the OpenID last used at the site

At this point in the demo, I’ve signed out of Plaxo and returned to the selector-enabled sign-in page. After clicking “Sign in with OpenID” again, the selector reappears.

Plaxo Yahoo second time
This time, the selector has remembered the OpenID I last used at the site and tells me when I last used it there. (This is one of the ways that a selector can help protect people from phishing.) By default, the OpenID last used at a relying party is automatically selected – in this case, Yahoo. I click “OK” to select it, with the rest of the flow again being the standard OpenID 2.0 flow.

 


Experience at a new RP plus a trusted OP experience

Interscope homepage
JanRain selector-enabled several production sites, including interscope.com, uservoice.com, and pibb.com, which use JanRain’s hosted RPX service. This could be done with no impact on users without a selector by using JavaScript to detect whether a selector is present or not, and customizing the page accordingly. The page above is the production Interscope Records page. I click the OpenID button on the right under the “Join The Community” banner.

 

Interscope signon
The OpenID button invokes the RPX “NASCAR” experience. (Arguably, this page could be omitted from the experience if a selector is detected.) I click the OpenID button on the “NASCAR” page.

 

Interscope Yahoo never used here
The selector is invoked by Interscope (really, by RPX) to let me choose an OpenID. My Yahoo OpenID is shown and the “Never used here” tells me that I haven’t used it at this site before. I could choose it by clicking OK or hitting Enter. Instead, I click the “Other OpenIDs” button to explore other options.

 

Interscope other OpenIDs
The “Other OpenIDs” tile shows me the OpenID providers suggested by Interscope – in this case, Flickr, Yahoo, and Google. I click on the Google suggestion.

 

Interscope Google first time
The selector has created a Google OpenID card for me to use. It is marked “Verified” because it (like Yahoo) was on a whitelist in the selector and considered “safe” to use. Of course, in production use, such a whitelist would have to be maintained by a neutral third party or parties and dynamically updated. In the prototype, we hard-coded a few common providers so we could show a user experience that relies on a whitelist of OPs, to start the discussion about that possibility. I hit Enter to use the new Google card at Interscope.

 

Google UniversalMusic signin
Once I chose to use my Google card, the selector redirected me to Google’s signin page, with the actual RP for Interscope being signup.universalmusic.com. I sign into Google.

 

Google UniversalMusic permission
Following signin, Google asks me permission to release information to signup.universalmusic.com. I allow it.

 

Interscope registration
I’m redirected back to Interscope, which asked me to complete a sign-up process by supplying more information via a web form.

 


Selector remembering which OpenID’s you’ve used where

Interscope Google second time
When visiting Interscope again after having signed out, signing in with OpenID shows me that I last used my Google OpenID here. For that reason, it’s selected as the default. I can also see that I haven’t used my Yahoo OpenID here.

 


Trusted versus untrusted OpenIDs

test-id signin
Andrew Arnott created the first selector-enabled relying party site for us, which is shown above. I click “Log in using your OpenID Selector”.

 

test-id Google never used here
Now I have both Yahoo and Google cards, but neither have been used at test-id.org. I notice that I can get more details about my cards, and click “More details” on the Google card.

 

test-id Google more details
“More details” tells me where and when I used the card (signup.universalmusic.com), the discovered OpenID endpoint, and that this OpenID was on the selector’s whitelist. I could now use either of these OpenIDs, but I select “Other OpenIDs” instead.

 

test-id other OpenIDs
The “Other OpenIDs” panel shows me OPs suggested by the site, as well as a dialog box to enter another OpenID. I decide to enter my blog URL self-issued.info, which is also an OpenID.

 

test-id self-issued being entered
Here I’m entering my blog URL self-issued.info into the selector. I then click Verify or OK to have the selector perform discovery on the OpenID to add it as one of my choices.

 

test-id self-issued not verified
Discovery has succeeded, but the OP my blog is delegated to, signon.com, is not on the selector’s whitelist. Because it’s not, a warning shield is shown, rather than the OP logo. I’ll also have to make an explicit decision to trust this OpenID provider before the selector will let me use it. The same would have happened if I chose an OP suggested by the RP if the OP was not on the whitelist. This is another aspect of the selector’s phishing protection. I check the “Continue, I trust this provider” box.

 

test-id self-issued trusted
After checking the “Continue, I trust this provider” box, the warning shield is replaced by either the OP logo, if it can be discovered, or a generic OpenID logo, as in this case. I click OK to use this OpenID.

 

signon test-id signin
The selector follows my delegation link from self-issued.info and redirects me to signon.com. (Ping, are you going to fix the signon.com UX issue above someday?) I sign into signon.com.

 

test-id signed in
Having signed into my OpenID at signon.com, I’m redirected back to the test site, which received an authentication response from the OP. I click “Reset test” to sign out, in preparation for another test.

 


More details

test-id self-issued second time
Upon a second visit to test-id.org, the selector has remembered that I last used the OpenID self-issued.info, which is actually delegated to mbj.signon.com. I click “More details” to learn more about this OpenID.

 

test-id self-issued more details
“More details” tells me where and when I last used the OpenID and that the OpenID has been verified. But unlike my Google OpenID, which was verified via the whitelist, I told the selector to trust this OpenID myself.

 


Delegation to a trusted OP

test-id davidrecordon being entered
At the OpenID Summit, people wanted to see the untrusted user experience again, so I entered an OpenID that I was sure wasn’t on our built-in whitelist – davidrecordon.com. However, verifying the OpenID actually brought me and those in attendance a surprise…

 

test-id davidrecordon verified
Because davidrecordon.com is delegated to myopenid.com, which is on the whitelist, it turns out that the prototype considered davidrecordon.com to be trusted as well. Upon reflection, this is probably the right behavior, but I’d never seen it until giving the demo live. (Great job, Oren!) I tried factoryjoe.com next and got the same result. Finally Will Norris helped me out by saying that willnorris.com isn’t delegated, so we got to see the untrusted user experience again.

 


Conclusion

I’d like to thank Chuck Reeves and Oren Melzer for quickly building a killer prototype and to thank Ariel Gordon and Arun Nanda for helping design it, as well as others, both from Microsoft and other companies, who provided feedback that helped us fine-tune it as we built it. See the presentation for a much more comprehensive list of thank-yous.

I’ll close by saying that in the OpenID v.Next planning meeting at IIW, there was an unopposed consensus that optional active client support should be included as a feature of v.Next. Hopefully our demo, as well as those by others, including Markus Sabadello of Higgins, helped the community decide that this is a good idea by enabling people to concretely experience the benefits that an active client can bring to OpenID. If so, I’d call the experiment a success!