August 7, 2020
OpenID Connect Logout specs addressing all known issues

OpenID logoI’ve been systematically working through all the open issues filed about the OpenID Connect Logout specs in preparation for advancing them to Final Specification status. I’m pleased to report that I’ve released drafts that address all these issues. The new drafts are:

The OpenID Connect working group waited to make these Final Specifications until we received feedback resulting from certification of logout deployments. Indeed, this feedback identified a few ambiguities and deficiencies in the specifications, which have been addressed in the latest edits. You can see the certified logout implementations at https://openid.net/certification/. We encourage you to likewise certify your implementations now.

Please see the latest History entries in the specifications for descriptions of the normative changes made. The history entries list the issue numbers addressed. The issues can be viewed in the OpenID Connect issue tracker, including links to the commits containing the changes that resolved them.

All are encouraged to review these drafts in advance of the formal OpenID Foundation review period for them, which should commence in a few weeks. If you believe that changes are needed before they become Final Specifications, please file issues describing the proposed changes. Discussion on the OpenID Connect mailing list is also encouraged.

Special thanks to Roland Hedberg for writing the initial logout certification tests. And thanks to Filip Skokan for providing resolutions to two of the thornier Session Management issues.

July 7, 2020
Identiverse 2020 Talk: Enabling Scalable Multi-lateral Federations with OpenID Connect

OpenID logoMy Identiverse 2020 talk Enabling Scalable Multi-lateral Federations with OpenID Connect was just broadcast and is available for viewing. The talk abstract is:

Numerous large-scale multi-lateral identity federations are in production use today, primarily in the Research and Education sector. These include national federations, such as SWAMID in Sweden and InCommon in the US, some with thousands of sites, and inter-federations among dozens of federations, such as eduGAIN. Yet these existing federations are based on SAML 2 and require the federation operator to poll the participants for their metadata, concatenating it into a huge file that is distributed to all federation participants nightly – a brittle process with significant scalability problems.

Responding to demand from the Research and Education community to migrate from SAML 2 to the simpler OpenID Connect protocol, the OpenID Connect working group has created the OpenID Connect Federation specification to enable this. The new approach incorporates lessons learned from existing SAML 2 federations – especially using a new, scalable approach to federation metadata, in which organizations host their own signed metadata and federation operators in turn sign statements about the organizations that are participants in the federation. As Shibboleth author Scott Cantor publicly said at a federation conference, “Given all my experience, if I were to redo the metadata handling today, I would do it along the lines in the OpenID Connect Federation specification”.

This presentation will describe progress implementing and deploying OpenID Connect Federation, upcoming interop events and results, and next steps to complete the specification and foster production deployments. The resulting feedback from Identiverse participants on the approach will be highly valuable.

As a late-breaking addition, data from the June 2020 Federation interop event organized by Roland Hedberg was included in the presentation.

You can also view the presentation slides as PowerPoint or PDF.

June 29, 2020
SecEvent Delivery specs sent to the RFC Editor

IETF logoI’m pleased to report that the SecEvent delivery specifications are now stable, having been approved by the IESG, and will shortly become RFCs. Specifically, they have now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specifications with confidence that that breaking changes will not occur as they are finalized.

The specifications are available at:

HTML-formatted versions are also available at:

June 19, 2020
Registrations for all WebAuthn algorithm identifiers completed

IETF logoWe wrote the specification COSE and JOSE Registrations for WebAuthn Algorithms to create and register COSE and JOSE algorithm and elliptic curve identifiers for algorithms used by WebAuthn and CTAP2 that didn’t yet exist. I’m happy to report that all these registrations are now complete and the specification has progressed to the RFC Editor. Thanks to the COSE working group for supporting this work.

Search for WebAuthn in the IANA COSE Registry and the IANA JOSE Registry to see the registrations. These are now stable and can be used by applications, both in the WebAuthn/FIDO2 space and for other application areas, including decentralized identity (where the secp256k1 “bitcoin curve” is in widespread use).

The algorithms registered are:

  • RS256 – RSASSA-PKCS1-v1_5 using SHA-256 – new for COSE
  • RS384 – RSASSA-PKCS1-v1_5 using SHA-384 – new for COSE
  • RS512 – RSASSA-PKCS1-v1_5 using SHA-512 – new for COSE
  • RS1 – RSASSA-PKCS1-v1_5 using SHA-1 – new for COSE
  • ES256K – ECDSA using secp256k1 curve and SHA-256 – new for COSE and JOSE

The elliptic curves registered are:

  • secp256k1 – SECG secp256k1 curve – new for COSE and JOSE
June 15, 2020
SecEvent Delivery specs now unambiguously require TLS

