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.
A new version of the Security Event Token (SET) specification has been published that incorporates clarifications suggested by working group members in discussions since IETF 100. Changes were:
Clarified that all “events” values must represent aspects of the same state change that occurred to the subject — not an aggregation of unrelated events about the subject.
Removed ambiguities about the roles of multiple “events” values and the responsibilities of profiling specifications for defining how and when they are used.
Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
Addressed terminology inconsistencies. In particular, standardized on using the term “issuer” to align with JWT terminology and the “iss” claim. Previously the term “transmitter” was sometimes used and “issuer” was sometimes used. Likewise, standardized on using the term “recipient” instead of “receiver” for the same reasons.
The 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.