Musings on Digital Identity

Category: OpenID Page 5 of 10

OAuth and OpenID Connect Token Binding specs updated

OAuth logoThe OAuth 2.0 Token Binding specification has been updated to enable Token Binding of JWT Authorization Grants and JWT Client Authentication. The discussion of phasing in Token Binding was improved and generalized. See the Document History section for other improvements applied.

The specification is available at:

An HTML-formatted version is also available at:

An update to the closely-related OpenID Connect Token Bound Authentication 1.0 specification was also simultaneously published. Its discussion of phasing in Token Binding was correspondingly updated.

The OpenID Connect Token Binding specification is available in HTML and text versions at:

Thanks to Brian Campbell for doing the bulk of the editing for both sets of revisions.

OpenID Presentations at October 16, 2017 OpenID Workshop and IIW

OpenID logoI gave the following presentations at the Monday, October 16, 2017 OpenID Workshop at PayPal:

I also gave the following “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 17th:

Authentication Method Reference Values is now RFC 8176

IETF logoThe Authentication Method Reference Values specification is now RFC 8176. The abstract describes the specification as:

The amr (Authentication Methods References) claim is defined and registered in the IANA “JSON Web Token Claims” registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.

The specification defines and registers some Authentication Method Reference values such as the following, which are already in use by some Google and Microsoft products and OpenID specifications:

  • face” — Facial recognition
  • fpt” — Fingerprint
  • hwk” — Proof-of-possession of a hardware-secured key
  • otp” — One-time password
  • pin” — Personal Identification Number
  • pwd” — Password
  • swk” — Proof-of-possession of a software-secured key
  • sms” — Confirmation using SMS
  • user” — User presence test
  • wia” — Windows Integrated Authentication

See https://www.iana.org/assignments/authentication-method-reference-values/ for the full list of registered values.

Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all of whom substantially contributed to the specification. Thanks also to the OAuth working group members, chairs, area directors, and other IETF members who helped refine the specification.

OpenID Connect Logout Implementer’s Drafts Approved

As announced by the OpenID Foundation, the OpenID membership has approved Implementer’s Drafts of the three OpenID Connect logout specifications. That means that developers and deployers can now count on the intellectual property protections that come with being Implementer’s Drafts.

These are the first Implementer’s Drafts of these specifications:

  • Front-Channel Logout – Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
  • Back-Channel Logout – Defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out

Whereas, this is the fourth Implementer’s Draft of this specification:

  • Session Management – Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality

Each of these protocols communicate logout requests from OpenID Providers to Relying Parties, but using different mechanisms that are appropriate for different use cases. See the Introduction sections of each of the specifications for descriptions of the mechanisms used and comparisons between them. All the specifications share a common mechanism for communicating logout requests from Relying Parties to OpenID Providers.

As expected, the reviews generated some great feedback on ways to make the specs clearer. I expect the working group to incorporate that feedback in future revisions.

AMR Values specification addressing Stephen Farrell’s comments

OAuth logoSecurity area director Stephen Farrell had asked us to make it as clear as possible to people who might be registering new “amr” values that names can identify families of closely-related authentication methods. This is now said right in the IANA Registration Template, so that people who might not have read the spec can’t miss it.

FYI, all the previous IESG DISCUSSes have now been cleared, so hopefully that means this is the last version to be published before the Authentication Method Reference Values specification becomes an RFC.

Thanks again to Stephen for his always-thorough reviews of the specification.

The specification is available at:

An HTML-formatted version is also available at:

AMR Values specification addressing IESG comments

OAuth logoThe Authentication Method Reference Values specification has been updated to address feedback from the IESG. Identifiers are now restricted to using only printable JSON-friendly ASCII characters. All the “amr” value definitions now include specification references.

Thanks to Stephen Farrell, Alexey Melnikov, Ben Campbell, and Jari Arkko for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

OpenID Connect Relying Party Certification Launched

OpenID logoThanks to all who contributed to the launch of OpenID Connect Relying Party Certification! This is a major step in continuing to improve the interoperability and security of OpenID Connect implementations.