IETF logoThe SecEvent delivery specifications have been revised to unambiguously require the use of TLS, while preserving descriptions of precautions needed for non-TLS use in non-normative appendices. Thanks to the Security Events and Shared Signals and Events working group members who weighed in on this decision. I believe these drafts are now ready to be scheduled for an IESG telechat.

The updated specifications are available at:

HTML-formatted versions are also available at:

June 9, 2020
CBOR Tags for Date Registered

IETF logoThe CBOR tags for the date representations defined by the “Concise Binary Object Representation (CBOR) Tags for Date” specification have been registered in the IANA Concise Binary Object Representation (CBOR) Tags registry. This means that they’re now ready for use by applications. In particular, the full-date tag requested for use by the ISO Mobile Driver’s License specification in the ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification” working group is now good to go.

FYI, I also updated the spec to incorporate a few editorial suggestions by Carsten Bormann. The new draft changed “positive or negative” to “unsigned or negative” and added an implementation note about the relationship to Modified Julian Dates. Thanks Carsten, for the useful feedback, as always!

It’s my sense that the spec is now ready for working group last call in the CBOR Working Group.

The specification is available at:

An HTML-formatted version is also available at:

June 5, 2020
SecEvent Delivery Specs Addressing Directorate Reviews

IETF logoI’ve published updated SecEvent delivery specs addressing the directorate reviews received during IETF last call. Thanks to Joe Clarke, Vijay Gurbani, Mark Nottingham, Robert Sparks, and Valery Smyslov for your useful reviews.

The specifications are available at:

HTML-formatted versions are also available at:

May 31, 2020
secp256k1 curve and algorithm registered for JOSE use

IETF logoIANA has registered the “secp256k1” elliptic curve in the JSON Web Key Elliptic Curve registry and the corresponding “ES256K” signing algorithm in the JSON Web Signature and Encryption Algorithms registry. This curve is widely used among blockchain and decentralized identity implementations.

The registrations were specified by the COSE and JOSE Registrations for WebAuthn Algorithms specification, which was created by the W3C Web Authentication working group and the IETF COSE working group because WebAuthn also allows the use of secp256k1. This specification is now in IETF Last Call. The corresponding COSE registrations will occur after the specification becomes an RFC.

May 21, 2020
Successful OpenID Foundation Virtual Workshop

OpenID logoI was pleased by the quality of the discussions and participation at the first OpenID Foundation Virtual Workshop. There were over 50 participants, with useful conversations happening both on the audio channel and in the chat. Topics included current work in the working groups, such as eKYC-IDA, FAPI, MODRNA, FastFed, Shared Signals and Events, and OpenID Connect), OpenID Certification, and a discussion on interactions between browser privacy developments and federated login. Thanks to all who participated!

Here’s my presentation on the OpenID Connect working group and OpenID Certification: (PowerPoint) (PDF).

Update: The presentations from the workshop are available at OIDF Virtual Workshop – May 21, 2020.

May 14, 2020
Nearing completion on two WebAuthn-related specs at the IETF

IETF logoThis week we published updates to two IETF specifications that support the WebAuthn/FIDO2 ecosystem, as well as other uses, such as decentralized identity.

One is COSE and JOSE Registrations for WebAuthn Algorithms. It registers algorithm and elliptic curve identifiers for algorithms used by WebAuthn and FIDO2. The “secp256k1” curve being registered is also used for signing in some decentralized identity applications. The specification has completed the Area Director review and has been submitted to the IESG for publication.

The other is Registries for Web Authentication (WebAuthn). This creates IANA registries enabling multiple kinds of extensions to W3C Web Authentication (WebAuthn) implementations to be registered. This specification has completed IETF last call and is scheduled for review by the IESG.

Thanks to the COSE working group for their adoption of the algorithms specification, and to Ivaylo Petrov and Murray Kucherawy for their reviews of it. Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area Director sponsorships of the registries specification and to Jeff Hodges for being primary author of it.

The specifications are available at:

May 7, 2020
Working group adoption of Concise Binary Object Representation (CBOR) Tags for Date

IETF logoThe IETF CBOR working group has adopted the specification Concise Binary Object Representation (CBOR) Tags for Date. The abstract of the specification is:

The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix “seconds since the epoch”). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation without a time. It also defines a CBOR tag for days since the Posix epoch, for applications needing a numeric date representation without a time. It is intended as the reference document for the IANA registration of the CBOR tags defined.

The need for this arose for the ISO Mobile Driver’s License specification in the working group ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification”.

The specification is available at:

An HTML-formatted version is also available at:

May 4, 2020
Refinements to “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)”

