Musings on Digital Identity

Category: OpenID Page 4 of 10

Security Event Token (SET) delivery specifications updated in preparation for IETF 104

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 104 in Prague. The Push Delivery spec went through working group last call (WGLC). It has been updated to incorporate the WGLC comments. Changes made are summarized in the spec change log, the contents of which were also posted to the working group mailing list. Thanks to Annabelle Backman for the edits to the Push Delivery spec.

It’s worth noting that the Push Delivery spec and the Security Event Token (SET) are now being used in early Risk and Incident Sharing and Coordination (RISC) deployments, including between Google and Adobe. See the article about these deployments by Mat Honan of BuzzFeed.

Changes to the Poll Delivery spec are also summarized in that spec’s change log, which contains:

  • Removed vestigial language remaining from when the push and poll delivery methods were defined in a common specification.
  • Replaced remaining uses of the terms Event Transmitter and Event Recipient with the correct terms SET Transmitter and SET Recipient.
  • Removed uses of the unnecessary term “Event Stream”.
  • Removed dependencies between the semantics of maxEvents and returnImmediately.
  • Said that PII in SETs is to be encrypted with TLS, JWE, or both.
  • Corrected grammar and spelling errors.

The specifications are available at:

HTML-formatted versions are also available at:

OpenID Connect Federation Specification

OpenID logoThe OpenID Connect Federation 1.0 specification is being developed to enable large-scale federations to be deployed using OpenID Connect. It enables trust among federation participants to be established through signed statements made by federation operators about federation participants.

The design of this specification builds upon the experiences gained in operating large-scale SAML 2.0 federations, and indeed, is authored by people having practical experience with these federations. The primary authors are Roland Hedberg and Andreas Ã’¦kre Solberg, with additional contributions by Samuel Gulliksson, John Bradley, and myself, as well as members of the OpenID Connect working group, which is the home of the specification.

A key innovation that differentiates OpenID Connect federations from most SAML 2.0 federations is that OpenID Connect federation employs hierarchal metadata, where participants directly publish statements about themselves, versus the aggregated metadata approach used by many SAML 2.0 federations, where the federation operator publishes a single file concatenating all the metadata for all the federation participants.

The specification was just updated so that the latest version can be discussed at a SURFnet OpenID Connect “Wisdom of the Crowd” session today.

The latest version of specification is available at:

This URL always points to the latest published version:

Please review and/or implement this important specification and send your feedback to the OpenID Connect working group!

OpenID Connect Introduction at October 2018 IIW

OpenID logoI gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 23, 2018:

The core Token Binding specs are now RFCs 8471, 8472, and 8473

IETF logoThe 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.

Vote to update OpenID IPR Policy document now

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!

It’s Time for Token Binding

IETF logoCheck 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.

Security Event Token (SET) is now RFC 8417

IETF logoThe 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!

OpenID Connect Token Binding Specification Updated

OpenID logoThe 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:

OAuth 2.0 Authorization Server Metadata is now RFC 8414

OAuth logoThe 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!

OpenID Connect News, Overview, Certification, and Action Items at June 2018 Identiverse Conference

OpenID logoI gave the following presentation during the June 2018 Identiverse Conference:

News included:

Action items included:

Ongoing recognition for the impact of OpenID Connect and OpenID Certification

OpenID logoThis 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:

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!

Alex Simons 92% OpenID Connect

OpenID Certification wins 2018 European Identity and Cloud Award

OpenID Certified logoThe 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!

EIC 2018 Award EIC 2018 Award Certificate EIC 2018 Award John Bradley, Mike Jones, Nat Sakimura EIC 2018 Award Don Thibeau EIC 2018 Award State EIC 2018 Award Don Thibeau, George Fletcher, Mike Jones, John Bradley, Nat Sakimura

OpenID Presentations at May 2018 European Identity and Cloud Conference (EIC)

OpenID logoI gave the following presentations during the OpenID workshop at the May 2018 European Identity and Cloud Conference (EIC):

OpenID Presentations at April 2018 OpenID Workshop and IIW

OpenID logoI gave the following presentations at the Monday, April 2, 2018 OpenID Workshop at Oracle:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 3, 2018:

OpenID Certification wins the 2018 Identity Innovation Award

OpenID Certified logoI’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.

Identity Innovation Award

Identity Innovation Award Presentation

Finally, here’s the presentation that I gave at the IDnext conference making the case for the award (pptx) (pdf).

What Does Logout Mean?

OAuth logoDigital 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:

Security Event Token (SET) spec simplifying claims usage

IETF logoThe 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:

Security Event Token (SET) spec incorporating clarifications and a RISC example

IETF logoA 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:

OAuth and OpenID Connect Token Binding specs updated

OAuth logoThe 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:

Thanks to Brian Campbell for doing the bulk of the editing for both sets of revisions.

OpenID Presentations at October 16, 2017 OpenID Workshop and IIW

OpenID logoI gave the following presentations at the Monday, October 16, 2017 OpenID Workshop at PayPal:

I also gave the following “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 17th:

Page 4 of 10

Powered by WordPress & Theme by Anders Norén