Archive for the 'Specifications' Category

November 6, 2019
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) sent to the RFC Editor

OAuth logoI’m pleased to report that the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification is now technically stable and will shortly be an RFC – an Internet standard. Specifically, it has 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 specification with confidence that that breaking changes will not occur as it is finalized.

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).

Thanks to the ACE working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

October 24, 2019
COSE and JOSE Registrations for WebAuthn Algorithms spec addressing WGLC comments

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to address working group last call (WGLC) feedback received. Thanks to J.C. Jones, Kevin Jacobs, Jim Schaad, Neil Madden, and Benjamin Kaduk for their useful reviews.

The specification is available at:

An HTML-formatted version is also available at:

October 22, 2019
JSON Web Token Best Current Practices sent to the RFC Editor

OAuth logoI’m pleased to report that the JSON Web Token (JWT) Best Current Practices (BCP) specification is now technically stable and will shortly be an RFC – an Internet standard. Specifically, it has 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 specification with confidence that that breaking changes will not occur as it is finalized.

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. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

Thanks to the OAuth working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

October 21, 2019
OpenID Connect Federation draft 09 ready for your review

OpenID logoDraft 09 of the OpenID Connect Federation specification has been published at https://openid.net/specs/openid-connect-federation-1_0-09.html. This version of the specification benefitted from in-person review by experts at IIW. Major changes were:

  • Separated entity configuration discovery from operations provided by the federation API.
  • Defined new authentication error codes.

The authors believe that this version should become the second Implementer’s Draft, in preparation for interop testing in the coming year. Please review!

October 21, 2019
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Gen-ART and SecDir reviews

IETF logoA new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published addressing the Gen-ART and SecDir review comments. Thanks to Christer Holmberg and Yoav Nir, respectively, for these useful reviews.

The specification is available at:

An HTML-formatted version is also available at:

October 1, 2019
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing remaining Area Director comments

IETF logoA new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published to address the remaining Area Director review comments by Benjamin Kaduk. Thanks to Ludwig Seitz for doing the bulk of the editing for this version.

The specification is available at:

An HTML-formatted version is also available at:

September 19, 2019
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Area Director review comments

IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address the Area Director review comments by Benjamin Kaduk. Thanks to Ludwig Seitz and Hannes Tschofenig for their work on resolving the issues raised.

The specification is available at:

An HTML-formatted version is also available at:

August 16, 2019
OAuth Device Flow is now RFC 8628

OAuth logoThe OAuth Device Flow specification (recently renamed to be the OAuth 2.0 Device Authorization Grant specification) is now RFC 8628. The abstract describes the specification as:

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

This specification standardizes an already widely-deployed pattern in production use by Facebook, ForgeRock, Google, Microsoft, Salesforce, and many others. Thanks to all of you who helped make this existing practice an actual standard!

July 24, 2019
OAuth 2.0 Token Exchange specification sent to the RFC Editor

OAuth logoI’m very pleased to report that the OAuth 2.0 Token Exchange specification is now technically stable and will shortly be an RFC – an Internet standard. Specifically, it has 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 specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

Thanks to the OAuth working group for completing this important specification. And thanks to Brian Campbell for taking point in making the recent updates to get us here.

The specification is available at:

An HTML-formatted version is also available at:

July 8, 2019
Security Event Token (SET) delivery specifications updated in preparation for IETF 105

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 105 in Montreal. Only minor terminological updates were made to the Push Delivery spec following the working group last call (WGLC) changes in the previous recent revisions. Thanks to Annabelle Backman for the edits to the Push Delivery spec.

The changes to the Poll Delivery spec further aligned it with the Push spec, referencing shared functionality, rather than duplicating it. I believe that the Poll spec is now ready for working group last call.

The specifications are available at:

HTML-formatted versions are also available at:

July 8, 2019
Refinements to COSE and JOSE Registrations for WebAuthn Algorithms

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to address feedback received since working group adoption. The one breaking change is changing the secp256k1 curve identifier for JOSE from “P-256K” to “secp256k1”, for reasons described by John Mattsson. The draft now also specifies that the SHA-256 hash function is to be used with “ES256K” signatures – a clarification due to Matt Palmer.

The specification is available at:

An HTML-formatted version is also available at:

June 25, 2019
OpenID Connect Federation Progress at TNC19

OpenID logoCheck out the post OpenID Connect Federation Progress describing the recent updates that Roland Hedberg and I made to the OpenID Connect Federation 1.0 specification. We used the TNC19 conference – a gathering of federation experts – as a venue to get together to review and refine the specification. Besides getting lots done on the spec, I also really enjoyed the TNC conference and its attendees!

Given that the syntax and semantics should now be stable, it’s my hope that early adopters will start kicking the tires – building implementations and making trial deployments. I can’t wait for the useful feedback that results!

May 22, 2019
W3C WebAuthn and FIDO 2.0 win 2019 European Identity and Cloud Award

EIC logoThe W3C WebAuthn and FIDO 2.0 standards have won the 2019 European Identity and Cloud Award for Best Future Technology / Standard Project at the European Identity and Cloud (EIC) conference. This award recognizes the significance of these recently-approved standards, which enable password-less sign-in with platform authenticators, mobile devices, and security keys. They provide a huge step forward for online security, privacy, and convenience.

