Musings on Digital Identity

Month: January 2014

Refactored OAuth Dynamic Client Registration Specs

OAuth logoI’ve posted an updated set of OAuth Dynamic Client Registration specifications that refactors the previous single specification into three specs:

  • OAuth 2.0 Dynamic Client Registration Core Protocol
  • OAuth 2.0 Dynamic Client Registration Metadata
  • OAuth 2.0 Dynamic Client Registration Management Protocol

This refactoring was the result of discussions at IETF 88 in Vancouver, BC. These refactored specifications are compatible with the previous single specification.

The Core specification contains only the definitions needed to perform dynamic registrations. It contains a completely rewritten Use Cases appendix, intended to clarify the different ways that dynamic registration can be performed. It also adds the Software Statement abstraction invented by Phil Hunt — enabling assertions to be made and used about the client software being registered.

The Metadata specification defines useful client metadata values that are nonetheless not essential to the core, such as “client_name“, “logo_uri“, and “software_id“. These were previously defined in the single dynamic registration spec.

The Management specification defines the client management operations Read, Update, and Delete, and addresses client secret rotation. These were previously defined in the single dynamic registration spec.

The drafts are available at:

HTML formatted versions are also available at:

These versions build upon prior restructuring work done by both Justin Richer and Phil Hunt.

JOSE -20 drafts intended for Working Group Last Call

IETF logoJSON Object Signing and Encryption (JOSE) -20 drafts have been published that incorporate the changes agreed to on last week’s JOSE working group call. Hopefully this brings us to the point of Working Group Last Call.

The only normative changes were to change the name of the “use_details” JWK member to “key_ops” and to clarify that “use” is meant for public key use cases, “key_ops” is meant for use cases in which public, private, or symmetric keys may be present, and that “use” and “key_ops” should not be used together.

The drafts, including JSON Web Token (JWT), now also reference draft-ietf-json-rfc4627bis, rather than RFC 4627.

The drafts are available at:

HTML formatted versions are also available at:

Powered by WordPress & Theme by Anders Norén