Musings on Digital Identity

Month: March 2015

OAuth Proof-of-Possession draft -02 closing open issues

OAuth logoAn updated OAuth Proof-of-Possession draft has been posted that address the open issues identified in the previous draft. Changes were:

  • Defined the terms Issuer, Presenter, and Recipient and updated their usage within the document.
  • Added a description of a use case using an asymmetric proof-of-possession key to the introduction.
  • Added the “kid” (key ID) confirmation method.

Thanks to Hannes Tschofenig for writing text to address the open issues.

This specification is available at:

An HTML formatted version is also available at:

HTTP-Based OpenID Connect Logout Spec

OpenID logoA new HTTP-Based OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-logout-1_0.html. This can coexist with or be used instead of the current HTML postMessage-based Session Management Spec.

The abstract for the new spec states:

This specification defines an HTTP-based logout mechanism that does not need an OpenID Provider iframe on Relying Party pages. Other protocols have used HTTP GETs to RP URLs that clear cookies and then return a hidden image or iframe content to achieve this. This specification does the same thing. It also reuses the RP-initiated logout functionality specified in Section 5 of OpenID Connect Session Management 1.0 (RP-Initiated Logout).

Special thanks to Brian Campbell, Torsten Lodderstedt, and John Bradley for their insights that led to some of the decisions in the spec.

JWK Thumbprint -04 draft incorporating feedback during second WGLC

IETF logoThe latest JWK Thumbprint draft addresses review comments on the -03 draft by Jim Schaad, which resulted in several clarifications and some corrections to the case of RFC 2119 keywords.

The specification is available at:

An HTML formatted version is also available at:

Key Managed JSON Web Signature (KMJWS) specification

IETF logoI took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload. We had considered doing this in JOSE issue #2 but didn’t do so at the time because of lack of demand. However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future — possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or https://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html.

This spec reuses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec. The result is essentially a JWS with an Encrypted Key value added, and a new “mac” Header Parameter value representing the MAC algorithm used. (Like JWE, the key management algorithm is carried in the “alg” Header Parameter value.)

I also wrote this now as possible input into our thinking on options for creating a CBOR JOSE mapping. If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution.

Yes, the spec name and abbreviation are far from catchy. Better naming ideas would be great.

Feedback welcomed.

Powered by WordPress & Theme by Anders Norén