Musings on Digital Identity

Month: August 2016

Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs

OpenID logoSession ID definitions in the OpenID Connect front-channel and back-channel logout specs have been aligned so that the Session ID definition is now the same in both specs. The Session ID is scoped to the Issuer in both specs now (whereas it was previously global in scope in the front-channel spec). This means that the issuer value now needs to be supplied whenever the Session ID is. This doesn’t change the simple (no-parameter) front-channel logout messages. The back-channel specification is now also aligned with the ID Event Token specification.

The new specification versions are:

Initial OpenID Connect Enhanced Authentication Profile (EAP) Specifications Published

The OpenID Enhanced Authentication Profile (EAP) working group was created to enable use of the IETF Token Binding specifications with OpenID Connect and to enable integration with FIDO relying parties and/or other strong authentication technologies. The OpenID Foundation has now published the initial EAP specifications as a first step towards accomplishing these goals. See the announcement on

OAuth Metadata Specifications Enhanced

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:

Powered by WordPress & Theme by Anders Norén