Given that the syntax and semantics should now be stable, it’s my hope that early adopters will start kicking the tires – building implementations and making trial deployments. I can’t wait for the useful feedback that results!
While AAD has supported OpenID Connect for years, the push to achieve OpenID Certification closed a number of gaps in AAD’s feature set — mostly notably, adding support for the UserInfo Endpoint to AAD V2. This work was part of Microsoft’s commitment to utilizing widely-adopted open identity standards. Kudos to the AAD engineering team for bringing this important developer-focused work to completion!
The two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 104 in Prague. The Push Delivery spec went through working group last call (WGLC). It has been updated to incorporate the WGLC comments. Changes made are summarized in the spec change log, the contents of which were also posted to the working group mailing list. Thanks to Annabelle Backman for the edits to the Push Delivery spec.
The OpenID Connect Federation 1.0 specification is being developed to enable large-scale federations to be deployed using OpenID Connect. It enables trust among federation participants to be established through signed statements made by federation operators about federation participants.
The design of this specification builds upon the experiences gained in operating large-scale SAML 2.0 federations, and indeed, is authored by people having practical experience with these federations. The primary authors are Roland Hedberg and Andreas Åkre Solberg, with additional contributions by Samuel Gulliksson, John Bradley, and myself, as well as members of the OpenID Connect working group, which is the home of the specification.
A key innovation that differentiates OpenID Connect federations from most SAML 2.0 federations is that OpenID Connect federation employs heirarchal metadata, where participants directly publish statements about themselves, versus the aggregated metadata approach used by many SAML 2.0 federations, where Continue reading "OpenID Connect Federation Specification"
As Alex Simons recently wrote, it’s time for token binding. Especially now that the core specs are done, now’s the time for platforms and applications to deploy Token Binding. This will enable replacing bearer tokens, which can be stolen and reused, with Token Bound tokens, which are useless if stolen. This is a huge security benefit applicable to any tokens used over TLS, including browser cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens.
A quick reminder that the vote to approve updates to the OpenID IPR Policy document is under way. If you’re an OpenID Foundation member, I encourage you to vote to approve the updates now at https://openid.net/foundation/members/polls/151.
As described in the OpenID Foundation post Proposed Revisions to OpenID IPR Policy Document, the updates enable the use of electronic signatures on contributor agreements instead of requiring on-paper signatures and simplify the descriptions of working group contributors, all without changing the IPR rights of any party.
The foundation needs 30% of the membership to vote in order for the changes to take effect, so please take a moment and vote now. Thanks!
The Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.
The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.
The award recognizes that the OpenID Certification program has become a significant global force promoting high-quality, secure, interoperable OpenID Connect implementations. Its innovative use of self-certification using freely available online tools has made testing the quality of OpenID Connect implementations simple, effective, and commonplace. Thanks to Kuppinger Cole for recognizing the impact of the OpenID Certification program!
The award recognizes that the OpenID Certification program has become a significant global force promoting high-quality, secure, interoperable OpenID Connect implementations. Its innovative use of self-certification using freely available online tools has made testing the quality of OpenID Connect implementations simple, effective, and commonplace. Thanks to IDnext for recognizing the impact of the OpenID Certification program!
Digital identity systems almost universally support end-users logging into applications and many also support logging out of them. But while login is reasonable well understood, there are many different kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logouts.
I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth Security Workshop in Trento, Italy, which was held the week before IETF 101, to explore this topic. The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic. Brock Allen – a practicing application security architect (and MVP for ASP.NET/IIS) – significantly contributed to the materials used to seed the discussion. And Nat Sakimura took detailed notes to record what we learned during the discussion.