Mike Jones: self-issued

Musings on Digital Identity

Category: Specifications Page 12 of 23

Initial ACE working group CBOR Web Token (CWT) specification

By

On May 20, 2016

In CBOR, Claims, Specifications

IETF logoWe have created the initial working group version of the CBOR Web Token (CWT) specification based on draft-wahlstroem-ace-cbor-web-token-00, with no normative changes. The abstract of the specification is:

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. 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.

Changes requested during the call for adoption will be published in the -01 version but we first wanted to publish a clean -00 working group draft.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800

By

On April 6, 2016

In Cryptography, JSON, OAuth, Specifications

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

Using RSA Algorithms with COSE Messages

By

On April 4, 2016

In CBOR, Cryptography, Specifications

IETF logoI 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:

OAuth 2.0 Token Exchange draft -04

By

On March 4, 2016

In Claims, JSON, OAuth, Specifications

OAuth logoA new draft of “OAuth 2.0 Token Exchange” has been published addressing review comments on the prior draft. The changes from -03 are listed here:

The specification is available at:

An HTML-formatted version is also available at:

Thanks to Brian Campbell for doing most of the edits for this release.

Tidied-up OAuth 2.0 Device Flow specification

By

On March 3, 2016

In OAuth, Specifications

OAuth logoThe OAuth 2.0 Device Flow specification has been tidied up to apply spelling and grammar corrections and add the Document History appendix. No normative changes were made. Again, if you’re using an OAuth device flow, please let us know whether your implementation matches this specification, and if not, let us know how it differs.

The specification is available at:

An HTML-formatted version is also available at:

JWS Unencoded Payload Option is now RFC 7797

By

On February 25, 2016

In Cryptography, JSON, Specifications

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

Initial OAuth working group Device Flow specification

By

On February 18, 2016

In OAuth, Specifications

OAuth logoThanks to William Denniss for creating the initial working group version of the OAuth 2.0 Device Flow specification. The abstract of the specification is:

The device flow is suitable for OAuth 2.0 clients executing on devices which do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs), but where the end-user has separate access to a user-agent on another computer or device (e.g., desktop computer, a laptop, a smart phone, or a tablet).

Note: This version of the document is a continuation of an earlier, long expired draft. The content of the expired draft has been copied almost unmodified. The goal of the work on this document is to capture deployment experience.

If you’re using an OAuth device flow, please let us know whether this specification matches your usage, and if not, how yours differs.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Discovery spec pared down to its essence

By

On February 17, 2016

In Claims, JSON, OAuth, Specifications

OAuth logoIn response to working group input, this version of the OAuth Discovery specification has been pared down to its essence — leaving only the features that are already widely deployed. Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it. The WebFinger discovery logic has been removed. The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.

Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.

The specification is available at:

An HTML-formatted version is also available at:

Authentication Method Reference Values spec incorporating adoption feedback

By

On February 11, 2016

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoThis draft of the Authentication Method Reference Values specification incorporates OAuth working group feedback from the call for adoption. The primary change was to remove the “amr_values” request parameter, so that “amr” values can still be returned as part of an authentication result, but cannot be explicitly requested. Also, noted that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no longer require a specification.

The specification is available at:

An HTML-formatted version is also available at:

Initial OAuth working group Discovery specification

By

On February 9, 2016

In Claims, JSON, OAuth, Specifications

OAuth logoWe have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.

The specification is available at:

An HTML-formatted version is also available at:

W3C Web Authentication Working Group

By

On February 8, 2016

In Cryptography, Specifications

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

OAuth Discovery metadata values added for revocation, introspection, and PKCE

By

On January 28, 2016

In Claims, JSON, OAuth, Specifications

OAuth logoThe OAuth Discovery specification has been updated to add metadata values for revocation, introspection, and PKCE. Changes were:

  • Added “revocation_endpoint_auth_methods_supported” and “revocation_endpoint_auth_signing_alg_values_supported” for the revocation endpoint.
  • Added “introspection_endpoint_auth_methods_supported” and “introspection_endpoint_auth_signing_alg_values_supported” for the introspection endpoint.
  • Added “code_challenge_methods_supported” for PKCE.

The specification is available at:

An HTML-formatted version is also available at:

Second OAuth 2.0 Mix-Up Mitigation Draft

By

On January 20, 2016

In OAuth, Specifications

OAuth logoJohn Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft. Changes were:

  • Simplified by no longer specifying the signed JWT method for returning the mitigation information.
  • Simplified by no longer depending upon publication of a discovery metadata document.
  • Added the “state” token request parameter.
  • Added examples.
  • Added John Bradley as an editor.

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 Mix-Up Mitigation

By

On January 11, 2016

In OAuth, Specifications

OAuth logoYesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up. This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory. The abstract of the specification is:

This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata about itself. This information is returned in the authorization response. It can be used by the client to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as “IdP Mix-Up” and “Malicious Endpoint” attacks.

The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one. Note that these attacks can only be made against clients that are configured to use more than one authorization server.

Please give the draft a quick read and provide feedback to the OAuth working group. This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution. Please definitely read the Security Considerations and Open Issues sections, as they contain important information about the choices made and the decisions remaining.

Special thanks go to Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations. Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.

The specification is available at:

An HTML-formatted version is also available at:

JWS Unencoded Payload Option spec addressing Stephen Farrell’s review

By

On December 23, 2015

In Cryptography, JSON, Specifications

IETF logoJWS 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 spec addressing remaining comments

By

On December 18, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoProof-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:

JWS Unencoded Payload Option spec for IESG telechat

By

On December 17, 2015

In Cryptography, JSON, Specifications

IETF logoJWS Unencoded Payload Option draft -08 was published for consideration on the IESG telechat later today. The changes addressed Gen-Art review comments by Robert Sparks, Ops-Dir review comments by Stefan Winter, and ballot comments by Benoit Claise and Ben Campbell. Normative text was added describing the use of “crit” with “b64“.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for JWTs spec for IESG telechat

By

On December 17, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoProof-of-Possession Key Semantics for JWTs draft -10 was published for consideration on the IESG telechat later today. All changes were editorial and addressed ballot comments by Barry Leiba.

The specification is available at:

An HTML-formatted version is also available at:

Authentication Method Reference Values coordination with OpenID MODRNA

By

On December 15, 2015

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoAuthentication Method Reference Values draft -04 added the values “face” (facial recognition), “geo” (geolocation), “hwk” (proof-of-possession of a hardware-secured key), “pin” (Personal Identification Number or pattern), and “swk” (proof-of-possession of a software-secured key), and removed the value “pop” (proof-of-possession), based on input from members of the OpenID Foundation MODRNA working group.

The specification is available at:

An HTML formatted version is also available at:

OAuth 2.0 Token Exchange: An STS for the REST of Us

By

On December 14, 2015

In Claims, JSON, OAuth, Specifications

OAuth logoI’m happy to report that a substantially revised OAuth 2.0 Token Exchange draft has been published that enables a broad range of use cases, while still remaining as simple as possible. This draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working group input from the in-person discussions in Prague and mailing list discussions. Thanks to all for your interest in and contributions to OAuth Token Exchange! Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this draft.

The core functionality remains token type independent. That said, new claims are also defined to enable representation of delegation actors in JSON Web Tokens (JWTs). Equivalent claims could be defined for other token types by other specifications.

See the Document History section for a summary of the changes made. Please check it out!

The specification is available at:

An HTML-formatted version is also available at:

Page 12 of 23

Previous

Next

Powered by WordPress & Theme by Anders Norén