Mike Jones: self-issued

Musings on Digital Identity

Author: Mike Jones Page 14 of 33

Building the Internet's missing identity layer

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

By

On August 23, 2016

In OpenID, Specifications

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

By

On August 5, 2016

In OpenID, Phishing Resistance, Specifications

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 openid.net.

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:

OpenID Connect EAP ACR Values specification

By

On July 7, 2016

In Federation, OpenID, Phishing Resistance, Specifications

OpenID logoThe OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been submitted to the OpenID Enhanced Authentication Profile (EAP) working group. Per the abstract:

This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators.

The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.

The specification is available at:

Terminology updates in OAuth Mix-Up Mitigation specification

By

On July 7, 2016

In OAuth, Specifications

OAuth logoThe only change to the new draft is to use terminology more consistently. Specifically, it changes the terms “issuer URL” and “configuration information location” to “issuer identifier” so that consistent terminology is used for this. (This is the terminology used by OpenID Connect.)

This is being posted in preparation for discussions at the upcoming OAuth Security Workshop in Trier, Germany and the IETF 96 meeting in Berlin.

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:

Token Binding for Access Tokens, Refresh Tokens, and ID Tokens

By

On July 4, 2016

In Cryptography, JSON, OAuth, OpenID, Specifications

IETF logoTwo new related specifications define syntax and semantics for applying Token Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-token-bound-authentication-1_0 contains the OpenID Connect portions.

These are being submitted now to hopefully enable end-to-end implementations and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID Tokens across multiple platforms before the Token Binding specifications are finalized.

The OAuth specification is available at:

The OpenID Connect specification is available at:

Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell for reviews of earlier versions of these specifications and to Dirk Balfanz and William Denniss for some earlier discussions providing input to these specifications.

OpenID Certification Progress Report at CIS 2016

By

On June 10, 2016

In Events, OpenID

OpenID logoI gave an invited presentation on OpenID Certification at the 2016 Cloud Identity Summit (CIS) this week. I used the presentation as an opportunity to inventory what we’ve achieved with the certification program since its launch in April 2015, and while the numbers are impressive in and of themselves (90 profiles certified for 28 implementations by 26 organizations, with new certifications in May by Clareity Security, Auth0, and Okta), there’s a deeper impact that’s occurring that the numbers don’t tell.

The new thing that’s happening this year is relying parties are explicitly asking identity providers to get certified. Why? Because certified implementations should “just work” — requiring no custom code to integrate with them, which is better for everyone. This network effect is now in play because it provides business value to all the participants.

While I’ve spoken about certification about 10 times since the launch, this presentation is different because it tells this new story that’s playing out in the marketplace. Check it out in PowerPoint or PDF.

Mike presenting at CIS 2016
(Photo from https://twitter.com/JamieXML/status/740213415172444160)

First Public Working Draft of W3C Web Authentication Specification

By

On May 31, 2016

In Cryptography, Specifications

W3C logoThe W3C Web Authentication Working Group today announced publication of the First Public Working Draft of the W3C Web Authentication specification. The abstract of the specification is:

This specification defines an API that enables web pages to access WebAuthn compliant strong cryptographic credentials through browser script. Conceptually, one or more credentials are stored on an authenticator, and each credential is scoped to a single Relying Party. Authenticators are responsible for ensuring that no operation is performed without the user’s consent. The user agent mediates access to credentials in order to preserve user privacy. Authenticators use attestation to provide cryptographic proof of their properties to the relying party. This specification also describes a functional model of a WebAuthn compliant authenticator, including its signature and attestation functionality.

This specification is derived from the November 12, 2015 member submission of FIDO 2.0 Platform Specifications. Content from the three submitted specifications has been merged into a single Web Authentication specification, also incorporating changes agreed to by the Web Authentication working group. The working group intends to continue making timely progress, planning to publish a Candidate Recommendation by September 2016.

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:

OpenID Connect Discussions at EIC 2016

By

On May 16, 2016

In Events, OpenID

OpenID logoOn May 10, during the OpenID Workshop at the 2016 European Identity and Cloud (EIC) conference, I gave a status update on the OpenID Connect working group to the 46 workshop attendees, including continued progress with OpenID Certification. You can view the presentation in PowerPoint or PDF format.

While I was happy to report on the working group activities, what I really enjoyed about the workshop was hearing many of the attendees telling us about their deployments. They told us about several important OpenID Connect projects each in Europe, Australia, South America, North America, and Asia. Rather than coming to learn what OpenID Connect is, as in some past EIC workshops, people were coming to discuss what they’re doing. Very cool!

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800

By

On April 6, 2016

In Cryptography, JSON, OAuth, Specifications

IETF logoThe Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specification is now RFC 7800 — an IETF standard. The abstract describes the specification as:

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of-possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

Thanks to John Bradley, Hannes Tschofenig, and the OAuth working group for their work on this specification.

Using RSA Algorithms with COSE Messages

By

On April 4, 2016

In CBOR, Cryptography, Specifications

IETF logoI have published draft-jones-cose-rsa, which defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. This addresses COSE Issue #21: Restore RSA-PSS and the “RSA” key type. The initial version of this specification incorporates text from draft-ietf-cose-msg-05 — the last COSE message specification version before the RSA algorithms were removed.

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.

Tidied-up OAuth 2.0 Device Flow specification

By

On March 3, 2016

In OAuth, Specifications

OAuth logoThe OAuth 2.0 Device Flow specification has been tidied up to apply spelling and grammar corrections and add the Document History appendix. No normative changes were made. Again, if you’re using an OAuth device flow, please let us know whether your implementation matches this specification, and if not, let us know how it differs.

The specification is available at:

An HTML-formatted version is also available at:

JWS Unencoded Payload Option is now RFC 7797

By

On February 25, 2016

In Cryptography, JSON, Specifications

IETF logoThe JWS Unencoded Payload Option specification is now RFC 7797 — an IETF standard. The abstract describes the specification as:

JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url-encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.

This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.

This option is used by including the header parameters "b64":false and "crit":["b64"]. JWTs never use this option.

Initial OAuth working group Device Flow specification

By

On February 18, 2016

In OAuth, Specifications

OAuth logoThanks to William Denniss for creating the initial working group version of the OAuth 2.0 Device Flow specification. The abstract of the specification is:

The device flow is suitable for OAuth 2.0 clients executing on devices which do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs), but where the end-user has separate access to a user-agent on another computer or device (e.g., desktop computer, a laptop, a smart phone, or a tablet).

Note: This version of the document is a continuation of an earlier, long expired draft. The content of the expired draft has been copied almost unmodified. The goal of the work on this document is to capture deployment experience.

If you’re using an OAuth device flow, please let us know whether this specification matches your usage, and if not, how yours differs.

The specification is available at:

An HTML-formatted version is also available at:

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:

Authentication Method Reference Values spec incorporating adoption feedback

By

On February 11, 2016

In Claims, JSON, OAuth, OpenID, Specifications

OAuth logoThis draft of the Authentication Method Reference Values specification incorporates OAuth working group feedback from the call for adoption. The primary change was to remove the “amr_values” request parameter, so that “amr” values can still be returned as part of an authentication result, but cannot be explicitly requested. Also, noted that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no longer require a specification.

The specification is available at:

An HTML-formatted version is also available at:

Page 14 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén