Archive for the 'Specifications' Category

February 28, 2021
Second Version of W3C Web Authentication (WebAuthn) advances to Proposed Recommendation (PR)

W3C logoThe World Wide Web Consortium (W3C) has published this Proposed Recommendation (PR) for the Web Authentication (WebAuthn) Level 2 specification, bringing the second version of WebAuthn one step closer to becoming a completed standard. While remaining compatible with the original standard, this second version adds additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format.

December 31, 2020
Near-Final Second W3C WebAuthn and FIDO2 CTAP Specifications

W3C logoFIDO logoThe W3C WebAuthn and FIDO2 working groups have been busy this year preparing to finish second versions of the W3C Web Authentication (WebAuthn) and FIDO2 Client to Authenticator Protocol (CTAP) specifications. While remaining compatible with the original standards, these second versions add additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format. Near-final review drafts of both have been published:

Expect these to become approved standards in early 2021. Happy New Year!

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:

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

Next »