Mike Jones: self-issued

Musings on Digital Identity

Category: Claims Page 5 of 13

Initial JSON Web Token Best Current Practices Draft

By

On June 4, 2017

In Claims, Cryptography, JSON, OAuth, Specifications

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

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

By

On April 20, 2017

In CBOR, Claims, Specifications

IETF logoWith the CBOR Web Token (CWT) specification nearing completion, which provides the CBOR equivalent of JWTs, I thought that it was also time to introduce the CBOR equivalent of RFC 7800, “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)”, so that applications using CWTs will have a standard representation for proof-of-possession keys. I know that PoP keys are important to ACE applications, for instance. I therefore took RFC 7800 and produced the CBOR/CWT equivalent of it.

The specification is available at:

An HTML-formatted version is also available at:

CBOR Web Token (CWT) specification correcting inconsistencies in examples

By

On April 13, 2017

In CBOR, Claims, Specifications

IETF logoA revised CBOR Web Token (CWT) draft has been published that corrects inconsistencies in the examples. Thanks to Jim Schaad for validating the examples and pointing out the inconsistencies and to Samuel Erdtman for fixing them. As before, people are highly encouraged to validate the updated examples.

The specification is available at:

An HTML-formatted version is also available at:

AMR Values specification addressing Stephen Farrell’s comments

By

On March 13, 2017

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoSecurity area director Stephen Farrell had asked us to make it as clear as possible to people who might be registering new “amr” values that names can identify families of closely-related authentication methods. This is now said right in the IANA Registration Template, so that people who might not have read the spec can’t miss it.

FYI, all the previous IESG DISCUSSes have now been cleared, so hopefully that means this is the last version to be published before the Authentication Method Reference Values specification becomes an RFC.

Thanks again to Stephen for his always-thorough reviews of the specification.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata spec incorporating WGLC feedback

By

On March 10, 2017

In Claims, JSON, OAuth, Specifications

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to incorporate the working group last call feedback received. Thanks to William Denniss and Hannes Tschofenig for their reviews. Use of the “https” scheme for the “jwks_uri” URL is now required. The precedence of signed metadata values over unsigned values was clarified. Unused references were removed.

The specification is available at:

An HTML-formatted version is also available at:

CBOR Web Token (CWT) with better examples and a CBOR tag

By

On March 2, 2017

In CBOR, Claims, Specifications

IETF logoA new CBOR Web Token (CWT) draft is available with completely rewritten and much more useful examples, thanks to Samuel Erdtman. There are now examples of signed, MACed, encrypted, and nested CWTs that use all of the defined claims (and no claims not yet defined). A CBOR tag for CWTs is now also defined. People are highly encouraged to review the new examples and validate them.

The specification is available at:

An HTML-formatted version is also available at:

AMR Values specification addressing IESG comments

By

On February 28, 2017

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoThe Authentication Method Reference Values specification has been updated to address feedback from the IESG. Identifiers are now restricted to using only printable JSON-friendly ASCII characters. All the “amr” value definitions now include specification references.

Thanks to Stephen Farrell, Alexey Melnikov, Ben Campbell, and Jari Arkko for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

“amr” Values specification addressing IETF last call comments

By

On January 24, 2017

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoDraft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:

  • Specified characters allowed in “amr” values, reusing the IANA Considerations language on this topic from RFC 7638.
  • Added several individuals to the acknowledgements.

Thanks to Linda Dunbar, Catherine Meadows, and Paul Kyzivat for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata decoupled from OAuth Protected Resource Metadata

By

On January 19, 2017

In Claims, JSON, OAuth, Specifications

OAuth logoThe IETF OAuth working group decided at IETF 97 to proceed with standardizing the OAuth Authorization Server Metadata specification, which is already in widespread use, and to stop work on the OAuth Protected Resource Metadata specification, which is more speculative. Accordingly, a new version of the AS Metadata spec has been published that removes its dependencies upon the Resource Metadata spec. In particular, the “protected_resources” AS Metadata element has been removed. Its definition has been moved to the Resource Metadata spec for archival purposes. Note that the Resource Metadata specification authors intend to let it expire unless the working group decides to resume work on it at some point in the future.

The specifications are available at:

HTML-formatted versions are also available at:

Media Type registration added to CBOR Web Token (CWT)

