The “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.
I’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.
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.
I’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 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address issues identified by Roman Danyliw while writing his shepherd review. Thanks to Samuel Erdtman for fixing an incorrect example.
Key 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 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 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.
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.
The 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.
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,
The JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the Working Group Last Call (WGLC) feedback received. Thanks to Neil Madden for his numerous comments and to Carsten Bormann and Brian Campbell for their reviews.
Assuming the chairs concur, the next step should be to request publication.
The “CBOR Web Token (CWT)” specification is now RFC 8392 – an IETF standard. The abstract for the specification is:
CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.
I’m pleased to report that a public Implementation Draft of the FIDO2 Client to Authenticator Protocol (CTAP) specification has been published. This specification enables FIDO2 clients, such as browsers implementing the W3C Web Authentication (WebAuthn) specification, to perform authentication using pairwise public/private key pairs securely held by authenticators speaking the CTAP protocol (rather than passwords). Use of three transports for communicating with authenticators is specified in the CTAP specification: USB Human Interface Device (USB HID), Near Field Communication (NFC), and Bluetooth Smart/Bluetooth Low Energy Technology (BLE).
This specification was developed in parallel with WebAuthn, including having a number of common authors. This CTAP version is aligned with the WebAuthn Candidate Recommendation (CR) version.
The WebAuthn working group has published the “COSE Algorithms for Web Authentication (WebAuthn)” specification, which registers COSE algorithm identifiers for RSASSA-PKCS1-v1_5 signature algorithms with SHA-2 and SHA-1 hash algorithms. RSASSA-PKCS1-v1_5 with SHA-256 is used by several kinds of authenticators. RSASSA-PKCS1-v1_5 with SHA-1, while deprecated, is used by some Trusted Platform Modules (TPMs). See https://www.iana.org/assignments/cose/cose.xhtml#algorithms for the actual IANA registrations.
Thanks to John Fontana, Jeff Hodges, Tony Nadalin, Jim Schaad, Göran Selander, Wendy Seltzer, Sean Turner, and Samuel Weiler for their roles in registering these algorithm identifiers.
This milestone represents a huge step towards enabling logins to occur using privacy-preserving public/private key pairs securely held by authenticators, rather than passwords. Its contents have been informed by what we learned during several rounds of interop testing by multiple browser and authenticator vendors. The Web Authentication spec has also progressed in parallel with and been kept in sync with the FIDO2 Client To Authenticator Protocol (CTAP) specification, so that they work well together.