December 3, 2018
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 heirarchal 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!

November 9, 2018
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec adding Key ID considerations

IETF logoKey ID confirmation method considerations suggested by Jim Schaad have been added to the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification. Per discussions in the working group meeting in Bangkok, it’s now time for the shepherd review.

The specification is available at:

An HTML-formatted version is also available at:

November 8, 2018
JWT BCP updates addressing Area Director review comments

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the review comments from Security Area Director (AD) Eric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for working on the responses with me.

Note that IETF publication has already been requested. The next step is for the shepherd review to be submitted and responded to.

The specification is available at:

An HTML-formatted version is also available at:

November 6, 2018
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing additional WGLC comments

IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to addresses a few additional Working Group Last Call (WGLC) comments. All of the (few) changes were about improving the clarity of the exposition. I believe that this completes addressing the WGLC comments.

Thanks to Roman Danyliw for helping to categorize the remaining comments that needed to be addressed.

The specification is available at:

An HTML-formatted version is also available at:

October 23, 2018
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:

October 23, 2018
Security Event Token (SET) delivery specifications updated

IETF logoNow that the Security Event Token (SET) specification is RFC 8417, the SecEvent working group is working on defining the SET delivery mechanisms. This week, both the push-based and poll-based SET delivery specs have been updated to simplify their exposition and reduce duplication of text between the drafts. Thanks to Annabelle Backman for doing the bulk of the recent work on the push-based delivery spec. The latest versions of both specs contain these updates:

  • Addressed problems identified in my 18-Jul-18 review message titled “Issues for both the Push and Poll Specs”.
  • Changes to align terminology with RFC 8417, for instance, by using the already defined term SET Recipient rather than SET Receiver.
  • Applied editorial and minor normative corrections.
  • Updated Marius Scurtescu’s contact information.

In addition, the latest version of the poll delivery spec also contains this update:

  • Begun eliminating redundancies between this specification and “Push-Based Security Event Token (SET) Delivery Using HTTP”, referencing, rather that duplicating common normative text.

The specifications are available at:

HTML-formatted versions are also available at:

October 8, 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.

September 29, 2018
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

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!

August 29, 2018
The role of standards in accelerating innovation

Use of standards accelerates innovation. Oxymoron? Not at all!

Read Alex Simons’ description of how using robust standards like JWT is accelerating innovation when prototyping decentralized identity systems.

August 21, 2018
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.

August 7, 2018
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

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.

July 20, 2018
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 servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.

This document is a companion document to The Token Binding Protocol.

This is a huge step towards cryptographically protecting data structures that had previously been bearer tokens, such as browser cookies, refresh tokens, access tokens, ID Tokens, etc., so that they can only be used by the intended party. Congratulations especially to the editors Andrei Popov, Dirk Balfanz, and Jeff Hodges, as well as the chairs John Bradley and Leif Johansson for getting us to this important milestone!

The three specifications are:

July 10, 2018
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!

July 1, 2018
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:

June 29, 2018
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing WGLC comments

IETF logoA new draft of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published that addresses the Working Group Last Call (WGLC) comments received. Changes were:

Thanks to Samuel Erdtman and Hannes Tschofenig for contributing to the editing for this version and to Jim Schaad and Roman Danyliw for their review comments.

The specification is available at:

An HTML-formatted version is also available at:

June 28, 2018
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 for the initial set of registered metadata values.

Thanks to all of you who helped make this standard a reality!

June 24, 2018
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:

June 1, 2018
OAuth Device Flow spec addressing initial IETF last call feedback

OAuth logoThe OAuth Device Flow specification (full name “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices”) has been updated to address comments received to date from the IETF last call. Thanks to William Denniss for taking the pen for this set of revisions. Changes were:

  • Added a missing definition of access_denied for use on the token endpoint.
  • Corrected text documenting which error code should be returned for expired tokens (it’s “expired_token”, not “invalid_grant”).
  • Corrected section reference to RFC 8252 (the section numbers had changed after the initial reference was made).
  • Fixed line length of one diagram (was causing xml2rfc warnings).
  • Added line breaks so the URN grant_type is presented on an unbroken line.
  • Typos fixed and other stylistic improvements.

The specification is available at:

An HTML-formatted version is also available at:

May 22, 2018
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, Google, Microsoft, etc.). This presentation will examine the progress we’ve made, the standards and devices making it possible, and stimulate a discussion on what’s left to do to deprecate the password.

Key takeaways are:

    There are good alternatives to passwords in use today.
    Passwords are being used for fewer and fewer identity interactions.
    Devices are increasingly enabling authentication without passwords.
    New standards are enabling cross-platform password-less authentication.
    The days of having to use passwords for everything you do are numbered!

Thanks to Steve Hutchinson for this photo from the presentation and his vote of confidence.
Mike presenting at EIC 2018

Extra: See all the Microsoft presentations at EIC 2018, including videos of Joy Chik’s and Kim Cameron’s keynotes.

May 18, 2018
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

Next »