[Openid-specs-ab] Spec Call Notes 3-Apr-23

Mike Jones Michael.Jones at microsoft.com
Tue Apr 4 00:06:47 UTC 2023


Spec Call Notes 3-Apr-23

Mike Jones
Aaron Parecki
David Waite
Vittorio Bertocci
Joseph Heenan
Nat Sakimura
Dima Postnikov
Kristina Yasuda
Edmund Jay

PRs
              https://bitbucket.org/openid/connect/pull-requests/
              PR #508: OID4VP editorial after the full read.
                           Oliver created PR #509 suggesting minor changes
                           Kristina will merge it into her branch and then correct a few things
                           Kristina will then merge and Mike will publish, updating the review blog post
              PR #448: [Federation] Added appendix on using Web PKI cryptographic trust
                           Mike described in-person discussions on the PR in Yokohama
                           He described the desire to use existing metadata locations
                                         It would then be a deployment choice
                                         Kristina supported that
                           Kristina said that we also discussed the philosophy of not trusting TLS
                                         She said that there are multilateral federations that are willing to trust TLS
                           Kristina said it will confuse people if the whole spec says not to trust TLS but then allows it sometimes
                           Dima said that he sees a need to be able to profile the Federation spec
                                         He said that GAIN is using Automatic Registration and doesn't need Explicit Registration implementation
              PR #463: removing the requirement around JSON-LD processing (Issue #1840)
                           Kristina said there is still an ongoing conversation

Open Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              #1912: Implementers that are willing to trust TLS
                           Kristina wrote down some of what we discussed in Yokohama
              Lots of SPAM :-(
              #1887: Wallet attestation in SIOPv2 (implementation considerations)
                           Discussed in person in Yokohama
                           Depending upon how trust occurs, having a JWT attestation might be useful
                           (This is related to #1886)
              #1886: New client authentication method for Wallet attestation
                           This may require a new JWT attestation client authentication method
                           This is waiting for a concrete proposal

Needed changes for next Implementer's Drafts
              SIOPv2
                           Add client_id_scheme
                           Possibly refactor
              OpenID4VCI
                           Add client_id_scheme
                           There are several important PRs outstanding
                                         Cleaning up deferred issuance endpoint
                                         There are PRs addressing feedback received, including from Taka
                           Refresh implementation considerations will be added
                                         There are jurisdictions requiring periodic resigning over data to keep the signatures fresh
                           It's unclear that managing changing claim values is required functionality
                           We discussed using access tokens issued to the wallet, when the wallet can be a public client
                                         We shouldn't be using long-lived tokens with public clients
                                         DPoP is recommended for public clients that want to reuse tokens
                                         Ideally they would be sender-constrained
              Federation
                           Add description of option to use existing metadata in some profiles
                           Add description of option to trust Web PKI in some profiles
                           Technical issue about trust mark issuers

Liaison Statement
              Nat asked people for quick review of his e-mail "Liaison statements to ISO/IEC JTC 1/SC 27"
              Nat reported that submitted several public comments on NISTR 8389 - Security Considerations for Open Banking
              We also commented on the OECD Guidelines for Digital Identity
                           OECD guidelines were influential in creating GDPR

Next Call
              The next call will be Thursday, April 6 at 7am Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230404/fa65cb7f/attachment-0001.html>


More information about the Openid-specs-ab mailing list