Roland Hedberg deserves huge credit for writing and deploying the testing tools. Roland eagerly interacted with developers as they “tested the tests”, promptly answering questions and iteratively developing the software to address issues that arose during the testing.

Hans Zandbelt and Edmund Jay also deserve huge thanks for being the earliest Relying Party testers. Because of their early feedback and perseverance, the process is now much easier for those that followed them.

As Don Thibeau wrote in the launch announcement, we were surprised by the speed of RP Certification adoption once we began the pilot phase – happening much more quickly than OpenID Provider certification did. I loved the feedback from developers, who told us that they understand the protocol better and have more secure implementations because of their certification participation. Let’s have more of that!

Candidate proposed OpenID Connect logout Implementer’s Drafts

Per discussions on the OpenID Connect working group calls, I have released candidate proposed Implementer’s Drafts for the three logout specs. The new versions are:

These drafts address the issues discussed on the calls and in the issue tracker. The changelogs can be viewed at these URLs:

Note that the Back-Channel Logout spec is compatible with the working group SecEvent spec https://tools.ietf.org/html/draft-ietf-secevent-token-00.

This note starts a one-week review period of these specifications by the working group. If blocking issues aren’t raised within a week, we will proceed with the formal review period preceding an OpenID Foundation Implementer’s Draft adoption vote.

“amr” Values specification addressing IETF last call comments

OAuth logoDraft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:

  • Specified characters allowed in “amr” values, reusing the IANA Considerations language on this topic from RFC 7638.
  • Added several individuals to the acknowledgements.

Thanks to Linda Dunbar, Catherine Meadows, and Paul Kyzivat for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) Specification and IETF Security Events Working Group

IETF logoAs those of you who have been following the id-event@ietf.org mailing list or attended the inaugural meeting of the new IETF Security Events working group know, Phil Hunt and co-authors (including myself) have been working on a Security Event Token (SET) specification. A SET is a JSON Web Token (JWT) with an “events” claim that contains one or more event identifiers (which are URIs) that say what event the SET describes.

This work isn’t being done in isolation. Among others, the OpenID Risk and Incident Sharing and Coordination (RISC) working group, the OpenID Back-Channel Logout specification, and the SCIM Provisioning Events work intend to use the Security Event Token format.

To make this concrete, the claims in an example OpenID Connect Back-Channel Logout token (which is a SET) are:

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  }
}

You’ll see that this a normal JWT, with the issuer, subject, and session ID identifying the target of the logout, and the “events” value identifying the JWT as a logout SET.

Today, we published an updated SET spec based on discussions at IETF 97, which simplifies the SET parsing. Thanks to Phil Hunt or Oracle, William Denniss of Google, Morteza Ansari of Cisco, and the numerous other contributors who’ve gotten us to this point. We now believe that this specification is ready for adoption by the Security Events working group.

The specification is available at:

An HTML-formatted version is also available at:

The OpenID Connect Back-Channel Logout specification should be updated soon (after the US Thanksgiving holiday) to utilize the simplified SET syntax. Happy Thanksgiving, everyone!

“amr” Values specification addressing area director comments

OAuth logoDraft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:

  • Added “amr” claim examples with both single and multiple values.
  • Clarified that the actual credentials referenced are not part of this specification to avoid additional privacy concerns for biometric data.
  • Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to applications using this specification.

The specification is available at:

An HTML-formatted version is also available at:

“amr” Values specification addressing shepherd comments

OAuth logoDraft -03 of the Authentication Method Reference Values specification addresses the shepherd comments. It changes the references providing information about specific “amr” values to be informative, rather than normative. A reference to ISO/IEC 29115 was also added. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

“amr” Values specification addressing WGLC comments

OAuth logoDraft -02 of the Authentication Method Reference Values specification addresses the Working Group Last Call (WGLC) comments received. It adds an example to the multiple-channel authentication description and moves the “amr” definition into the introduction. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

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

“amr” Values specification distinguishing between iris and retina scan biometrics

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

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:

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

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

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)

OpenID Connect Discussions at EIC 2016

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!

Page 5 of 10

Powered by WordPress & Theme by Anders Norén