I gave the following presentation on the OpenID Connect Working Group at the Third Virtual OpenID Workshop on Thursday, April 29, 2021:
- OpenID Connect Working Group (PowerPoint) (PDF)
I gave the following presentation on the OpenID Connect Working Group at the Third Virtual OpenID Workshop on Thursday, April 29, 2021:
Today marks an important milestone in the life of the OpenID Foundation and the worldwide digital identity community. Following Don Thibeau’s decade of exemplary service to the OpenID Foundation as its Executive Director, today we welcomed Gail Hodges as our new Executive Director.
Don was instrumental in the creation of OpenID Connect, the Open Identity Exchange, the OpenID Certification program, the Financial-grade API (FAPI), and its ongoing worldwide adoption. He’s created and nurtured numerous liaison relationships with organizations and initiatives advancing digital identity and user empowerment worldwide. And thankfully, Don intends to stay active in digital identity and the OpenID Foundation, including supporting Gail in her new role.
Gail’s Twitter motto is “Reinventing identity as a public good”, which I believe will be indicative of the directions in which she’ll help lead the OpenID Foundation. She has extensive leadership experience in both digital identity and international finance, as described in her LinkedIn profile. The board is thrilled to have her on board and looks forward to what we’ll accomplish together in this next exciting chapter of the OpenID Foundation!
I encourage all of you to come meet Gail at the OpenID Foundation Workshop tomorrow, where she’ll introduce herself to the OpenID community.
I gave the following invited “101” session presentation at the 32nd Internet Identity Workshop (IIW) on Tuesday, April 20, 2021:
The session was well attended. There was a good discussion about uses of Self-Issued OpenID Providers.
As described in my last post about OAuth JAR, after it was first sent to the RFC Editor, the IESG requested an additional round of IETF feedback. I’m happy to report that, having addressed this feedback, the spec has now been sent back to the RFC Editor.
As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].
The specification is available at:
An HTML-formatted version is also available at:
After the OAuth 2.0 JWT Secured Authorization Request (JAR) specification was sent to the RFC Editor, the IESG requested an additional round of IETF feedback. We’ve published an updated draft addressing the remaining review comments, specifically, SecDir comments from Watson Ladd. The only normative change made since the 28 was to change the MIME Type from “oauth.authz.req+jwt
” to “oauth-authz-req+jwt
“, per advice from the designated experts.
As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].
The specification is available at:
An HTML-formatted version is also available at:
Like the First OpenID Foundation Virtual Workshop, I was once again pleased by the usefulness of the discussions at the Second OpenID Foundation Virtual Workshop held today. Many leading identity engineers and businesspeople participated, with valuable conversations happening both via the voice channel and in the chat. Topics included current work in the working groups, such as eKYC-IDA, FAPI, MODRNA, FastFed, EAP, Shared Signals and Events, and OpenID Connect, plus OpenID Certification, OpenID Connect Federation, and Self-Issued OpenID Provider (SIOP) extensions.
Identity Standards team colleagues Kristina Yasuda and Tim Cappalli presented respectively on Self-Issued OpenID Provider (SIOP) extensions and Continuous Access Evaluation Protocol (CAEP) work. Here’s my presentation on the OpenID Connect working group (PowerPoint) (PDF) and the Enhanced Authentication Profile (EAP) (PowerPoint) (PDF) working group. I’ll add links to the other presentations when they’re posted.
I gave the following invited “101” session presentation at the 31st Internet Identity Workshop (IIW) on Tuesday, October 20, 2020:
I appreciated learning about how the participants are using or considering using OpenID Connect. The session was recorded and will be available in the IIW proceedings.
Congratulations to Nat Sakimura and John Bradley for progressing the OAuth 2.0 JWT Secured Authorization Request (JAR) specification from the working group through the IESG to the RFC Editor. This specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and intentionally does so without introducing breaking changes.
This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].
The specification is available at:
An HTML-formatted version is also available at:
Again, congratulations to Nat and John and the OAuth Working Group for this achievement!
I’ve been systematically working through all the open issues filed about the OpenID Connect Logout specs in preparation for advancing them to Final Specification status. I’m pleased to report that I’ve released drafts that address all these issues. The new drafts are:
The OpenID Connect working group waited to make these Final Specifications until we received feedback resulting from certification of logout deployments. Indeed, this feedback identified a few ambiguities and deficiencies in the specifications, which have been addressed in the latest edits. You can see the certified logout implementations at https://openid.net/certification/. We encourage you to likewise certify your implementations now.
Please see the latest History entries in the specifications for descriptions of the normative changes made. The history entries list the issue numbers addressed. The issues can be viewed in the OpenID Connect issue tracker, including links to the commits containing the changes that resolved them.
All are encouraged to review these drafts in advance of the formal OpenID Foundation review period for them, which should commence in a few weeks. If you believe that changes are needed before they become Final Specifications, please file issues describing the proposed changes. Discussion on the OpenID Connect mailing list is also encouraged.
Special thanks to Roland Hedberg for writing the initial logout certification tests. And thanks to Filip Skokan for providing resolutions to two of the thornier Session Management issues.
My Identiverse 2020 talk Enabling Scalable Multi-lateral Federations with OpenID Connect was just broadcast and is available for viewing. The talk abstract is:
Numerous large-scale multi-lateral identity federations are in production use today, primarily in the Research and Education sector. These include national federations, such as SWAMID in Sweden and InCommon in the US, some with thousands of sites, and inter-federations among dozens of federations, such as eduGAIN. Yet these existing federations are based on SAML 2 and require the federation operator to poll the participants for their metadata, concatenating it into a huge file that is distributed to all federation participants nightly — a brittle process with significant scalability problems.
Responding to demand from the Research and Education community to migrate from SAML 2 to the simpler OpenID Connect protocol, the OpenID Connect working group has created the OpenID Connect Federation specification to enable this. The new approach incorporates lessons learned from existing SAML 2 federations — especially using a new, scalable approach to federation metadata, in which organizations host their own signed metadata and federation operators in turn sign statements about the organizations that are participants in the federation. As Shibboleth author Scott Cantor publicly said at a federation conference, “Given all my experience, if I were to redo the metadata handling today, I would do it along the lines in the OpenID Connect Federation specification”.
This presentation will describe progress implementing and deploying OpenID Connect Federation, upcoming interop events and results, and next steps to complete the specification and foster production deployments. The resulting feedback from Identiverse participants on the approach will be highly valuable.
As a late-breaking addition, data from the June 2020 Federation interop event organized by Roland Hedberg was included in the presentation.
You can also view the presentation slides as PowerPoint or PDF.
I was pleased by the quality of the discussions and participation at the first OpenID Foundation Virtual Workshop. There were over 50 participants, with useful conversations happening both on the audio channel and in the chat. Topics included current work in the working groups, such as eKYC-IDA, FAPI, MODRNA, FastFed, Shared Signals and Events, and OpenID Connect), OpenID Certification, and a discussion on interactions between browser privacy developments and federated login. Thanks to all who participated!
Here’s my presentation on the OpenID Connect working group and OpenID Certification: (PowerPoint) (PDF).
Update: The presentations from the workshop are available at OIDF Virtual Workshop — May 21, 2020.
I gave the following invited “101” session presentation at the 30th Internet Identity Workshop (IIW) on Tuesday, April 28, 2020:
I missed being able to gauge audience reactions by looking around the room but the virtualized session was still well attended by a good group of people, who let me know how OpenID Connect is relevant to what they’re doing.
Two widely used OAuth specifications have recently become RFCs. Here’s a bit about both specs.
RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
Abstract: This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.
Client certificates are widely used in the financial industry to authenticate OAuth clients. Indeed, this specification was developed in part because it was needed by the OpenID Financial-Grade API (FAPI) specifications. It is in production use by numerous Open Banking deployments today.
RFC 8707: Resource Indicators for OAuth 2.0
Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.
This specification standardizes the “resource
” request parameter that is used by Azure Active Directory (AAD) V1 to specify the target resource for an OAuth authorization request.
I gave this keynote presentation at the January 2020 OpenID Japan Summit: Enabling Large-Scale Multi-Party Federations with OpenID Connect. View it in PowerPoint or PDF.
Thanks to Roland Hedberg for collaborating on the presentation with me and for being primary author of the OpenID Connect Federation specification.
And as a preview of coming attractions, I’ll also be presenting on OpenID Connect Federation at Identiverse in June 2020.
I’m pleased to report that the OpenID eKYC and Identity Assurance Working Group is up and running. The new working group is now the home for the OpenID Connect for Identity Assurance specification. This specification defines a representation for verified claims about end-users. This enables real-world use cases such as electronic driver’s licenses and digitally satisfying Know Your Customer (KYC) requirements.
See the post OpenID Connect for Identity Assurance now has a dedicated home for more information about the working group, including the working group call schedule.
Draft 09 of the OpenID Connect Federation specification has been published at https://openid.net/specs/openid-connect-federation-1_0-09.html. This version of the specification benefitted from in-person review by experts at IIW. Major changes were:
The authors believe that this version should become the second Implementer’s Draft, in preparation for interop testing in the coming year. Please review!
My co-authors and I recently competed the paper Using OpenID Connect Self-Issued to Achieve DID Auth, which was created as a result of discussions at the eighth Rebooting the Web of Trust workshop. The paper’s abstract is:
Proving control of a DID requires proving ownership of a private key corresponding to a public key for the DID. Of course, this could be done with a new DID-specific protocol. However, standard protocols for proving ownership of a public/private key pair already exist.
This paper describes how to reuse the Self-Issued OpenID Connect (SIOP) specification and related protocol messages to prove control of a DID. It describes both why and how to do this. Related topics, such as release of claims, are also touched upon.
Several people came to the workshop wanting to explore how to use the OpenID Connect Self-Issued OpenID Provider functionality to prove control of a Decentralized Identifier (DID), including myself. The paper describes the approach being taken by a number of groups using DIDs, including Microsoft. The paper’s publication is timely, as the W3C DID Working Group has just formed to create a DID standard. Microsoft is an active member of the working group.
Special thanks to Dmitri Zagidulin for getting the paper over the finish line!
I gave the following presentations at the Monday, September 30, 2019 OpenID Workshop at Verizon Media:
I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 1, 2019:
Check out the post OpenID Connect Federation Progress describing the recent updates that Roland Hedberg and I made to the OpenID Connect Federation 1.0 specification. We used the TNC19 conference — a gathering of federation experts — as a venue to get together to review and refine the specification. Besides getting lots done on the spec, I also really enjoyed the TNC conference and its attendees!
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!
I gave the following presentations at the May 14, 2019 OpenID Workshop at the 2019 European Identity and Cloud (EIC) conference:
This deck was also prepared but not presented, due to time limitations:
Powered by WordPress & Theme by Anders Norén