[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