By

On January 13, 2017

In CBOR, Claims, Specifications

IETF logoThe CBOR Web Token (CWT) specification now registers the “application/cwt” media type, which accompanies the existing CoAP Content-Format ID registration for this media type. The description of nested CWTs, which uses this content type, was clarified. This draft also corrected some nits identified by Ludwig Seitz.

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) Specification and IETF Security Events Working Group

By

On November 23, 2016

In Claims, JSON, OpenID, Specifications

IETF logoAs those of you who have been following the id-event@ietf.org mailing list or attended the inaugural meeting of the new IETF Security Events working group know, Phil Hunt and co-authors (including myself) have been working on a Security Event Token (SET) specification. A SET is a JSON Web Token (JWT) with an “events” claim that contains one or more event identifiers (which are URIs) that say what event the SET describes.

This work isn’t being done in isolation. Among others, the OpenID Risk and Incident Sharing and Coordination (RISC) working group, the OpenID Back-Channel Logout specification, and the SCIM Provisioning Events work intend to use the Security Event Token format.

To make this concrete, the claims in an example OpenID Connect Back-Channel Logout token (which is a SET) are:

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  }
}

You’ll see that this a normal JWT, with the issuer, subject, and session ID identifying the target of the logout, and the “events” value identifying the JWT as a logout SET.

Today, we published an updated SET spec based on discussions at IETF 97, which simplifies the SET parsing. Thanks to Phil Hunt or Oracle, William Denniss of Google, Morteza Ansari of Cisco, and the numerous other contributors who’ve gotten us to this point. We now believe that this specification is ready for adoption by the Security Events working group.

The specification is available at:

An HTML-formatted version is also available at:

The OpenID Connect Back-Channel Logout specification should be updated soon (after the US Thanksgiving holiday) to utilize the simplified SET syntax. Happy Thanksgiving, everyone!

“amr” Values specification addressing area director comments

By

On November 13, 2016

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoDraft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:

  • Added “amr” claim examples with both single and multiple values.
  • Clarified that the actual credentials referenced are not part of this specification to avoid additional privacy concerns for biometric data.
  • Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to applications using this specification.

The specification is available at:

An HTML-formatted version is also available at:

“amr” Values specification addressing shepherd comments

By

On October 14, 2016

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoDraft -03 of the Authentication Method Reference Values specification addresses the shepherd comments. It changes the references providing information about specific “amr” values to be informative, rather than normative. A reference to ISO/IEC 29115 was also added. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

“amr” Values specification addressing WGLC comments

By

On September 9, 2016

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoDraft -02 of the Authentication Method Reference Values specification addresses the Working Group Last Call (WGLC) comments received. It adds an example to the multiple-channel authentication description and moves the “amr” definition into the introduction. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Metadata Specifications Enhanced

By

On August 3, 2016

In Claims, JSON, OAuth, Specifications

OAuth logoThe existing OAuth 2.0 Authorization Server Metadata specification has now been joined by a related OAuth 2.0 Protected Resource Metadata specification. This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT). This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration. Signed metadata can also be used for protected resource metadata.

For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the “protected_resources” metadata value to list them. Likewise, the protected resource metadata specification defines an “authorization_servers” metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.

The specifications are available at:

HTML-formatted versions are also available at:

“amr” Values specification distinguishing between iris and retina scan biometrics

By

On July 8, 2016

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoThis draft distinguishes between iris and retina scan biometrics, as requested by NIST, and adds a paragraph providing readers more context at the end of the introduction, which was requested by the chairs during the call for adoption. The OpenID Connect MODRNA Authentication Profile 1.0 specification, which uses “amr” values defined by this specification, is now also referenced.

The specification is available at:

An HTML formatted version is also available at:

IANA Considerations added to CBOR Web Token (CWT)

By

On July 7, 2016

In CBOR, Claims, Specifications

IETF logoThe CBOR Web Token (CWT) specification now establishes the IANA CWT Claims registry and registers the CWT claims defined by the specification. The application/cwt CoAP content type is now also registered.

This version adds Samuel Erdtman as an editor in recognition of his already significant contributions to the specification.

The specification is available at:

An HTML-formatted version is also available at:

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:

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.

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:

Page 5 of 13

Previous

Next

Powered by WordPress & Theme by Anders Norén