I gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 23, 2018:
- Introduction to OpenID Connect (PowerPoint) (PDF)
Category: OpenID Page 4 of 10
The IETF Token Binding working group has completed the core Token Binding specifications. These new standards are:
- RFC 8471: The Token Binding Protocol Version 1.0
- RFC 8472: Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
- RFC 8473: Token Binding over HTTP
As Alex Simons recently wrote, it’s time for token binding. Especially now that the core specs are done, now’s the time for platforms and applications to deploy Token Binding. This will enable replacing bearer tokens, which can be stolen and reused, with Token Bound tokens, which are useless if stolen. This is a huge security benefit applicable to any tokens used over TLS, including browser cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens.
Congratulations especially to the editors Andrei Popov, Dirk Balfanz, Jeff Hodges, Magnus Nyström, and Nick Harper and the chairs John Bradley and Leif Johansson for getting this done!
I likewise look forward to timely completion of related Token Binding specifications, which enable use of Token Binding with TLS 1.3, with OAuth 2.0, and with OpenID Connect.
A quick reminder that the vote to approve updates to the OpenID IPR Policy document is under way. If you’re an OpenID Foundation member, I encourage you to vote to approve the updates now at https://openid.net/foundation/members/polls/151.
As described in the OpenID Foundation post Proposed Revisions to OpenID IPR Policy Document, the updates enable the use of electronic signatures on contributor agreements instead of requiring on-paper signatures and simplify the descriptions of working group contributors, all without changing the IPR rights of any party.
The foundation needs 30% of the membership to vote in order for the changes to take effect, so please take a moment and vote now. Thanks!
Check out Alex Simons‘ and Pamela Dingle‘s blog post “It’s Time for Token Binding“. Now that the IETF Token Binding specs are essentially done, it’s time to ask those who write TLS software you use to ship Token Binding support soon, if they haven’t already done so.
Token Binding in a nutshell: When an attacker steals a bearer token sent over TLS, he can use it; when an attacker steals a Token Bound token, it’s useless to him.
The Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.
SETs are already in use to represent OpenID Connect Back-Channel Logout tokens and to represent Risk and Incident Sharing and Coordination (RISC) events. Thanks to my co-editors, members of the IETF ID Events mailing list, and members of the IETF Security Events working group for making this standard a reality!
The OpenID Connect Token Bound Authentication specification has been updated in response to developer feedback and in anticipation of the IETF Token Binding specifications finishing. Changes were:
- Adjusted the metadata to indicate supported confirmation method hash algorithms for Token Binding IDs in ID Tokens.
- Updated references for draft-ietf-tokbind-protocol to -19, draft-ietf-tokbind-https to -17, draft-ietf-oauth-token-binding to -07, and draft-ietf-oauth-discovery to -10.
- Explicitly stated that the base64url encoding of the “
tbh” value doesn’t include any trailing pad characters, line breaks, whitespace, etc.
(The representation of the Token Binding ID in the ID Token is unchanged.)
Thanks to Brian Campbell for doing the editing for this draft.
The specification is available at:
The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.
Having a standard OAuth metadata format makes it easier for OAuth clients to configure connections to OAuth authorization servers. See https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata for the initial set of registered metadata values.
Thanks to all of you who helped make this standard a reality!
I gave the following presentation during the June 2018 Identiverse Conference:
- OpenID Connect: News, Overview, Certification, and Action Items (PowerPoint) (PDF)
News included:
- contribution of the Python JWTConnect OpenID RP library to the OpenID Connect working group and
- launch of the Form Post Response Mode certification profiles for OPs and RPs.
Action items included:
- give the Python JWTConnect OpenID RP library a try,
- test the Form Post Response Mode conformance tests and certify your implementations,
- review the OpenID Connect logout specifications now before we vote them to Final status,
- review the OpenID Connect Federation specification during the current Implementer’s Draft review period,
- participate in the RISC Implementer’s Drafts members vote before Friday, and
- join the OpenID Foundation to be able to participate in the vote.
This week the OpenID Certification program won the 2018 European Identity and Cloud Award for Best Innovation at the European Identity and Cloud (EIC) conference. This is actually the second award for the OpenID Certification program this year and only the latest in a series awards recognizing the value and impact of OpenID Connect and certification of its implementations.
On this occasion, I thought I’d take the opportunity to recount the awards that OpenID Connect, the specifications underlying it, and its certification program have been granted. To date, they are:
- OpenID Connect: 2012 European Identity Award for Best Innovation/New Standard
- OAuth 2.0: 2013 European Identity Award for Best Innovation/New Standard
- JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE): 2014 Special European Identity Award for Best Innovation
- OpenID Certification program: 2018 Identity Innovation Award
- OpenID Certification program: 2018 European Identity and Cloud Award for Best Innovation
My sincere thanks to Kuppinger Cole for their early recognition of potential of OpenID Connect, for calling out the value of OAuth 2.0, JWT, and JOSE, and to both IDnext and Kuppinger Cole for recognizing the importance and global impact of OpenID Certification!
Speaking of impact, I can’t help but end this note with data that Alex Simons presented at EIC this week. 92% of Azure Active Directory (AAD) authentications use OpenID Connect. There’s no better demonstration of impact than widespread deployment. Very cool!
The OpenID Certification program won the 2018 European Identity and Cloud Award for Best Innovation at the European Identity and Cloud (EIC) conference. See the award announcement by the OpenID Foundation for more details. This is actually the second award this year for the OpenID Certification program.
The award recognizes that the OpenID Certification program has become a significant global force promoting high-quality, secure, interoperable OpenID Connect implementations. Its innovative use of self-certification using freely available online tools has made testing the quality of OpenID Connect implementations simple, effective, and commonplace. Thanks to Kuppinger Cole for recognizing the impact of the OpenID Certification program!
I gave the following presentations during the OpenID workshop at the May 2018 European Identity and Cloud Conference (EIC):
- OpenID Connect Working Group status update (PowerPoint) (PDF)
- OpenID Certification status update (PowerPoint) (PDF)
- OpenID EAP Working Group status update (PowerPoint) (PDF)
I gave the following presentations at the Monday, April 2, 2018 OpenID Workshop at Oracle:
- OpenID Connect Working Group status update (PowerPoint) (PDF)
- OpenID Certification status update (PowerPoint) (PDF)
I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 3, 2018:
- Introduction to OpenID Connect (PowerPoint) (PDF)
I’m thrilled that the OpenID Certification program has won the 2018 Identity Innovation Award at the IDnext conference. See the award announcement by the OpenID Foundation for more details.
The award recognizes that the OpenID Certification program has become a significant global force promoting high-quality, secure, interoperable OpenID Connect implementations. Its innovative use of self-certification using freely available online tools has made testing the quality of OpenID Connect implementations simple, effective, and commonplace. Thanks to IDnext for recognizing the impact of the OpenID Certification program!
Also, see the IDnext press release announcing the award and its description of the opinion of the award committee:
The significant global impact of the OpenID Certification program was a reason for its selection for the Identity Innovation Award. It recognizes that the innovative use of self-certification, with freely available testing tools, has resulted in substantial participation in the certification program, improving the security, quality, and interoperability of OpenID Connect implementations worldwide.
Finally, here’s the presentation that I gave at the IDnext conference making the case for the award (pptx) (pdf).
Digital identity systems almost universally support end-users logging into applications and many also support logging out of them. But while login is reasonable well understood, there are many different kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logouts.
I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth Security Workshop in Trento, Italy, which was held the week before IETF 101, to explore this topic. The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic. Brock Allen — a practicing application security architect (and MVP for ASP.NET/IIS) — significantly contributed to the materials used to seed the discussion. And Nat Sakimura took detailed notes to record what we learned during the discussion.
Feedback on the discussion was uniformly positive. It seemed that all the participants learned things about logout use cases, mechanisms, and limitations that they previously hadn’t previously considered.
Materials related to the session are:
- Presentation used to bootstrap the discussions (pptx) (pdf)
- Notes from the session
- Workshop submission (pdf)
- OpenID Connect issue “Create a document explaining “single logout” semantics“
The Security Event Token (SET) specification has been updated to simplify the definitions and usage of the “iat” (issued at) and “toe” (time of event) claims. The full set of changes made was:
- Simplified the definitions of the “
iat” and “toe” claims in ways suggested by Annabelle Backman. - Added privacy considerations text suggested by Annabelle Backman.
- Updated the RISC event example, courtesy of Marius Scurtescu.
- Reordered the claim definitions to place the required claims first.
- Changed to using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.
Thanks to Annabelle Backman, Marius Scurtescu, Phil Hunt, and Dick Hardt for the discussions that led to these simplifications.
The specification is available at:
An HTML-formatted version is also available at:
A new version of the Security Event Token (SET) specification has been published that incorporates clarifications suggested by working group members in discussions since IETF 100. Changes were:
- Clarified that all “events” values must represent aspects of the same state change that occurred to the subject — not an aggregation of unrelated events about the subject.
- Removed ambiguities about the roles of multiple “events” values and the responsibilities of profiling specifications for defining how and when they are used.
- Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
- Addressed terminology inconsistencies. In particular, standardized on using the term “issuer” to align with JWT terminology and the “iss” claim. Previously the term “transmitter” was sometimes used and “issuer” was sometimes used. Likewise, standardized on using the term “recipient” instead of “receiver” for the same reasons.
- Added a RISC event example, courtesy of Marius Scurtescu.
- Applied wording clarifications suggested by Annabelle Backman and Yaron Sheffer.
- Applied numerous grammar, syntax, and formatting corrections.
No changes to the semantics of the specification were made.
The specification is available at:
An HTML-formatted version is also available at:
The OAuth 2.0 Token Binding specification has been updated to enable Token Binding of JWT Authorization Grants and JWT Client Authentication. The discussion of phasing in Token Binding was improved and generalized. See the Document History section for other improvements applied.
The specification is available at:
An HTML-formatted version is also available at:
An update to the closely-related OpenID Connect Token Bound Authentication 1.0 specification was also simultaneously published. Its discussion of phasing in Token Binding was correspondingly updated.
The OpenID Connect Token Binding specification is available in HTML and text versions at:
- http://openid.net/specs/openid-connect-token-bound-authentication-1_0-02.html
- http://openid.net/specs/openid-connect-token-bound-authentication-1_0-02.txt
Thanks to Brian Campbell for doing the bulk of the editing for both sets of revisions.
I gave the following presentations at the Monday, October 16, 2017 OpenID Workshop at PayPal:
- OpenID Connect Working Group (PowerPoint) (PDF)
- OpenID Certification (PowerPoint) (PDF)
- OpenID Enhanced Authentication Profile (EAP) Working Group (PowerPoint) (PDF)
I also gave the following “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 17th:
- Introduction to OpenID Connect (PowerPoint) (PDF)
The Authentication Method Reference Values specification is now RFC 8176. The abstract describes the specification as:
The
amr(Authentication Methods References) claim is defined and registered in the IANA “JSON Web Token Claims” registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.
The specification defines and registers some Authentication Method Reference values such as the following, which are already in use by some Google and Microsoft products and OpenID specifications:
- “
face” — Facial recognition - “
fpt” — Fingerprint - “
hwk” — Proof-of-possession of a hardware-secured key - “
otp” — One-time password - “
pin” — Personal Identification Number - “
pwd” — Password - “
swk” — Proof-of-possession of a software-secured key - “
sms” — Confirmation using SMS - “
user” — User presence test - “
wia” — Windows Integrated Authentication
See https://www.iana.org/assignments/authentication-method-reference-values/ for the full list of registered values.
Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all of whom substantially contributed to the specification. Thanks also to the OAuth working group members, chairs, area directors, and other IETF members who helped refine the specification.
As announced by the OpenID Foundation, the OpenID membership has approved Implementer’s Drafts of the three OpenID Connect logout specifications. That means that developers and deployers can now count on the intellectual property protections that come with being Implementer’s Drafts.
These are the first Implementer’s Drafts of these specifications:
- Front-Channel Logout – Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
- Back-Channel Logout – Defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out
Whereas, this is the fourth Implementer’s Draft of this specification:
- Session Management – Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
Each of these protocols communicate logout requests from OpenID Providers to Relying Parties, but using different mechanisms that are appropriate for different use cases. See the Introduction sections of each of the specifications for descriptions of the mechanisms used and comparisons between them. All the specifications share a common mechanism for communicating logout requests from Relying Parties to OpenID Providers.
As expected, the reviews generated some great feedback on ways to make the specs clearer. I expect the working group to incorporate that feedback in future revisions.