Mike Jones: self-issued

Musings on Digital Identity

Author: Mike Jones Page 16 of 33

Building the Internet's missing identity layer

CBOR Web Token (CWT)

By

On November 12, 2015

In CBOR, Claims, Cryptography, Specifications

IETF logoI know that some of you have been following the IETF’s work on the CBOR Object Signing and Encryption (COSE) Working group on creating a Concise Binary Object Representation (CBOR) equivalent of the JSON-based cryptographic data formats produced by the JSON Object Signing and Encryption (JOSE) Working group. I’m happy to announce that work has now started on a CBOR Web Token (CWT) specification: a CBOR mapping of the JSON Web Token (JWT) security token format that was built using the JOSE specifications. While I expect JSON and the JOSE/JWT specs to continue be used in most Web, PC, phone, tablet, cloud, and enterprise contexts, the COSE specs and now CWT are designed for use in constrained environments, such as those for some Internet of Things (IoT) devices.

Just as it was important to have a JSON-based security token format for applications using JSON, it will be important to have a CBOR-based security token format for applications using CBOR. CBOR Web Token (CWT) fills that role. Note that what is actually defined is a general cryptographically secured CBOR data structure, enabling CWTs to be used as general application payloads for CBOR-based applications.

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.

My thanks to Erik Wahlström and Hannes Tschofenig for helping to make this happen!

Finally, I’ll note that just as the suggested pronunciation of JWT is the same as the English word “jot”, the suggested pronunciation of CWT is the same as the English word “cot”. So welcome to “cots”!

The specification is available at:

An HTML formatted version is also available at:

JWS Unencoded Payload Option spec addressing shepherd comments

By

On November 11, 2015

In Cryptography, JSON, Specifications

IETF logoDraft -04 of the JWS Unencoded Payload Option specification addresses the shepherd comments. Thanks to Jim Schaad for his careful review. The primary change was adding additional security considerations text, including describing when “crit” should be used.

The specification is available at:

An HTML formatted version is also available at:

Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

By

On November 4, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoProof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining document shepherd comment – adding use case diagrams to the introduction.

The updated specification is available at:

An HTML formatted version is also available at:

Proof-of-Possession Key Semantics for JWTs spec addressing document shepherd comments

By

On October 19, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoProof-of-Possession Key Semantics for JWTs draft -05 addresses Kepeng Li’s document shepherd comments (other than adding some use case diagrams in the introduction, which will happen soon).

The updated specification is available at:

An HTML formatted version is also available at:

JWS Unencoded Payload Option spec addressing WGLC comments

By

On October 13, 2015

In Cryptography, JSON, Specifications

IETF logoDraft -03 of the JWS Unencoded Payload Option specification addresses the working group last call comments received. Thanks to Jim Schaad, Vladimir Dzhuvinov, John Bradley, and Nat Sakimura for the useful comments. Changes were:

  • Allowed the ASCII space character and all printable ASCII characters other than period (‘.’) in non-detached unencoded payloads using the JWS Compact Serialization.
  • Updated the abstract to say that that the spec updates RFC 7519.
  • Removed unused references.
  • Changed the change controller to IESG.

The specification is available at:

An HTML formatted version is also available at:

ADFS Achieves Key OpenID Connect Certifications

By

On October 8, 2015

In Interoperability, OpenID, Software

OpenID Certified logoI wanted to bring your attention to Alex Simons’ announcement Active Directory Federation Services gains OpenID Certifications! ADFS now is certified for the Basic OpenID Provider and Implicit OpenID Provider profiles of OpenID Connect — adding to its previous certification for the OpenID Provider Publishing Configuration Information profile. I’ll also add that ADFS was tested for “response_type=code id_token” and passed all those tests as well.

My congratulations both to the ADFS team and to the other teams worldwide that have recently certified their OpenID Providers. See the current OpenID Certification results at http://openid.net/certification/. Watch that space for more results to come!

JWS Unencoded Payload Option -02

By

On September 13, 2015

In Cryptography, JSON, Specifications