Thanks to Kuppinger Cole for recognizing the importance and impact of these important new standards!

EIC 2019 Award EIC 2019 Award Certificate

April 3, 2019
OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer

OAuth logoI’m excited that a new, simpler approach for application-level proof of possession of OAuth access tokens and refresh tokens is being developed by members of the IETF OAuth working group. The effort is led by Daniel Fett, who had previously done formal analysis of the OAuth protocol. I wanted to bring it to your attention now to solicit your early feedback. This approach was designed in discussions at the Fourth OAuth Security Workshop and is captured in a new individual draft specification for Demonstration of Proof-of-Possession (DPoP) intended for the OAuth working group. The abstract of the new 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 to detect replay attacks with access and refresh tokens.

The specification is still an early draft and undergoing active development, but I believe the approach shows a lot of promise and is likely to be adopted by the OAuth working group soon. It works by creating a proof-of-possession signature over an access token or refresh token that would otherwise be a bearer token. And there’s already one implementation that I’m aware of – by Filip Skokan of Auth0. Let us know what you think of this new work!

The specification is available at:

An HTML-formatted version is also available at:

March 27, 2019
Working group adoption of “COSE and JOSE Registrations for WebAuthn Algorithms”

IETF logoI’m pleased to report that the IETF COSE Working Group has adopted the specification “COSE and JOSE Registrations for WebAuthn Algorithms”. An abstract of what it does is:

This specification defines how to use several algorithms with COSE [RFC8152] that are used by implementations of the W3C Web Authentication (WebAuthn) [WebAuthn] and FIDO2 Client to Authenticator Protocol (CTAP) [CTAP] specifications. These algorithms are to be registered in the IANA “COSE Algorithms” registry [IANA.COSE.Algorithms] and also in the IANA “JSON Web Signature and Encryption Algorithms” registry [IANA.JOSE.Algorithms], when not already registered there.

The algorithms registered are RSASSA-PKCS1-v1_5 with four different hash functions and signing with the secp256k1 curve. Note that there was consensus in the working group meeting not to work on registrations for the Elliptic Curve Direct Anonymous Attestation (ECDAA) algorithms “ED256” and “ED512”, both because of issues that have been raised with them and because they are not in widespread use.

The -01 version will address the review comments received on the mailing list from Jim Schaad and John Mattsson.

The specification is available at:

An HTML-formatted version is also available at:

March 12, 2019
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:

March 11, 2019
OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”

OAuth logoResponding to feedback from multiple parties that the title “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices” was too much of a mouthful, the title of the specification has been simplified to “OAuth 2.0 Device Authorization Grant”. Likewise, we received feedback that “Device flow” was an insider term that caused more confusion than clarity, so its use has been removed from the specification. Finally, last minute feedback was received that client authorization and error handling were not explicitly spelled out. The specification now says that these occur in the same manner as in OAuth 2.0 [RFC 6749].

Many thanks to William Denniss for performing these edits! Hopefully this will be the draft that is sent to the RFC Editor.

The specification is available at:

An HTML-formatted version is also available at:

March 11, 2019
Additional COSE algorithms used by W3C Web Authentication (WebAuthn)

IETF logoThe new COSE working group charter includes this deliverable:

4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point (Informational).

I have written draft-jones-cose-additional-algorithms, which combines these starting points into a single draft, which registers these algorithms in the IANA COSE registries. When not already registered, this draft also registers these algorithms for use with JOSE in the IANA JOSE registries. I believe that this draft is ready for working group adoption to satisfy this deliverable.

The specification is available at:

An HTML-formatted version is also available at:

March 9, 2019
FIDO2 Client to Authenticator Protocol (CTAP) standard published

FIDO logoI’m thrilled to report that the FIDO2 Client to Authenticator Protocol (CTAP) is now a published FIDO Alliance standard! Together with the now-standard Web Authentication (WebAuthn) specification, this completes standardization of the APIs and protocols needed to enable password-less logins on the Web, on PCs, and on and mobile devices. This is a huge step forward for online security, privacy, and convenience!

The FIDO2 CTAP standard is available in HTML and PDF versions at these locations:

March 4, 2019
The W3C Web Authentication (WebAuthn) specification is now a standard!

W3C logoI’m thrilled to report that the Web Authentication (WebAuthn) specification is now a W3C standard! See the W3C press release describing this major advance in Web security and convenience, which enables logging in without passwords. Alex Simons, Microsoft Vice President of Identity Program Management is quoted in the release, saying:

“Our work with W3C and FIDO Alliance, and contributions to FIDO2 standards have been a critical piece of Microsoft’s commitment to a world without passwords, which started in 2015. Today, Windows 10 with Microsoft Edge fully supports the WebAuthn standard and millions of users can log in to their Microsoft account without using a password.”

The release also describes commitments to the standard by Google, Mozilla, and Apple, among others. Thanks to all who worked on the standard and who built implementations as we developed the standard – ensuring that that the standard can be used for a broad set of use cases, including password-less sign-in with platform authenticators, mobile devices, and security keys.

Next »