[Openid-specs-ab] Meeting notes: May 18, 2023

[George Fletcher]

Attendees:
- Mike Jones
- Brian Campbell
- Joseph Heenan
- Sudesha Shetty
- Takahiko Kawasaki
- Giuseppe De Marco
- Bjorn Hjelm
- David Luna

Introductions
* Sudesha - first time, working on implementing OIDC4VCI, OIDC4VP

Agenda (in no particular order:)

   - Verifiable Presentations over BLE
   - DID method - Giuseppe
   - PRs for OpenID Connect
   - Native SSO for Mobile Apps
   - MODERNA - Mobile Operator Space [CIBA]


Verifiable Presentations over BLE - update

   - The draft has been adopted by the working group
   - Mike will publish the initial draft today and add it to the list of
   working documents


Security analysis of OpenID 4 Verifiable Credentials specifications

   - Work by Daniel Fett (PR 468)
   - Not yet adopted by the working group
   - Requesting review of the PR
   - After addressing the review comments will request a call for adoption


Verifiable Credentials working group

   - Still under consideration
   - Similar to what eKYC did a few years ago
   - Need to get the drafts approved as an implementers draft to make IPR
   issues simpler
   - To support the creation of the new working group, this working group
   needs to move all the related drafts to implementers draft


DID Method - Giuseppe

   - Looking at how allow OpenID Connect Federation and DID method
   resolution to work together well
   - Issue:
   https://github.com/vcstuff/draft-terbu-sd-jwt-vc/issues/41#issuecomment-1546743042
      - did:openid-trustchain:...
      - did:openid:example.it:oidc:rp[...]
   - Should the DID methods be registered with W3C?
   - Should the descriptions be added to the OpenID Connect Federation spec?
   - Who would use it?
   - Issue is that the federation spec currently requires an HTTPS URL
      - this doesn't allow for how to determine the trust chain
      - other issues?
   - The DID method resolution makes the trust determination explicit
   - Request raised by a community of developers more involved in the
   issuer-holder-verifier model wanting a DID mechanism for federation
   - Who would use it and why?
      - offline flows - put the full trust chain in the DID [static]
      - what to do about revocation of the "static" trust chain?
         - in Italy the trust chain expires in 24hrs
         - expiry time included in the trust-chain object within the DID
      - Why does the developer community want a DID?
         - It fits the model in which the developers are working
         - It hints at the trust resolution method. Not an issue for the
         Italy implementation.
         - In other contexts, the trust resolution is less defined and the
         DID method provides that clarity
      - Not a critical item for today - Giuseppe
   - DIDs are about proving possession of a key - Mike
      - in this context what key is being attested to and provable?
      - to prove control of the DID you prove control of a specific key? -
      Mike
         - could identify the "kid" and then prove control of that key -
         Giuseppe
         - for the did:openid:... the key-value is after the #
      - DIDs need to resolve to a DID Method document - Takahiko
      - There are some other DID methods that don't today require
      resolution to a DID method -- did:jwk, did:x509, did:key - Giuseppe
   - DID method 'openid' is a bit too generic - Takahiko
      - yes, this is probably too generic - Giuseppe
      - could add a suffix to help with determining resolution
      - openid configuration, jot issuer, could also be areas that could be
      involved in the resolution discussion - Takahiko
         - Not sure of the value of a new .well-known for jot-issuer
      - DID trust-chain may be more interesting for the offline use case -
   Giuseppe
      - Trust chain header parameter will work in the same way - Takahiko
      - The trust chain header only works in HTTPS bases solutions and the
      DID method could potentially work in other use cases - Giuseppe
   - Additional related document:
   https://docs.google.com/document/d/1Dk_8UmytCI4VhCx5VMnXmEzdXRvgJozGeq1GNHZOQik/edit


Pull Requests

   - 510 - [Federation] introductory text, metadata section, editorials
      - a couple of normative changes
      - there is an appendix describing other ways to define entity metadata
         - this requires a change from MUST to SHOULD
         - the appendix text is still in it's own PR
      - GAIN POC pilots are using Federation spec but getting the entity
      metadata via other methods
      - Other use case where the System of Record is in a DB but the
      publishing mechanisms still puts the entity metadata into the published
      documents
      - impacts to interop by moving from MUST to SHOULD - however, this
      choice has already been deployed in the real world
      - merge of PR approved - Giuseppe
   - 518 - Please review!!
      - Takahiko has reviewed and approves the merge

Agenda items not discussed:

   - Native SSO for Mobile Apps
   - MODERNA - Mobile Operator Space [CIBA]

______________________________________________________________________



The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230518/910e14bd/attachment-0001.html>