IETF logoDraft -02 of the JWS Unencoded Payload Option specification makes these updates:

  • Required that “b64” be integrity protected.
  • Stated that if the JWS has multiple signatures and/or MACs, the “b64” Header Parameter value MUST be the same for all of them.
  • Stated that if applications use content encoding, they MUST specify whether the encoded or unencoded payload is used as the JWS Payload value.
  • Reorganized the Unencoded Payload Content Restrictions section.
  • Added an “updates” clause for RFC 7519 because this specification prohibits JWTs from using "b64":false.

Thanks for the working group feedback that resulted in these improvements.

The specification is available at:

An HTML formatted version is also available at:

OpenID Connect Back-Channel Logout Specification

By

On September 9, 2015

In Federation, OpenID, Specifications

OpenID logoA new back-channel OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-backchannel-1_0.html. This can coexist with or be used instead of the front-channel-based Session Management and HTTP-Based Logout specifications.

The abstract for the new specification states:

This specification defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.

This completes publication of the three planned OpenID Connect logout mechanisms: two that communicate on the front-channel through the User Agent (browser) and this one that communicates on the back-channel, without involving the User Agent. See the Introduction for a discussion of the upsides and downsides of the different logout approaches. As much as we’d like there to be a single logout solution, both experience and extensive discussions led us to the conclusion that there isn’t a feasible one-size-fits-all approach.

Reviews of the new (and existing!) specifications are welcomed.

Thanks to John Bradley, Pedro Felix, Nat Sakimura, Brian Campbell, and Todd Lainhart for their contributions to the creation of the specification.

JSON Web Key (JWK) Thumbprint is now RFC 7638

By

On September 8, 2015

In Cryptography, JSON, OpenID, Specifications

IETF logoThe JSON Web Key (JWK) Thumbprint specification is now RFC 7638 — an IETF standard. The abstract describes the specification as follows:

This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.

Thanks to James Manger, John Bradley, and Nat Sakimura, all of whom participated in security discussions that led to the creation of this specification. Thanks also to the JOSE working group members, chairs, area directors, and other IETF members who contributed to the specification.

A JWK Thumbprint is used as the “sub” (subject) claim value in OpenID Connect self-issued ID Tokens.

Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments

By

On August 28, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoProof-of-Possession Key Semantics for JWTs draft -04 addresses the remaining working group comments received — both a few leftover WGLC comments and comments received during IETF 93 in Prague. The changes were:

  • Allowed the use of “jwk” for symmetric keys when the JWT is encrypted.
  • Added the “jku” (JWK Set URL) member.
  • Added privacy considerations.
  • Reordered sections so that the “cnf” (confirmation) claim is defined before it is used.
  • Noted that applications can define new claim names, in addition to “cnf“, to represent additional proof-of-possession keys, using the same representation as “cnf“.
  • Applied wording clarifications suggested by Nat Sakimura.

The updated specification is available at:

An HTML formatted version is also available at:

“amr” values “rba” and “sc”

By

On August 21, 2015

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoAuthentication Method Reference Values draft -02 changed the identifier for risk-based authentication from “risk” to “rba“, by popular acclaim, and added the identifier “sc” (smart card).

The specification is available at:

An HTML formatted version is also available at:

“amr” Values spec updated

By

On August 13, 2015

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoI’ve updated the Authentication Method Reference Values spec to incorporate feedback received from the OAuth working group. Changes were:

  • Added the values “mca” (multiple-channel authentication), “risk” (risk-based authentication), and “user” (user presence test).
  • Added citations in the definitions of Windows integrated authentication, knowledge-based authentication, risk-based authentication, multiple-factor authentication, one-time password, and proof-of-possession.
  • Alphabetized the values.
  • Added Tony Nadalin as an author and added acknowledgements.

The specification is available at:

An HTML formatted version is also available at:

JWS Unencoded Payload Option specification

By

On August 9, 2015

In Cryptography, JSON, Specifications

IETF logoThe former JWS Signing Input Options specification has been renamed to JWS Unencoded Payload Option to reflect that there is now only one JWS Signing Input option defined in the spec — the “b64”:false option. The “sph” option was removed by popular demand. I also added a section on unencoded payload content restrictions and an example using the JWS JSON Serialization.

The specification is available at:

An HTML formatted version is also available at:

JWS Signing Input Options initial working group draft

By

On July 23, 2015

In Cryptography, JSON, Specifications

IETF logoThe initial working group version of JWS Signing Input Options has been posted. It contains no normative changes from draft-jones-jose-jws-signing-input-options-00.

Let the working group discussions begin! I particularly call your attention to Martin Thomson’s review at http://www.ietf.org/mail-archive/web/jose/current/msg05158.html, Nat Sakimura’s review at http://www.ietf.org/mail-archive/web/jose/current/msg05189.html, and Matias Woloski’s review at http://www.ietf.org/mail-archive/web/jose/current/msg05191.html to start things off.

The specification is available at:

An HTML formatted version is also available at:

Authentication Method Reference Values Specification

By

On July 22, 2015

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoPhil Hunt and I have posted a new draft that defines some values used with the “amr” (Authentication Methods References) claim and establishes a registry for Authentication Method Reference values. These values include commonly used authentication methods like “pwd” (password) and “otp” (one time password). It also defines a parameter for requesting that specific authentication methods be used in the authentication.

The specification is available at:

An HTML formatted version is also available at:

Lots of great data about JWT and OpenID Connect adoption!

By

On July 21, 2015

In Claims, Documentation, Interoperability, JSON, OAuth, OpenID, People, Software, Specifications

JWT logoCheck out the post Json Web Token (JWT) gets a logo, new website and more by Matias Woloski of Auth0. I particularly love the data in the “Numbers speak for themselves” section and the graph showing the number of searches for “JSON Web Token” crossing over the number of searches for “SAML Token”.

Also, be sure to check out http://jwt.io/, where you can interactively decode, verify, and generate JWTs. Very cool!

JWK Thumbprint -08 approved by IESG

By

On July 13, 2015

In Cryptography, JSON, Specifications

IETF logoThe IESG has approved JWK Thumbprint draft -08, meaning that it will now progress to the RFC Editor. Draft -08 added IANA instructions in response to an IESG comment by Barry Leiba.

The specification is available at:

An HTML formatted version is also available at:

OAuth 2.0 Dynamic Client Registration Protocol is now RFC 7591

By

On July 9, 2015

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoThe OAuth 2.0 Dynamic Client Registration Protocol specification is now RFC 7591 – an IETF standard. The abstract describes it as follows:

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

This specification extracts the subset of the dynamic client registration functionality defined by OpenID Connect Dynamic Client Registration 1.0 that is applicable to any OAuth 2.0 deployment. It is intentionally completely compatible with the OpenID Connect registration spec, yet is also now usable as a basis for dynamic client registration by other OAuth 2.0 profiles.

My personal thanks to Justin Richer, John Bradley, Maciej Machulak, Phil Hunt, and Nat Sakimura for their work on this specification and its precursors. Thanks also to members of the OpenID Connect working group and members of the OAuth working group, as well as its chairs, area directors, and other IETF members who contributed to this specification.

OAuth 2.0 Token Exchange -02 enabling use of any token type

By

On July 7, 2015

In Claims, JSON, OAuth, Specifications

OAuth logoDraft -02 of the OAuth 2.0 Token Exchange specification has been published, making the functionality token type independent. Formerly, only JSON Web Tokens (JWTs) could be used in some contexts. This was a change requested by working group participants during IETF 92 in Dallas.

The specification is available at:

An HTML formatted version is also available at:

JWK Thumbprint -07 draft addressing Gen-ART review comment

By

On July 7, 2015

In Claims, Cryptography, Specifications

IETF logoJWK Thumbprint draft -07 has been published, addressing a Gen-ART review comment by Joel Halpern. Beyond updating the acknowledgements, the only change was replacing this sentence:

“Only if multiple parties will be reproducing the JWK Thumbprint calculation for some reason, will parties other than the original producer of the JWK Thumbprint need to know which hash function was used.”

with these two:

“However, in some cases, multiple parties will be reproducing the JWK Thumbprint calculation and comparing the results. In these cases, the parties will need to know which hash function was used and use the same one.”

The specification is available at:

An HTML formatted version is also available at:

Page 16 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén