Archive for the 'IETF' Category

May 16, 2022
JWK Thumbprint URI Draft Addressing IETF Last Call Comments

OAuth logoKristina Yasuda and I have published a new JWK Thumbprint URI draft that addresses the IETF Last Call comments received. Changes made were:

  • Clarified the requirement to use registered hash algorithm identifiers.
  • Acknowledged IETF Last Call reviewers.

The specification is available at:

May 4, 2022
OAuth DPoP Specification Addressing WGLC Comments

OAuth logoBrian Campbell has published an updated OAuth DPoP draft addressing the Working Group Last Call (WGLC) comments received. All changes were editorial in nature. The most substantive change was further clarifying that either iat or nonce can be used alone in validating the timeliness of the proof, somewhat deemphasizing jti tracking.

As Brian reminded us during the OAuth Security Workshop today, the name DPoP was inspired by a Deutsche POP poster he saw on the S-Bahn during the March 2019 OAuth Security Workshop in Stuttgart:

Deutsche POP in Stuttgart

He considered it an auspicious sign seeing another Deutsche PoP sign in the Vienna U-Bahn during IETF 113 the same day WGLC was requested!

Deutsche POP in Vienna

The specification is available at:

March 5, 2022
Two new COSE- and JOSE-related Internet Drafts with Tobias Looker

IETF logoThis week, Tobias Looker and I submitted two individual Internet Drafts for consideration by the COSE working group.

The first is “Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE“, the abstract of which is:


This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key).

These curves are used in Zero-Knowledge Proof (ZKP) representations for JOSE and COSE, where the ZKPs use the CFRG drafts “Pairing-Friendly Curves” and “BLS Signatures“.

The second is “CBOR Web Token (CWT) Claims in COSE Headers“, the abstract of which is:


This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload.

JWTs define a mechanism for replicating claims as header parameter values, but CWTs have been missing the equivalent capability to date. The use case is the same as that which motivated Section 5.3 of JWT “Replicating Claims as Header Parameters” – encrypted CWTs for which you’d like to have unencrypted instances of particular claims to determine how to process the CWT prior to decrypting it.

We plan to discuss both with the COSE working group at IETF 113 in Vienna.

March 3, 2022
Minor Updates to OAuth DPoP Prior to IETF 113 in Vienna

OAuth logoThe editors have applied some minor updates to the OAuth DPoP specification in preparation for discussion at IETF 113 in Vienna. Updates made were:

  • Renamed the always_uses_dpop client registration metadata parameter to dpop_bound_access_tokens.
  • Clarified the relationships between server-provided nonce values, authorization servers, resource servers, and clients.
  • Improved other descriptive wording.

The specification is available at:

February 20, 2022
Four Months of Refinements to OAuth DPoP

