[Openid-specs-ab] Spec Call Notes 9-Mar-23

[Mike Jones]

Spec Call Notes 9-Mar-23

Nat Sakimura
Mike Jones
David Chadwick
Takahiko Kawasaki
Joseph Heenan
Bjorn Hjelm
Giuseppe De Marco
Judith Kahrer
Kristina Yasuda
Torsten Lodderstedt

IETF Meeting in Yokohama
              The draft submission cutoff is Monday, March 13th

Federation
              Joseph described interest in OpenID Connect Federation from Brazil
              They have separate directories for Open Banking and Open Insurance
                           They are considering Federation to enable interoperation
              They wanted to understand how close to final it is

Federation PRs
              https://bitbucket.org/openid/connect/pull-requests/457 feat: [Federation] Listing endpoint - added the parameter trust_mark_id
                            Fairly mature
                           Needs review
              https://bitbucket.org/openid/connect/pull-requests/459 OpenID Connect Federation 1.0: New equals and set_equals policy operators (iss #1819)
                           Giuseppe said that this can be achieved with subset_of and superset_of
                           He questioned whether this is necessary
                           We need additional reviews
                           Taka agreed to review
              https://bitbucket.org/openid/connect/pull-requests/458 fix: [Federation] metadata policies with essential claims
                           This is explanatory, correcting ambiguities
                           Adds an explanatory table
                           It also corrects a regression from a previous PR
                           This needs an approval from Vladimir
              https://bitbucket.org/openid/connect/pull-requests/477
                           Corrects an inconsistency
                           Needs review

OpenID4VP
              Kristina reported on the use of OpenID4VP by the ISO Mobile Driver's License spec
                           ISO wants to go to ballot for publication
                           To do that, they need to reference a stable standard
                           For this, we would need a second Implementer's Draft
                           For instance, we've changed the spec to be based on OAuth rather than Connect since ID1
                           There are two breaking changes we're proposing before the second Implementer's Draft
                                         ClientID Schema
                                         response_mode=direct_post with the cross-device flow
                           ISO is mandating encryption of the authorization response

                           Mike proposed creating a snapshot for a second Implementer's draft
                                         No one objected
                                         David advocated some additional edits about establishing trust

OpenID4VP PRs
              https://bitbucket.org/openid/connect/pull-requests/427 OID4VP: client id format
                           David is hoping that this will address issue #1551 - Administrative Trust in the RP
                           He also wants PRs for X.509 and Train to be added
                                         PRs #455 and #440
                           Torsten said that the X.509 and Train PRs were separated because their functionality wasn't previously in the spec
                           Torsten said the existing PR already adds a needed and effective mechanism
                                         It reduces complexity
                           Torsten said that there isn't sufficient feedback on X.509 yet
                                         He said that the same is true for Train
                                         Torsten asked for David's help with that one
                           Mike made a consensus call to merge it and merged
              https://bitbucket.org/openid/connect/pull-requests/478 Fixed JARM JWE only encryption language
                           There are use cases where it's desirable to only encrypt a response
                           We discussed that, if not signed, some claims such as "iss" aren't needed
                           This is transport encryption
                           We agreed to merge once a syntax error is corrected
              https://bitbucket.org/openid/connect/pull-requests/474 Extended direct_post to support redirect back to the verifier
                           We started to discuss this but decided to defer to the SIOP segment

Next Call
              The next call will be Monday, March 13th at 3pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230309/fd068f1e/attachment-0001.html>