[Openid-specs-ab] Spec Call Notes 5-Aug-24
Michael Jones
michael_b_jones at hotmail.com
Tue Aug 6 00:59:53 UTC 2024
Spec Call Notes 5-Aug-24
Mike Jones
Takahiko Kawasaki
Robert Lapes
Andrii Deinega
Alan Wang
Aaron Parecki
Tom Jones
Dima Postnikov
Victor Yu
John Bradley
Brian Campbell
Michael Fraser
Pamela Dingle
Ralph Bragg
Introductions
Robert Lapes - UK Govt. Interested in federating with departments in other countries.
Alan Wang - Just joined the foundation. Wallets, issuers, verifiers.
Taka Kawasaki - Co-founder of Authlete. Implementations of OAuth, OpenID Connect, OpenID Federation. GAIN POC participant.
Authlete's Federation implementation can work with the Italian federation
Wrote very detailed Medium article on OpenID Federation
https://darutk.medium.com/oidc-federation-c2840622dc8f
Also see https://www.authlete.com/developers/oidcfed/
Michael Fraser - Raidiam. Works on data sharing for ecosystems - primary in open finance.
ISO PAS Submission of OpenID Connect Specifications
All passed ISO ballot with no comments! These specs are to be published shortly:
ISO/IEC CD 26131: Information technology - OpenID Connect Core 1.0
ISO/IEC CD 26132: Information technology - OpenID Connect Discovery 1.0
ISO/IEC CD 26133: Information technology - OpenID Connect Dynamic Client Registration 1.0
ISO/IEC CD 26134: Information technology - OpenID Connect RP-Initiated Logout 1.0
ISO/IEC CD 26135: Information technology - OpenID Connect Session Management 1.0
ISO/IEC CD 26136: Information technology - OpenID Connect Front-Channel Logout 1.0
ISO/IEC CD 26137: Information technology - OpenID Connect Back-Channel Logout 1.0
ISO/IEC CD 26138: Information technology - OAuth 2.0 Multiple Response Type Encoding Practices
ISO/IEC CD 26139: Information technology - OAuth 2.0 Form Post Response Mode
No changes were made to any of them, other than adding boilerplate ISO title pages
Brian wondered, in that case, why the FAPI specs are being done using ISO formatting guidelines
It's a question for the FAPI working group
Federation Implementer's Draft 4
IANA Registrations
.well-known/openid-federation registered
OAuth parameters registered
OAuth error codes registered
Still need registrations for JOSE Header Parameters, JWT Claims, Media Types, Client Metadata
Considering adoption of two Federation profile specifications
OpenID Federation Wallet Architectures 1.0
Contributed a week ago at https://lists.openid.net/pipermail/openid-specs-ab/2024-July/010345.html
Also see https://github.com/peppelinux/federation-wallet/
Mike Jones described that the spec records what the Italian deployment is actually doing
Running a call for working group adoption was approved on the call
OpenID Federation Extended Subordinate Listing 1.0
Contributed last week at https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010351.html
Also see https://github.com/MichaelFraser1999/federation-extended-listing
Michael Fraser described the spec and the need
They observe ecosystems in which there is wide fan-out and few or no intermediaries
5 ecosystems so far exhibit this pattern, with more to come
The spec has filtering and pagination
Inspired by Australian ConnectID use case
Eliminates the need for mass entity downloads
Running a call for working group adoption was approved on the call
Federation Pull Requests
https://github.com/openid/federation/pulls
https://github.com/openid/federation/pull/26 - Additional client_registration_types MAY be defined and used
Requested by Justin Richer during his IANA review
Reviews requested
https://github.com/openid/federation/pull/27 - Entity Identifiers use the https scheme
Corrects #22 found by Mark Nottingham during his IANA review
Reviews requested
https://github.com/openid/federation/pull/29 - Corrected Usage Location for IANA error registrations #29
Correction requested by Hannes Tschofenig during his IANA review
Reviews requested
Federation Issues
https://github.com/openid/federation/issues
https://github.com/openid/federation/issues/12 - Supported RP/client metadata parameters
Robert Lapes spoke in favor of the symmetry added by the proposal
Taka finds the concept reasonable
He had thoughts on the use of "_supported" in the metadata names possibly being confused with server metadata
Mike pointed out that we reused names for both kinds of metadata in DPoP
Mike asked people to comment on whether we want/need this feature and when we would use it
https://github.com/openid/federation/issues/28
Mike suggested that validation should be done against the resolved metadata - not just the contents of the Entity Statement
Michael F. pointed out his comment on the treatment of "issuer"
Bitbucket Pull Requests
https://bitbucket.org/openid/connect/pull-requests/
There was consensus to close all three PRs since they were inputs to OpenID Federation Extended Subordinate Listing 1.0
Bitbucket Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open&status=submitted&is_spam=!spam
No new issues
Next Call
The next call is Thursday, August 8th at 7am Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240806/cd0915e7/attachment-0001.html>
More information about the Openid-specs-ab
mailing list