OAuth logoA new draft of the OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP) specification has been published that addresses four months’ worth of great review comments from the working group. Refinements made were:

  • Added Authorization Code binding via the dpop_jkt parameter.
  • Described the authorization code reuse attack and how dpop_jkt mitigates it.
  • Enhanced description of DPoP proof expiration checking.
  • Described nonce storage requirements and how nonce mismatches and missing nonces are self-correcting.
  • Specified the use of the use_dpop_nonce error for missing and mismatched nonce values.
  • Specified that authorization servers use 400 (Bad Request) errors to supply nonces and resource servers use 401 (Unauthorized) errors to do so.
  • Added a bit more about ath and pre-generated proofs to the security considerations.
  • Mentioned confirming the DPoP binding of the access token in the list in (#checking).
  • Added the always_uses_dpop client registration metadata parameter.
  • Described the relationship between DPoP and Pushed Authorization Requests (PAR).
  • Updated references for drafts that are now RFCs.

I believe this brings us much closer to a final version.

The specification is available at:

February 15, 2022
JWK Thumbprint URI Draft Addressing Working Group Last Call Comments

OAuth logoKristina Yasuda and I have published an updated JWK Thumbprint URI draft that addresses the OAuth Working Group Last Call (WGLC) comments received. Changes made were:

  • Added security considerations about multiple public keys coresponding to the same private key.
  • Added hash algorithm identifier after the JWK thumbprint URI prefix to make it explicit in a URI which hash algorithm is used.
  • Added reference to a registry for hash algorithm identifiers.
  • Added SHA-256 as a mandatory to implement hash algorithm to promote interoperability.
  • Acknowledged WGLC reviewers.

The specification is available at:

January 29, 2022
Working Group Adoption of the JWK Thumbprint URI Specification

OAuth logoThe IETF OAuth working group has adopted the JWK Thumbprint URI specification. The abstract of the specification is:

This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.

The need for this arose during specification work in the OpenID Connect working group. In particular, JWK Thumbprint URIs are used as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider v2 specification.

Given that the specification does only one simple thing in a straightforward manner, we believe that it is ready for working group last call.

The specification is available at:

January 12, 2022
Described more of the motivations for the JWK Thumbprint URI specification

OAuth logoAs requested by the chairs during today’s OAuth Virtual Office Hours call, Kristina Yasuda and I have updated the JWK Thumbprint URI specification to enhance the description of the motivations for the specification. In particular, it now describes using JWK Thumbprint URIs as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs. It is used this way in the Self-Issued OpenID Provider v2 specification, for instance. No normative changes were made.

As discussed on the call, we are requesting that that the chairs use this new draft as the basis for a call for working group adoption.

The specification is available at:

November 24, 2021
JWK Thumbprint URI Specification

IETF logoThe JSON Web Key (JWK) Thumbprint specification [RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517] and encoding that hash in a URL-safe manner. Kristina Yasuda and I have just created the JWK Thumbprint URI specification, which defines how to represent JWK Thumbprints as URIs. This enables JWK Thumbprints to be communicated in contexts requiring URIs, including in specific JSON Web Token (JWT) [RFC 7519] claims.

Use cases for this specification were developed in the OpenID Connect Working Group of the OpenID Foundation. Specifically, its use is planned in future versions of the Self-Issued OpenID Provider v2 specification.

The specification is available at:

October 6, 2021
Server-contributed nonces added to OAuth DPoP

OAuth logoThe latest version of the “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)” specification adds an option for servers to supply a nonce value to be included in the DPoP proof. Both authorization servers and resource servers can provide nonce values to clients.

As described in the updated Security Considerations, the nonce prevents a malicious party in control of the client (who might be a legitimate end-user) from pre-generating DPoP proofs to be used in the future and exfiltrating them to a machine without the DPoP private key. When server-provided nonces are used, actual possession of the proof-of-possession key is being demonstrated — not just possession of a DPoP proof.

The specification is available at:

August 21, 2021
OAuth 2.0 JWT-Secured Authorization Request (JAR) is now RFC 9101

IETF logoThe OAuth 2.0 JWT-Secured Authorization Request (JAR) specification has been published as RFC 9101. Among other applications, this specification is used by the OpenID Financial-grade API (FAPI). This is another in the series of RFCs bringing OpenID Connect-defined functionality to OAuth 2.0. Previous such RFCs included “OAuth 2.0 Dynamic Client Registration Protocol” [RFC 7591] and “OAuth 2.0 Authorization Server Metadata” [RFC 8414].

The abstract of the RFC is:


The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.


This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

Thanks to Nat Sakimura and John Bradley for persisting in finishing this RFC!

April 21, 2021
OAuth 2.0 JWT Secured Authorization Request (JAR) sent back to the RFC Editor

OAuth logoAs described in my last post about OAuth JAR, after it was first sent to the RFC Editor, the IESG requested an additional round of IETF feedback. I’m happy to report that, having addressed this feedback, the spec has now been sent back to the RFC Editor.

As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications – and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

March 19, 2021
OAuth 2.0 JWT Secured Authorization Request (JAR) updates addressing remaining review comments

