Building the Internet's missing identity layer
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!
I’m pleased to announce that a second set of Release Candidates for the upcoming OpenID Connect Implementer’s Drafts have been released. The first set of Release Candidates received thorough review, resulting in quite a bit of detailed feedback. The current specs incorporate the feedback received, making them simpler, more consistent, and easier to understand.
Please review these this week — especially if you had submitted feedback. The working group plans to decide whether we’re ready to declare Implementer’s Drafts during the OpenID Meeting before IETF 86 on Sunday.
The new specifications are:
See the History entries in the specs for details on the changes made.
Thanks again to all who did so much to get us to this point, including the spec writers, working group members, and especially the implementers!
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.
As you may have seen, the results of the 2013 OpenID Board Election have been announced. Thanks to all of you who participated and thank you for entrusting me with a seat on the board for the next two years. My congratulations to my fellow board community members as well. I intend to make the most of this opportunity to continue making people’s online interactions more seamless, secure, and valuable.
The election for community (individual) OpenID board members is under way at https://openid.net/foundation/members/elections/14. I encourage all of you to vote now. (Don’t wait until the morning of Wednesday, February 6th!) If you’re not already an OpenID Foundation member, you can join for USD $25 at https://openid.net/foundation/members/registration and participate in the election.
I’m running for the board this time and would appreciate your vote. My candidate statement, which is also posted on the election site, follows.
OpenID has the potential to make people’s online interactions seamless, secure, and more valuable. I am already working to make that a reality.
First, a bit about my background with OpenID… I’ve been an active contributor to OpenID since early 2007, including both specification work and serving the foundation. My contributions to the specification work have included: an author and editor of the OpenID Provider Authentication Policy Extension (PAPE) specification, editor of the OAuth 2.0 bearer token specification (now RFC 6750), an author and editor of the JSON Web Token (JWT) specification and the JSON Object Signing and Encryption (JOSE) specifications, which are used by OpenID Connect, and an active member of the OpenID Connect working group.
I’ve also made substantial contributions to the foundation and its mission, including: In 2007 I worked with the community to create a legal framework for the OpenID Foundation enabling both individuals and corporations to be full participants in developing OpenID specifications and ensuring that the specifications may be freely used by all; this led to the patent non-assertion covenants that now protect implementers of OpenID specifications. I served on the board representing Microsoft in 2008 and 2009, during which time I was chosen by my fellow board members to serve as secretary; you’ve probably read some of the meeting minutes that I’ve written. I’ve served on the board as an individual since 2011. I have helped organize numerous OpenID summits and working group meetings. I chaired the election committee that developed the foundation’s election procedures and software, enabling you to vote with your OpenID. I co-chaired the local chapters committee that developed the policies governing the relationships between local OpenID chapters around the world and the OpenID Foundation. I also serve on the marketing committee and am a member of the Account Chooser working group.
I’d like to continue serving on the OpenID board, because while OpenID has had notable successes, its work is far from done. Taking it to the next level will involve both enhanced specifications and strategic initiatives by the foundation. Through OpenID Connect, we are in the process of evolving OpenID to make it much easier to use and deploy and to enable it to be used in more kinds of applications on more kinds of devices. The Account Chooser work is making it easier to use identities that you already have across sites. I’m also pleased that the Backplane Exchange work is happening in the foundation – clear evidence of the increasing value provided by the OpenID Foundation. Yet, as a foundation, we need to continue building a broader base of supporters and deployers of OpenID, especially internationally. We need to form closer working relationships with organizations and communities doing related work. And we need continue to safeguarding OpenID’s intellectual property and trademarks so they are freely available for all to use.
I have a demonstrated track record of serving OpenID and producing results. I want to continue being part of making open identity solutions even more successful and ubiquitous. That’s why I’m running for a community board seat in 2013.
Mike Jones
mbj@microsoft.com
https://self-issued.info/
I’m pleased to announce that release candidate versions of the soon-to-come OpenID Connect Implementer’s Drafts have been released. All the anticipated breaking changes to the protocol are now in place, including switching Discovery over from using Simple Web Discovery to WebFinger and aligning Registration with the OAuth Dynamic Client Registration draft. While several names changed for consistency reasons, the changes to Discovery and Registration were the only architectural changes.
Please thoroughly review these drafts this week and report any issues that you believe need to be addressed before we release the Implementer’s Draft versions.
Normative changes since the December 27th, 2012 release were:
acct: scheme when passed to WebFinger.c_hash” and “at_hash” be computed using SHA-2 algorithms (for crypto agility reasons).display_values_supported“, “claim_types_supported“, “claims_supported“, and “service_documentation” discovery elements.javascript_origin_uris“, which is no longer present in Session Management.session_state” parameter to the authorization response for Session Management.post_logout_redirect_url” registration parameter for Session Management.Also, renamed these identifiers for naming consistency reasons:
user_jwk -> sub_jwk (used in self-issued ID Tokens)token_endpoint_auth_type -> token_endpoint_auth_methodtoken_endpoint_auth_types_supported -> token_endpoint_auth_methods_supportedcheck_session_iframe_url -> check_session_iframeend_session_endpoint_url -> end_session_endpointtype -> operation (in Registration)associate -> register (in Registration)application_name -> client_namecheck_session_endpoint -> check_session_iframeSee the History entries in the specifications for more details.
The new specification versions are at:
Thanks to all who did so much to get us to this point, including the spec writers, working group members, and implementers!
Draft 10 of the Assertion Framework for OAuth 2.0 has been published. It contains non-normative changes that add the “Interoperability Considerations” section, rename “Principal” to “Subject” to use the same terminology as the SAML Assertion Profile and JWT Assertion Profile specs, and apply Shawn Emery’s comments from the security directorate review.
The draft is available at:
An HTML formatted version is available at:
I highly recommend a piece that my friend Vittorio Bertocci wrote on the relationship between OAuth 2.0 and sign-in/federation protocols. While OAuth 2.0 can be used to sign in users and the term “OAuth” is often bandied about in identity contexts, as he points out, there’s a lot of details to fill in to make that possible. That’s because OAuth 2.0 is a resource authorization protocol — not an authentication protocol.
Read his post for a better understanding of how OAuth 2.0 relates to sign-in protocols, including a useful discussion of how OpenID Connect fills in the gaps to enable people to sign in with OAuth 2.0 in an interoperable manner.
New versions of the OpenID Connect specifications have been released resolving numerous open issues raised by the working group. The most significant change is changing the name of the “user_id” claim to “sub” (subject) so that ID Tokens conform to the OAuth JWT Bearer Profile specification, and so they can be used as OAuth assertions. (Also, see the related coordinated change to the OAuth JWT specifications.) A related enhancement was extending our use of the “aud” (audience) claim to allow ID Tokens to have multiple audiences. Also, a related addition was defining the “azp” (authorized party) claim to allow implementers to experiment with this proposed functionality. (This is a slightly more general form of the “cid” claim that Google and Nat Sakimura had proposed.)
Other updates were:
offline_access” scope value was defined to request that a refresh token be returned when using the code flow that can be used to obtain an access token granting access to the user’s UserInfo endpoint even when the user is not present.tos_url” registration parameter was added so that the terms of service can be specified separately from the usage policy.jwk_url” and “jwk_encryption_url” refer to documents containing JWK Sets – not single JWK keys.Implementers need to apply these name changes to their code:
user_id -> subprn -> subuser_id_types_supported -> subject_types_supporteduser_id_type -> subject_typeacrs_supported -> acr_values_supportedalg -> kty (in JWKs)See the Document History section of each specification for more details about the changes made.
This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: JOSE Release Notes, OAuth Release Notes.
The new specification versions are:
New versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs have been released incorporating feedback since IETF 85 in Atlanta. The primary change is changing the name of the “prn” claim to “sub” (subject) both to more closely align with SAML name usage and to use a more intuitive name for this concept. (Also, see the related coordinated change to the OpenID Connect specifications.) The definition of the “aud” (audience) claim was also extended to allow JWTs to have multiple audiences (a feature also in SAML assertions).
An explanation was added to the JWT spec about why should be signed and then encrypted.
The audience definition in the Assertions specification was relaxed so that audience values can be OAuth “client_id” values. Informative references to the SAML Bearer Profile and JWT Bearer Profile specs were also added.
This release incorporates editorial improvements suggested by Jeff Hodges, Hannes Tschofenig, and Prateek Mishra in their reviews of the JWT specification. Many of these simplified the terminology usage. See the Document History section of each specification for more details about the changes made.
This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: JOSE Release Notes, OpenID Connect Release Notes.
The new specification versions are:
HTML formatted versions are available at:
New versions of the JOSE specs have been released incorporating feedback since IETF 85 in Atlanta. The highlight of this release is the new JSON Private and Symmetric Key spec, which extends JWKs to be able to represent private and symmetric keys. These sensitive keys can then be protected for transmission and storage by JWE encryption of their JWK representations.
One new feature added to JWK is the ability to optionally specify which specific algorithm the key is intended to be used with. (This is already existing practice for keys in X.509 format.) For instance, a symmetric key might be annotated to say that it is to be used with the “HS256” algorithm. Because the natural field name for this functionality is “alg“, the “alg” name is now used for this purpose (matching JWS and JWE) and the key type (formerly “alg“) is now denoted by the “kty” field.
This release incorporates editorial improvements suggested by Jeff Hodges and Hannes Tschofenig in their reviews of the JWT specification. Many of these simplified the terminology usage. See the Document History section of each specification for more details about the changes made.
This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: OAuth Release Notes, OpenID Connect Release Notes.
The new specification versions are:
HTML formatted versions are available at:
The OpenID Foundation has announced the upcoming OpenID community board member election. Board members play an important role in safeguarding and advancing OpenID technologies and doing the work of the Foundation on a day-to-day basis. If you’re considering running, I’d be glad to discuss my experiences serving on the board with you.
Watch the OpenID blog and this space for updates on the election over the next few months.
(And yes, I plan to stand for re-election.)
Vittorio Bertocci just wrote about a developer preview release of JWT support for the Windows Identity Framework (WIF). Among other things, his catalog of places that JWT is already in production use is worth taking note of. I encourage those of you who are using JWTs to download it and give it a spin. Any feedback you could provide on how it works for your use cases would be very valuable.
OAuth 2.0 (a.k.a. RFC 6749) has an extension point for defining additional response_type values beyond the code and token values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification uses this extension point to define the additional response_type values id_token and none, as well as values for the combinations of code, token, and id_token. These response_type values are used by OpenID Connect, as well as other systems using OAuth 2.0.
I’m writing this now because I just updated the Multiple Response Types spec to add an IANA Considerations section to make IANA’s job easier when registering these additional response_type values. No normative changes were made.
The specification is available at:
I’ve made a small set of updates to the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the JOSE and OAuth working group meetings at IETF 85. These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.
Normative changes to the working group specs were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod, xpo) to (n, e). Fields for representing the RSA private key values needed for Chinese Remainder Theorem (CRT) calculations were added to the JSON Private Key specification.
The updated specs are available at:
HTML formatted versions are available at:
See the history entries in the specs for detailed change descriptions.
I’ve updated the Simple Web Discovery (SWD) specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint. This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server. This solution was developed in discussions by the OpenID Connect working group.
This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta.
The updated specification is available at:
Changes made were:
simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain’s host.mailto: from examples in favor of bare e-mail address syntax.An HTML formatted version is available at:
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.
New versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been released. These versions incorporate the decisions made by the JOSE working group during and since IETF 84.
The primary change was revising the JWE format to always use AEAD encryption algorithms. The companion change was defining two new composite AEAD algorithms “A128CBC+HS256” and “A256CBC+HS512” that use AES CBC to perform encryption and matching HMAC SHA-2 algorithms to perform an integrity check on the ciphertext and the parameters used to create it.
Other than that, all changes were local in scope, with no changes to JWS — other than changing the format of the “x5c” (X.509 Certificate Chain) from a string containing a list of certificate values to an array of strings containing certificate values. Likewise, the only changes to JWT were to track changes made in the specs that it uses.
Having addressed all the open issues with resolutions with apparent working group consensus, it’s my hope that the working group will decide to send these specifications to working group last call at IETF 85.
The companion JWS JSON Serialization and JWE JSON Serialization specs were also updated.
The working group specifications are available at:
The individual submission specifications are available at:
The document history entries (also in the specifications) are as follows:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06
x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06
int and kdf parameters and defined the new composite AEAD algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AES CBC, which required the use of separate integrity and key derivation functions.apu (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo). Updated the KDF examples accordingly.x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06
exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)alg (algorithm family) member is REQUIRED.http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06
int and kdf parameters and defined the new composite AEAD algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AES CBC, which required the use of separate integrity and key derivation functions.apu (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo).exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04
http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02
http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-02
HTML formatted versions are available at:
The OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750. This completes the journey to standardize a pair of simple identity specifications that are already in very widespread use for Web, enterprise, cloud, and mobile applications. They make things better by enabling access to resources to be granted without giving the password for the resource to the party being granted access (a pattern that used to be all too common).
I believe that the completion of these RFCs will only accelerate the momentum behind the adoption of simple REST/JSON based identity solutions. Some of the related standards that are already well under way and in use include the OAuth Assertion Framework, the OAuth SAML 2.0 Assertion Profile and OAuth JWT Assertion Profile, JSON Web Token (JWT), the JSON Object Signing and Encryption (JOSE) specs — JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA), and OpenID Connect. Watch this space for future developments. Like OAuth 2.0, all of these are the product of collaboration by numerous people around the world and in many industries to build and deploy simple, usable identity solutions that solve real-world problems.
The goal of all these specs is to standardize functionality that is not only useful, but is simple enough that it will actually be used. OAuth 2.0 is an early success story in this regard. While the number of words in the spec has increased since early drafts, most of that is due to doing a more complete job of describing things not to do (adding security considerations), rather than adding bells and whistles. It doesn’t get much simpler than a couple of HTTP GETs and replies with simple request parameters and responses.
Dick Hardt deserves special thanks for his role both in starting what became OAuth 2.0 and seeing it through to completion. I recommend his post on the process that brought us the OAuth 2.0 RFCs.
Updated drafts of all three OAuth Assertion specifications have been published. These specs define how to use assertions/security tokens as OAuth 2.0 authorization grants and for client authentication. They are: Assertion Framework for OAuth 2.0, SAML 2.0 Bearer Assertion Profiles for OAuth 2.0, and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0.
Language was added to all three explicitly clarifying that an assertion grant type can be used with or without client authentication via an assertion and that client authentication using an assertion is nothing more than an alternative way for a client to authenticate to the token endpoint. Two new examples were added to the SAML and JWT profile drafts to illustrate the use of assertions/security tokens in both cases. Thanks to Brian Campbell for making these updates.
The authors believe that draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer are now ready for Working Group Last Call.
The drafts are available at:
HTML-formatted versions are available at:
Powered by WordPress & Theme by Anders Norén