I’ve posted the OpenID Connect presentation that I gave at the OpenID Workshop at IETF 87. Besides giving an overview of the specification status, unsurprisingly given the setting at IETF 87, it also talks about the relationship between OpenID Connect and the IETF specifications that it depends upon. It’s available as PowerPoint and PDF.
Archive for the 'Events' Category
I’ve posted the OpenID Connect Update presentation that I gave today during the OpenID Workshop at the Cloud Identity Summit 2013. I’ve trimmed down the presentation to be lighter on the “how” and focus more on the “what” and “why”, relative to the one I gave at EIC in May. It’s available in PowerPoint and PDF formats.
I’m pleased to report that OAuth 2.0 has won the 2013 European Identity Award for Best Innovation/New Standard. I was honored to accept the award from Kuppinger Cole at the 2013 European Identity and Cloud Conference on behalf of all who contributed to creating the OAuth 2.0 standards [RFC 6749, RFC 6750] and who are building solutions with them.
A fourth set of release candidates for the upcoming OpenID Connect Implementer’s Drafts has been released. Changes since the third release candidates mostly consist of editorial improvements. There were only two changes that will result in changes to implementations. The first was replacing the “updated_time” claim, which used a textual date format, with the “updated_at” claim, which uses the same numeric representation as the other OpenID Connect date/time claims. The second was replacing the “PKIX” JWK key type with the “x5c” JWK key member (a change actually made this week by the JOSE working group).
These are ready for discussion at Monday’s in-person OpenID Connect working group meeting. All issues filed have been addressed.
The updated specifications are:
These specifications did not change:
Thanks to all who continued reviewing and implementing the specifications, resulting in the improvements contained in this release. I’ll look forward to seeing many of you on Monday!
Last week at the Japan Identity and Cloud Symposium I gave a presentation on this topic: A new set of simple, open identity protocols is emerging that utilize JSON data representations and REST-based communication patterns, including OAuth, JSON Web Token (JWT), JSON Object Signing and Encryption (JOSE), and WebFinger. I’ve posted PowerPoint and PDF versions of the presentation.
Thanks again to the organizers of JICS 2013 for a great event!
In preparation for discussions at the JOSE working group meeting at IETF 84 in Vancouver, BC, I did some investigation into the state of support for the JWA algorithms in common Web development platforms. This table contains the data gathered. It was also discussed at the July 2012 W3C WebCrypto F2F Meeting. I’m posting it now because I’d recently received a request for it and because it may be useful at the upcoming WebCrypto meeting at TPAC in Lyon and at IETF 85 in Atlanta.
Thanks to Roland Hedberg, Axel Nennker, Emmanuel Raviart, Nov Matake, Justin Richer, Edmund Jay, Wan-Teh Chang, Christopher Kula, and Ryan Sleevi for the data they provided. If you have more data that I should add, or believe that there are additional columns or rows we should track, please let me know.
I’m thrilled to report that OpenID Connect has won the 2012 European Identity Award for Best Innovation/New Standard. I appreciate the recognition of what we’ve achieved to date with OpenID Connect and its potential to significantly change digital identity for the better. As Dave Kearns wrote in the OpenID Foundation announcement about the award:
I’m pleased that Kuppinger Cole has granted OpenID Connect the award for Best Innovation/New Standard this year. What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices. My congratulations to the OpenID Foundation!
My thanks to all who have contributed to the OpenID Connect specifications to date and especially to the developers who have implemented draft versions, providing essential feedback needed to refine the specs on the road to final standards. I look forward to seeing what people will accomplish with OpenID Connect!
The Third OpenID Connect Interop is currently under way – this time based upon approved Implementer’s Drafts. Currently 7 implementations are being tested, with I believe more to be added. The interop is designed to enable people to test the implementations they’ve built against other implementations and verify that specific features that they’ve built are working correctly. This has several benefits: it helps debug implementations, it helps debug the specifications, and it results in greater interoperability among OpenID Connect implementations.
As background, like the other OSIS interops, the OpenID Connect interop is an opportunity for implementers to try their code against one another’s in a systematic way. It is not a conformance test; participants do not “pass” or “fail”. There is no requirement that you must support particular features to participate or that you must participate in all aspects of the interop.
If you’d like to participate in the interop, join the OpenID Connect Interop mailing list and send us a note there saying who your interop contact person will be, the name of your organization (can be an individual), the name of your implementation (can be your name), and a list of the online testing endpoints for your implementation. Testing is performed online on your schedule, with results recorded on the interop wiki. That being said, an in-person meeting of interop participants will also be held on Friday, March 2 in San Francisco (the week of RSA) for those who are able to attend.
A new set of open identity protocols is emerging that utilizes JSON data representations and simple REST-based communication patterns. These protocols and data formats are intentionally designed to be easy to use in browsers and modern web development environments.
I hope you’ll find it worthwhile reading. I’m looking forward to discussing it with many of you at the workshop!
A European OpenID summit will be held in London on Tuesday, June 8th at the Microsoft Offices at Cardinal Place, 100 Victoria Street, London SW1E 5JL, UK. This is the same location as the European e-Identity Management Conference, which follows it June 9th and 10th. Topics are expected to include: use cases, issues and problems encountered, solutions proposed, the OpenID v.Next effort, and EU trust profile topics.
Register at http://openid-eu-summit-2010.eventbrite.com/. If you’re interested in presenting, please include your proposed topic in your registration.
The OpenID v.Next session at IIW run by David Recordon and Dick Hardt reached some important conclusions about the future of OpenID. The motivation for the v.Next discussion was the sense that we’ve learned enough since the OpenID 2.0 specification was finalized that it’s time to revise the spec to incorporate what we’ve learned. This session attempted to reach a consensus on the priorities for the next version of OpenID, with a large number of the important players participating. I haven’t seen the decisions made published elsewhere, so I’m recording them here.
David organized the session around a stated goal of producing an evolved OpenID specification within the next six months. The consensus goals reached were as follows. The numbers represent the number of participants who said that they would work on that feature in the next six months.
- Integrating the UX extension (in which the user interacts with the OP in a pop-up window) into the core specification: 12
- Evolving the discovery specification for OpenID, including adding OpenIDs using e-mail address syntax: 10
- Integrating attributes (claims) into the core specification: 9
- Integrating the OAuth Hybrid specification into the core specification: 8
- Supporting an optional active client (identity selector) and non-browser applications: 8
- Improve security, including investigating enabling use at levels of assurance above NIST level 1: 8
- Better support for mobile devices: 8
- Addressing the problem of long URLs (where browsers limit URL length to 2048 or sometimes 256 characters): 6
And in case it isn’t obvious from reading the above, there was also an explicit consensus in the room that OpenID v.Next would not be backwards compatible with OpenID 2.0. (It will be related to, but not compatible with OpenID 2.0, analogously to how SAML 2.0 is related to, but not compatible with SAML 1.1.) I believe we have interesting and exciting times ahead!
The 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.
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=
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.
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.
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.
The signin page is followed by the standard Yahoo permissions page. I click “Agree”.
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.
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
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.
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.
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.
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.
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.
Following signin, Google asks me permission to release information to signup.universalmusic.com. I allow it.
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
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
Andrew Arnott created the first selector-enabled relying party site for us, which is shown above. I click “Log in using your OpenID Selector”.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
“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
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…
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.
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!
It’s been an open secret in the identity community for the past several months that the US Government has embarked on an initiative to enable people to sign into US Government web sites using commercial identities. The public announcements of the first steps were made last week during the Gov 2.0 Summit. Now that we can write about the initiative, here’s a personal recap of some of the steps that have gotten us here, and thoughts about what comes next.
- Then-candidate Barack Obama made a commitment to increase people’s access to government services; President Obama issued his Transparency and Open Government memo reinforcing this commitment on his first day in office.
- The federal CIO, Vivek Kundra, requested that the GSA do the ground work to enable people to log into US government web sites using commercially-issued identities using open protocols.
- In parallel to this, the Information Card Foundation, and especially Mary Ruddy, had been working with the GSA on a demo of using Information Cards to sign into government sites. The GSA demonstrated using the Equifax card to sign into a mockup of recovery.gov in April at RSA.
- In April, the GSA, and in particular, the Identity, Credential, and Access Management (ICAM) committee, communicated the need for certification frameworks for identity technologies and identity providers to be used to access government sites. The OpenID Foundation and Information Card Foundation agreed to develop certification programs for their respective technologies and to work with the GSA on profiles for use of the technologies.
- Not long thereafter, the OpenID Foundation and Information Card Foundation made a key decision to work together on aspects of the profiles and certification programs that can be common between the two technologies. Don Thibeau, the OIDF executive director, and Drummond Reed, the ICF executive director, get enormous credit for this decision, which I believe has served both communities well.
- The foundations jointly hired John Bradley to develop profiles for the two technologies. They also hired the same lawyer to look at liability issues.
- The foundations decided to base their profiles as much as possible on the SAML government profile developed by InCommon, so as not to re-invent the wheel.
- ICAM published its Identity Scheme Adoption Process and Trust Framework Provider Adoption Process documents in July. These established criteria for identity technologies and trust framework providers to be accredited for use at US Government sites.
- Based on their work together and with the government, the two foundations published the joint whitepaper “Open Trust Frameworks for Open Government”, with its release timed to coincide with the Open Government Identity Management Solutions Privacy Workshop in August. The whitepaper is available on both OIDF site and the ICF site.
- The privacy characteristics of the draft profiles when used at ICAM Assurance Level 1 (a.k.a. NIST Assurance Level 1) were subjected to public review at the Open Government Identity Management Solutions Privacy Workshop.
- On September 9th, the two foundations jointly announced the Open Identity for Open Government initiative, with Yahoo!, PayPal, Google, Equifax, AOL, VeriSign, Acxiom, Citi, Privo and Wave Systems participating as identity providers. See the press release on the ICF site or the OIDF site.
- On September 9th, US federal CIO Vivek Kundra met with the boards of the OpenID Foundation and Information Card Foundation to discuss progress on the initiative to accept commercial identities at government web sites. He endorsed the idea of starting with three pilot projects that would enable privacy, security, and usability issues to be identified and addressed before a broader rollout. He agreed that two of these pilots should be at ICAM Assurance Level 1 and one at Level 2 or 3.
- The ICAM OpenID 2.0 Profile was published on September 9th.
- At the Gov 2.0 Summit on September 10th, Vivek Kundra described the identity initiative to attendees. His remarks were in the context of things he is doing to make government’s IT investments more efficient. He gave the example of making campground reservations at recreation.gov, which currently requires you to create an account that you’re unlikely to use again soon. He said that since you already have identities from Google or Yahoo or Microsoft, wouldn’t it be better to let you use those identities at the government site?
- ICAM updated the Open Identity Solutions for Open Government page on September 10th. This page should continue to reflect the current state of the initiative.
Of course, despite all the activity above, this is really just the beginning. No government relying parties are yet live, the identity provider certification programs are still being developed, and the Information Card profile is not yet final. Only once sites go live will data start to come in about whether people are able to successfully use commercially-issued identities at the sites, and whether they find this capability useful.
Finally, I’ll note that while government sites will always be only a small fraction of the sites that people use on the Internet, and will typically not be on the cutting edge of innovation, I believe that that this is one of the relatively rare moments where a government initiative is serving as a useful focal point for action within private enterprise. A diverse set of companies and organizations have come together to meet this challenge in a way that would be hard to imagine happening without the government initiative to serve as a catalyst. That’s all good.
We still have a lot to learn and a lot to do. I’m glad we’re getting started.
There’s no other event like it where Identity leaders come together to collaborate and advance the state of Identity on the Internet together. Be there and be part of it!
Tuesday-Thursday, November 3-5, Computer History Museum, Mountain View, CA. Early registration discount available through Wednesday, September 16th. Register now!
(And yes, Microsoft will once again be buying you dinner!)
At a typical conference, you listen to thought leaders; at the Internet Identity Workshop unconference, you and your peers lead together.
Special bonus offer: Continuing a tradition dating back to the second IIW, Microsoft will be sponsoring a dinner for conference participants.
I’m excited that the first beta of the next version of CardSpace – Windows CardSpace “Geneva” – is now available. You can download the bits for this and the other “Geneva” betas at the “Geneva” Connect site. The team posted a detailed introductory piece about the new version on the team blog, so I won’t repeat that here.
This version of CardSpace is a rewrite on a new code base designed to be much smaller, faster, and easier to use. While it’s an early build and far from feature-complete, we nonetheless wanted to get it out now so you can see the directions we’re headed and give us feedback early in the development cycle. This build runs on Windows Vista (32 and 64 bit), Windows Server 2008, and Windows 7.
We’ll be writing more about the key features of CardSpace “Geneva” soon, and as well as the rest of the “Geneva” family that enables claims-aware applications, so watch this space and the team blog. It’s great to now be able to show and discuss the work the team has been doing. I’m looking forward to the ensuing conversation…
As just announced on the “Geneva” Team Blog (formerly known as the CardSpace Team Blog), beta releases of all three components of Microsoft’s “Geneva” identity platform are now available at the “Geneva” Connect site. The components are:
- “Geneva” Framework: Previously called “Zermatt“, the Geneva Framework helps developers build claims-aware .NET applications that externalize user authentication from the application and helps them build custom Security Token Services (STSs). It supports WS-Federation, WS-Trust, and SAML 2.0.
- “Geneva” Server: Geneva Server is an STS that issues and transforms security tokens and claims, manages user access, and enables easy federation. Based on the “Geneva” framework, it also supports WS-Federation, WS-Trust, and SAML 2.0.
- Windows CardSpace “Geneva”: CardSpace “Geneva” will be the next version of Windows CardSpace. It has a much smaller download footprint, starts fast, and has some innovative user interface improvements made in response to feedback from the first version.
All are early betas that are works in progress, but I highly encourage those of you who are interested in claims-based identity to download them and let us know what you think. Also, be sure to check out the “Introducing ‘Geneva’” whitepaper by David Chappell.