OAuth logoAfter the OAuth 2.0 JWT Secured Authorization Request (JAR) specification was sent to the RFC Editor, the IESG requested an additional round of IETF feedback. We’ve published an updated draft addressing the remaining review comments, specifically, SecDir comments from Watson Ladd. The only normative change made since the 28 was to change the MIME Type from “oauth.authz.req+jwt” to “oauth-authz-req+jwt”, per advice from the designated experts.

As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications – and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

December 31, 2020
SecEvent Delivery specs are now RFCs 8935 and 8936

IETF logoThe SecEvent Delivery specifications, “Push-Based Security Event Token (SET) Delivery Using HTTP” and “Poll-Based Security Event Token (SET) Delivery Using HTTP”, are now RFC 8935 and RFC 8936. Both deliver Security Event Tokens (SETs), which are defined by RFC 8417. The abstracts of the specifications are:

Push-Based Security Event Token (SET) Delivery Using HTTP:

This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response.

Poll-Based Security Event Token (SET) Delivery Using HTTP:

This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient’s need for assurance.

These were designed with use cases such as Risk & Incident Sharing and Collaboration (RISC) and Continuous Access Evaluation Protocol (CAEP) in mind, both of which are happening in the OpenID Shared Signals and Events Working Group.

November 20, 2020
Concise Binary Object Representation (CBOR) Tags for Date is now RFC 8943

IETF logoThe Concise Binary Object Representation (CBOR) Tags for Date specification has now been published as RFC 8943. 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 has been created by this RFC. The abstract of the RFC is:


The Concise Binary Object Representation (CBOR), as specified in 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 (date/time string as per RFC 3339) and tag 1 (POSIX “seconds since the epoch”). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined.

Note that a gifted musical singer/songwriter appears in this RFC in a contextually appropriate fashion, should you need an additional incentive to read the specification. ;-)

August 28, 2020
Concise Binary Object Representation (CBOR) Tags for Date progressed to IESG Evaluation

IETF logoThe “Concise Binary Object Representation (CBOR) Tags for Date” specification has completed IETF last call and advanced to evaluation by the Internet Engineering Steering Group (IESG). This is the specification that defines 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.

The specification is available at:

An HTML-formatted version is also available at:

August 20, 2020
OAuth 2.0 JWT Secured Authorization Request (JAR) sent to the RFC Editor

OAuth logoCongratulations to Nat Sakimura and John Bradley for progressing the OAuth 2.0 JWT Secured Authorization Request (JAR) specification from the working group through the IESG to the RFC Editor. This specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications – and intentionally does so without introducing breaking changes.

This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

Again, congratulations to Nat and John and the OAuth Working Group for this achievement!

August 14, 2020
COSE and JOSE Registrations for Web Authentication (WebAuthn) Algorithms is now RFC 8812

IETF logoThe W3C Web Authentication (WebAuthn) working group and the IETF COSE working group created “CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms” to make some algorithms and elliptic curves used by WebAuthn and FIDO2 officially part of COSE and JOSE. The RSA algorithms are used by TPMs. The “secp256k1” curve registered (a.k.a., the Bitcoin curve) is also used in some decentralized identity applications. The completed specification has now been published as RFC 8812.

As described when the registrations recently occurred, 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

See them in the IANA COSE Registry and the IANA JOSE Registry.

August 11, 2020
Registries for Web Authentication (WebAuthn) is now RFC 8809

IETF logoThe W3C Web Authentication (WebAuthn) working group created the IETF specification “Registries for Web Authentication (WebAuthn)” to establish registries needed for WebAuthn extension points. These IANA registries were populated in June 2020. Now the specification creating them has been published as RFC 8809.

Thanks again to Kathleen Moriarty and Benjamin Kaduk for their Area Director sponsorships of the specification and to Jeff Hodges and Giridhar Mandyam for their work on it.

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:

Next »