The IESG approved the “Using RSA Algorithms with COSE Messages” specification for publication as an RFC today. A new version was published incorporating the IESG feedback. Thanks to Ben Campbell, Eric Rescorla, and Adam Roach for their review comments. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
A new version of the “Using RSA Algorithms with COSE Messages” specification has been published that addresses the IETF last call feedback received. Additional security considerations were added and the IANA Considerations instructions were made more precise. Thanks to Roni Even and Steve Kent for their useful reviews!
The specification is available at:
An HTML-formatted version is also available at:
JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) functions underlying them are now being widely used in diverse sets of applications. During IETF 98 in Chicago, we discussed reports of people implementing and using JOSE and JWTs insecurely, the causes of these problems, and ways to address them. Part of this discussion was an invited JOSE/JWT Security Update presentation that I gave to two working groups, which included links to problem reports and described mitigations. Citing the widespread use of JWTs in new IETF applications, Security Area Director Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written for JSON Web Tokens (JWTs).
I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have produced an initial draft of a JWT BCP. Its abstract is:
JSON Web Tokens, also known as JWTs [RFC7519], 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.
In Section 2, we describe threats and vulnerabilities. In Section 3, we describe best practices addressing those threats and vulnerabilities. We believe that the best practices in Sections 3.1 through 3.8 are ready to apply today. Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) describes several possible best practices on that topic to serve as a starting point for a discussion on which of them we want to recommend under what circumstances.
We invite input from the OAuth Working Group and other interested parties on what best practices for JSON Web Tokens and the JOSE functions underlying them should be. We look forward to hearing your thoughts and working on this specification together.
The specification is available at:
An HTML-formatted version is also available at:
A slightly updated version of the “Using RSA Algorithms with COSE Messages” specification has been published in preparation for IETF last call. Changes were:
The specification is available at:
An HTML-formatted version is also available at:
I gave two presentations at the 2017 European Identity and Cloud Conference (EIC) on progress we’re making in creating and deploying important new identity and security standards. The presentations were:
(Photo from https://twitter.com/drummondreed/status/862314926433603584)
The W3C Web Authentication working group has published the fifth working draft of the W3C Web Authentication specification. It has a new title that’s more reflective of what it enables: “Web Authentication: An API for accessing Public Key Credentials“. Among other changes, the draft is now aligned with the W3C Credential Management API. Numerous issues were resolved and many improvements in the process of creating this release.
While not a candidate recommendation, this version is informally intended by the working group to be an Implementer’s Draft, which will be used for experimenting with implementations of the API.
Draft -02 of the OAuth Token Binding specification adds example protocol messages for every distinct flow and also adds token binding for authorization codes. A lot of this is informed by implementation work that Brian Campbell has been doing, who did most of the heavy lifting for this draft. Working group members are requested to give the new text a read before IETF 98 in Chicago and to have a look at the updated open issues list. The descriptions of some of the flows were also clarified, thanks to William Denniss.
The specification is available at:
An HTML-formatted version is also available at:
I’ve published an updated version of the “Using RSA Algorithms with COSE Messages” specification with a number of editorial improvements. Changes were:
The specification is available at:
An HTML-formatted version is also available at:
The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA algorithms with CBOR Object Signing and Encryption (COSE) messages. This supports use cases for the FIDO Alliance and others that need this functionality. Security Area Director Kathleen Moriarty has agreed to AD sponsorship of this specification. This specification incorporates text from draft-ietf-cose-msg-05 — the last COSE specification version before the RSA algorithms were removed.
The specification is available at:
An HTML-formatted version is also available at:
Review feedback is welcomed!
The OAuth Token Binding specification has been revised to use the Referred Token Binding ID when performing token binding of access tokens. This was enabled by the Implementation Considerations in the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enable using the Referred Token Binding ID in this manner. Protected Resource Metadata was also defined.
Thanks to Brian Campbell for clarifications on the differences between token binding of access tokens issued from the authorization endpoint versus those issued from the token endpoint.
The specification is available at:
An HTML-formatted version is also available at:
The initial working group draft of the OAuth Token Binding specification has been published. It has the same content as draft-jones-oauth-token-binding-00, but with updated references. This specification defines how to perform token binding for OAuth access tokens and refresh tokens. Note that the access token mechanism is expected to change shortly to use the Referred Token Binding, per working group discussions at IETF 96 in Berlin.
The specification is available at:
An HTML-formatted version is also available at:
The W3C Web Authentication working group has announced publication of the second public draft of the W3C Web Authentication specification. The working group expects to be issuing more frequent working drafts as we approach a Candidate Recommendation.
Two new related specifications define syntax and semantics for applying Token Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-token-bound-authentication-1_0 contains the OpenID Connect portions.
These are being submitted now to hopefully enable end-to-end implementations and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID Tokens across multiple platforms before the Token Binding specifications are finalized.
The OAuth specification is available at:
The OpenID Connect specification is available at:
Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell for reviews of earlier versions of these specifications and to Dirk Balfanz and William Denniss for some earlier discussions providing input to these specifications.
The W3C Web Authentication Working Group today announced publication of the First Public Working Draft of the W3C Web Authentication specification. The abstract of the specification is:
This specification defines an API that enables web pages to access WebAuthn compliant strong cryptographic credentials through browser script. Conceptually, one or more credentials are stored on an authenticator, and each credential is scoped to a single Relying Party. Authenticators are responsible for ensuring that no operation is performed without the user’s consent. The user agent mediates access to credentials in order to preserve user privacy. Authenticators use attestation to provide cryptographic proof of their properties to the relying party. This specification also describes a functional model of a WebAuthn compliant authenticator, including its signature and attestation functionality.
This specification is derived from the November 12, 2015 member submission of FIDO 2.0 Platform Specifications. Content from the three submitted specifications has been merged into a single Web Authentication specification, also incorporating changes agreed to by the Web Authentication working group. The working group intends to continue making timely progress, planning to publish a Candidate Recommendation by September 2016.
The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specification is now RFC 7800 — an IETF standard. The abstract describes the specification as:
This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of-possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.
Thanks to John Bradley, Hannes Tschofenig, and the OAuth working group for their work on this specification.
I have published draft-jones-cose-rsa, which defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. This addresses COSE Issue #21: Restore RSA-PSS and the “RSA” key type. The initial version of this specification incorporates text from draft-ietf-cose-msg-05 — the last COSE message specification version before the RSA algorithms were removed.
The specification is available at:
An HTML-formatted version is also available at:
The JWS Unencoded Payload Option specification is now RFC 7797 — an IETF standard. The abstract describes the specification as:
JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url-encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.
This option is used by including the header parameters "b64":false and "crit":["b64"]. JWTs never use this option.
The W3C approved the Web Authentication Working Group charter today and announced the first working group meeting, which will be on March 4, 2016 in San Francisco. The initial input to the working group was the member submission of FIDO 2.0 Platform Specifications.
JWS Unencoded Payload Option draft -09 addresses Stephen Farrell’s IESG review. In particular, the use of “crit” is now required with “b64“. This should be the version that is sent to the RFC Editor.
The specification is available at:
An HTML-formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -11 addresses Sec-Dir review comments by Chris Lonvick and ballot comments by Stephen Farrell. This should enable clearing the “point raised” status from yesterday’s IESG telechat and progressing the document to the RFC Editor.
The specification is available at:
An HTML-formatted version is also available at:
Powered by WordPress & Theme by Anders Norén