The “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to add explanatory comments on design decisions made that were discussed on the mailing list that Jim Schaad requested be added to the draft.
The specification is available at:
An HTML-formatted version is also available at:
I’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:
The “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:
I’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:
A 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:
A 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:
The 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:
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.
The specification is available at:
An HTML-formatted version is also available at:
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.
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:
The 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:
I’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:
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 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.
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.
The specification is available at:
An HTML-formatted version is also available at:
The World Wide Web Consortium (W3C) has published a Proposed Recommendation (PR) for the Web Authentication (WebAuthn) specification, bringing WebAuthn one step closer to becoming a completed standard. The Proposed Recommendation is at https://www.w3.org/TR/2019/PR-webauthn-20190117/.
The PR contains only clarifications and editorial improvements to the second Candidate Recommendation (CR), with no substantial changes. The next step will be to publish a Recommendation – a W3C standard – based on the Proposed Recommendation.
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 specification is available at:
An HTML-formatted version is also available at:
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 specification is available at:
An HTML-formatted version is also available at:
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.
The specification is available at:
An HTML-formatted version is also available at:
W3C has published a second W3C Candidate Recommendation (CR) for the Web Authentication (WebAuthn) specification. The second Candidate Recommendation is at https://www.w3.org/TR/2018/CR-webauthn-20180807/.
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.
Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.
This document is a companion document to The Token Binding Protocol.
This is a huge step towards cryptographically protecting data structures that had previously been bearer tokens, such as browser cookies, refresh tokens, access tokens, ID Tokens, etc., so that they can only be used by the intended party. Congratulations especially to the editors Andrei Popov, Dirk Balfanz, and Jeff Hodges, as well as the chairs John Bradley and Leif Johansson for getting us to this important milestone!
The three specifications are:
The OpenID Connect Token Bound Authentication specification has been updated in response to developer feedback and in anticipation of the IETF Token Binding specifications finishing. Changes were:
tbh” value doesn’t include any trailing pad characters, line breaks, whitespace, etc.(The representation of the Token Binding ID in the ID Token is unchanged.)
Thanks to Brian Campbell for doing the editing for this draft.
The specification is available at:
Powered by WordPress & Theme by Anders Norén