OAuth logoA number of refinements have been applied to the DPoP specification. As recorded in the History entries, they are:

  • Editorial updates
  • Attempt to more formally define the DPoP Authorization header scheme
  • Define the 401/WWW-Authenticate challenge
  • Added invalid_dpop_proof error code for DPoP errors in token request
  • Fixed up and added to the IANA section
  • Added dpop_signing_alg_values_supported authorization server metadata
  • Moved the Acknowledgements into an Appendix and added a bunch of names (best effort)

Thanks to Brian Campbell for doing the editing for this round.

The specification is available at:

May 4, 2020
Security Event Token (SET) delivery specifications in IETF Last Call

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address additional Area Director review comments by Benjamin Kaduk. See the History entries for descriptions of the changes, none of which were breaking. Both documents are now open for IETF Last Call reviews.

Thanks again to Ben for his thorough reviews. And thanks to Annabelle Backman for doing the editing for this round.

The specifications are available at:

HTML-formatted versions are also available at:

April 28, 2020
OpenID Presentation at IIW XXX

OpenID logoI gave the following invited “101” session presentation at the 30th Internet Identity Workshop (IIW) on Tuesday, April 28, 2020:

I missed being able to gauge audience reactions by looking around the room but the virtualized session was still well attended by a good group of people, who let me know how OpenID Connect is relevant to what they’re doing.

April 6, 2020
Working group adoption of “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)”

OAuth logoWe’re making progress on a simple application-level proof-of-possession solution for OAuth 2.0. I’m pleased to report that DPoP has now been adopted as an OAuth working group specification. The abstract of the specification is:

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

The specification is available at:

March 9, 2020
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747

IETF logoI’m pleased to report that Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747. The abstract of the specification is:

This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).

This is one of a series of specifications, including CWT [RFC 8392] – which mirrors JWT [RFC 7519], in which we are intentionally bringing functionality that is available in JSON to the CBOR and IoT world.

March 9, 2020
OAuth 2.0 DPoP for the Implicit Flow

OAuth logoAs I previously described, members of the OAuth working group have developed a simplified approach to providing application-level proof-of-possession protections for OAuth 2.0 access tokens and refresh tokens. This approach is called OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP). Among other benefits, this approach does not require a complicated and error-prone procedure for signing HTTP requests, as some past approaches have.

However, the DPoP specification to date has assumed that the client is using the OAuth authorization code flow. As promised at the last IETF meeting, we’ve now published a simple companion specification that describes how DPoP can be used with the OAuth implicit flow – in which access tokens are returned directly from the authorization endpoint. The specification is mercifully brief because very little had to be added to supplement the existing DPoP spec to enable use of DPoP with the implicit flow. Thanks to Brian Campbell and John Bradley for whiteboarding this solution with me.

Finally, in a related development, it was decided during the OAuth virtual interim meeting today to call for working group adoption of the core DPoP draft. That’s an important step on the journey towards making it a standard.

The specification is available at:

An HTML-formatted version is also available at:

March 9, 2020
Allocating a CBOR tag for RFC 3339 date strings

IETF logoI have published the specification Concise Binary Object Representation (CBOR) Tag for Date to allocate a CBOR tag for RFC 3339 full-date values. While there’s already a tag for date-time values, there’s currently no tag allocated for full-date values – a date string without a time. The need for this arose for the ISO Mobile Driver’s License specification in the working group ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification”.

Thanks to Carsten Bormann for pointers on the best way to accomplish this.

The specification is available at:

An HTML-formatted version is also available at:

March 3, 2020
Two New OAuth RFCs: MTLS (RFC 8705) and Resource Indicators (RFC 8707)

OAuth logoTwo widely used OAuth specifications have recently become RFCs. Here’s a bit about both specs.

RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

Abstract: This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

Client certificates are widely used in the financial industry to authenticate OAuth clients. Indeed, this specification was developed in part because it was needed by the OpenID Financial-Grade API (FAPI) specifications. It is in production use by numerous Open Banking deployments today.

RFC 8707: Resource Indicators for OAuth 2.0

Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

This specification standardizes the “resource” request parameter that is used by Azure Active Directory (AAD) V1 to specify the target resource for an OAuth authorization request.

February 19, 2020
JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

OAuth logoThe JSON Web Token Best Current Practices specification is now RFC 8725 and BCP 225. The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, almost five years ago, and has been in production use since at least 2013. This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise. Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others. For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party’s authorization to use a particular telephone number for an incoming call, providing verified Caller ID to help combat fraudulent and unwanted telephone calls. The advice in the BCP can be used by new JWT profiles and applications to take advantage of what’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

Next »