[Openid-specs-ab] Spec Call Notes 3-Oct-22

[Mike Jones]

Spec Call Notes 3-Oct-22

Mike Jones
George Fletcher
Tobias Looker
Kristina Yasuda
David Waite (DW)
Dima Postnikov
Karthik Sivasamy
Andrii Deinega

Pull Requests
              https://bitbucket.org/openid/connect/pull-requests/
              PR #309: Addresses issues 1644 and 1647
                           Merged
                           We will republish the prompt=create spec
              PR #312: fix: [Federation] signed_jwks_uri explanatory text
                           Merged
                           We will start a two-week working group last call review of the Federation spec
              PR 310: Clean up of SIOPv2
                           Torsten approved
                           Mike still plans to review
                           Tobias made a comment
              PR #291: relaxed the requirement to use openid4vp for presentation during issuance (Issue #1599)
                           Was updated to reflect Thomas Bellebaum's concerns
                           Tobias now also approved
                           Merged

Native SSO Spec
              We merged PR #306: Updates to Native SSO spec during the last call
              We will now start the Implementer's Draft review

Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              #1589: Proposal for supporting "client discovery" in OIDC / OAuth2
                           We discussed the desire to pass client metadata in a DID document
                           Automatic registration is already a way to enable just-in-time client usage without pre-registration
                                         https://openid.net/specs/openid-connect-federation-1_0.html#name-automatic-registration
                                         This is used by SIOPv2
                           Kristina asked about why the Automatic Registration requests need to be signed
                                         Mike answered that it's to prove possession of the keys published by the entity statement
                           Tobias described an effort to create an OAuth draft
                                         Mike expressed his desire to have it be compatible with Entity Statements
                                                       Just like past OAuth drafts derived from Connect drafts have been fully compatible
              #1451: [oidc4vci] Mandatory vs optional credential claims
                           Tobias stated that the claims included should be up to the issuer
                           Tobias sees three options:
                                         1. One option is that the requested claims are considered as a hint to the issuer
                                         2. The provider returns an error
                                         3. The claims that the requester can request are only the optional claims for that credential type
                           George said that a whole lot of errors can result from having various options
                           Given that selective disclosure is supported, even if a wallet has claims, they would not necessarily be released to RPs
                           Mike said that in Connect, we request claims, the OP decides what claims to send, and ultimately the RP decides what to do
                                         That gives the RP the most actionable information
                                         For instance, then it can then give the best error messages possible, even when further processing isn't feasible
                           Tobias is concerned with over-disclosure
                                         Mike said that that can't be fixed in the protocol
                                         It is at a contract and trust framework level
                           Mike said that returning errors is the least useful thing to do, from an ecosystem perspective
                                         Mike believes that not being able to return exactly what was requested is a normal case

Redirection of .well-known URIs
              George has previously said that redirects are supported
              Andrii said that OpenID Connect Discovery says that the response should be 200 OK
              George thought that WebFinger allows redirects
                           WebFinger does support redirection, per https://datatracker.ietf.org/doc/html/rfc7033#section-4.2
              Mike opined that the issuance document could choose to support redirection of its .well-known resource
                           But both Mike and Kristina want to seek John Bradley's viewpoint first ;-)
              We discussed possibly also signing the metadata
              After the call, DW located the issue that resulted in requiring the 200 OK responses:
                     https://bitbucket.org/openid/connect/issues/627/
                           It's by Tatsuya Hayashi (Lef) and over a decade old!

Next Call
              The next call is at 7am Pacific Time on Thursday, October 6, 2022, followed by the SIOP Special Topic call
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20221004/355781b1/attachment-0001.html>