Draft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:
amr” values, reusing the IANA Considerations language on this topic from RFC 7638.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:
As 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!
Draft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:
amr” claim examples with both single and multiple values.The specification is available at:
An HTML-formatted version is also available at:
Draft -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:
Draft -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 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:
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.
This 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:
The 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:
Two 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.
I 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.
(Photo from https://twitter.com/JamieXML/status/740213415172444160)
On 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!
This 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:
Please check out this important post today on the Active Directory Team Blog: “For Developers: Important upcoming changes to the v2.0 Auth Protocol“. While the title may not be catchy, it’s content is compelling — particularly for developers.
The post describes the converged identity service being developed by Microsoft that will enable people to log in either with an individual account (Microsoft Account) or an organizational account (Azure Active Directory). This is a big deal, because developers will soon have a single identity service that their applications can use for both kinds of accounts.
The other big deal is that the changes announced are a concrete demonstration of Microsoft’s ongoing commitment to interoperability and support for open identity standards — in this case, OpenID Connect. As the post says:
The primary motivation for introducing these changes is to be compliant with the OpenID Connect standard specification. By being OpenID Connect compliant, we hope to minimize differences between integrating with Microsoft identity services and with other identity services in the industry. We want to make it easy for developers to use their favorite open source authentication libraries without having to alter the libraries to accommodate Microsoft differences.
If you’re a developer, please do heed the request in the post to give the service a try now as it approaches General Availability (GA). Enjoy!
Authentication Method Reference Values draft -04 added the values “face” (facial recognition), “geo” (geolocation), “hwk” (proof-of-possession of a hardware-secured key), “pin” (Personal Identification Number or pattern), and “swk” (proof-of-possession of a software-secured key), and removed the value “pop” (proof-of-possession), based on input from members of the OpenID Foundation MODRNA working group.
The specification is available at:
An HTML formatted version is also available at:
Authentication Method Reference Values draft -03 adds the criterion to the IANA registration instructions that the value being registered be in actual use.
The specification is available at:
An HTML formatted version is also available at:
I wanted to bring your attention to Alex Simons’ announcement Active Directory Federation Services gains OpenID Certifications! ADFS now is certified for the Basic OpenID Provider and Implicit OpenID Provider profiles of OpenID Connect — adding to its previous certification for the OpenID Provider Publishing Configuration Information profile. I’ll also add that ADFS was tested for “response_type=code id_token” and passed all those tests as well.
My congratulations both to the ADFS team and to the other teams worldwide that have recently certified their OpenID Providers. See the current OpenID Certification results at http://openid.net/certification/. Watch that space for more results to come!
A new back-channel OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-backchannel-1_0.html. This can coexist with or be used instead of the front-channel-based Session Management and HTTP-Based Logout specifications.
The abstract for the new specification states:
This specification defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.
This completes publication of the three planned OpenID Connect logout mechanisms: two that communicate on the front-channel through the User Agent (browser) and this one that communicates on the back-channel, without involving the User Agent. See the Introduction for a discussion of the upsides and downsides of the different logout approaches. As much as we’d like there to be a single logout solution, both experience and extensive discussions led us to the conclusion that there isn’t a feasible one-size-fits-all approach.
Reviews of the new (and existing!) specifications are welcomed.
Thanks to John Bradley, Pedro Felix, Nat Sakimura, Brian Campbell, and Todd Lainhart for their contributions to the creation of the specification.
The JSON Web Key (JWK) Thumbprint specification is now RFC 7638 — an IETF standard. The abstract describes the specification as follows:
This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.
Thanks to James Manger, John Bradley, and Nat Sakimura, all of whom participated in security discussions that led to the creation of this specification. Thanks also to the JOSE working group members, chairs, area directors, and other IETF members who contributed to the specification.
A JWK Thumbprint is used as the “sub” (subject) claim value in OpenID Connect self-issued ID Tokens.
Authentication Method Reference Values draft -02 changed the identifier for risk-based authentication from “risk” to “rba“, by popular acclaim, and added the identifier “sc” (smart card).
The specification is available at:
An HTML formatted version is also available at:
Powered by WordPress & Theme by Anders Norén