[Openid-specs-digital-credentials-protocols] [minutes] EU-friendly DCP WG + SIOP call (PST 8am)

[chris.bormann at gmx.de]

Hi all,
Here are the minutes from 21st of march:

Attendees:

Christian Bormann
Joseph Heenan
Gail Hodges
Torsten Lodderstedt
Bjorn Helm
Daniel Fett
David Chadwick
Jin Wen
Juba Saadi
Oliver Terbu
Pedro Felix
Ryan Galluzzo
Sebastien Bahloul
Sudesha Shetty
Xavier Vila

Agenda:

- IPR reminder/ Note-taking
- Introductions/re-introductions
- Agenda bashing/adoption
- Events/External orgs
- Please vote for VCI Implementer’s Draft approval: https://openid.net/foundation/members/polls/328
- Discuss outstanding questions on request_uri extension, https://github.com/openid/OpenID4VP/pull/59
- Other open VP PRs: https://github.com/openid/OpenID4VP/pulls
- Do we want a VP implementers draft 3 “soon” and what should we target to include in it?
- VP profile for Browser API ( https://github.com/openid/OpenID4VP/issues/125 ) - are we good to start work on a PR to add the alternative proposal as an appendix in VP?
- Interop Event profiles for proposed EU interop event; https://drive.google.com/drive/u/3/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR

Introductions:

- Ryan Galluzzo, Identity Program lead for the NIST Applied Cyber Security Division

Events and general updates:

- OAuth Security Workshop in ~2.5 weeks
- In-person session scheduled on Friday after IIW (which requires registration).
- Ongoing poll for OpenID4VCI Implementers Draft

----
https://github.com/openid/OpenID4VP/issues/125 - Proposal for OpenID 4 VP profile for the W3C Digital Credentials API:

Torsten explains that there are 2 claims for a digital credential providers, "protocol" and "request". Protocol is the extension point, where you would specify protocols like openid4vp. The Browser API aims to replace other mechanisms for invoking wallets like Custom URI Schemes and also makes the cross device flow a lot more secure. Torsten explains that there would be one protocol identifier, "urn:openid.net:oid4vp" and for the simple mode,  the request resembles an OpenID4VP request but in pure JSON. Torsten explains that this introduces a new client_id_scheme "web_origin" for this flow, where we trust the Browser API origin information. The current proposal for Android is that every installed Wallet registers a matcher that would answer if the wallet can answer the requested presentation and the results of this matcher process is displayed to the user.
Torsten then goes on and explains another mode, where a request_uri is provided and the request object is signed with a key that belongs to an external trust framework (not web pki). This ties into the new request_mode post. A wallet nonce is included in the request, making sure that replay is not possible as the verifier needs to sign over the wallet provided nonce. The rest of the execution works as before but the response needs to be additionally encrypted. Torsten states that this proposal would leverage the Browser API and re-use the existing features of OpenID4VP as an easy migration path to integrate the Browser API features. 
Torsten proposes to create a PR that becomes an Appendix to the OpenID4VP spec that would not be merged before ID3 and collect feedback in the PR. David asks when this will be implemented in the OS? Torsten answers that Android already has this implemented behind a feature flag. Oliver comments that the last implementation he has seen was very specific to android and mdoc. Oliver later corrects himself, that he found a link that shows that android already implemented the general pattern of the current proposal: https://github.com/WICG/digital-identities/wiki/HOWTO:-Try-the-Prototype-API-in-Chrome-Android#verifier-api.
Torsten proposes again to create a PR in the repo and collected feedback in github. Oliver comments that Mike Jones and Tobias voiced their concerns and Joseph states that they would like to repeat this discussion in the APAC friendly call. Ryan asks what the timeline would look like for reviews and feedback. Joseph states that this would stay open at least for a couple of weeks while things get ready for ID3. Gail adds that several stakeholders (EC, NIST, California DMV) have asked about the shared roadmap of WICG and OpenID and how people are planning to deal with the alignment. Gail expects that in the coming weeks more people would be joining the calls and voice their asks and concerns. Joseph asks if anyone has an objection to the shown proposal. Oliver adds that he would like to have a repeat of this discussion on the APAC call. Torsten adds that until the PR gets started, the google document can be used for comments.

----
https://github.com/openid/oid4vc-haip-sd-jwt-vc/pulls - HAIP:

Joseph brings the focus to HAIP. Some open PRs and issues need attention and more projects are starting to look at HAIP.

----
https://github.com/openid/OpenID4VP/pull/59 - request_uri extension:

Torsten comments that there are a lot of approvals and that the remaining change requests circle around the question whether we can establish trust in the client. David brings up that the client_id is checked later on if it is trusted, then the flow goes on. Torsten says that at the suggested step, the client_id cannot be verified. Torsten asks about the formulation "if the client_id is false but identifies a trusted vendor" and David gives an example of an impersonation, where the client_id is not owned by the initiator of the call, but is a correct client_id in which case checking the request_uri is important to check. Torsten comments, that this would require a defined link between client_id and request_uri in a defined trust framework. Torsten shows his proposal to change the text from the PR.
David clarifies that his proposal was not to refuse outright if the request and client_id do not match, but ask the user. Torsten says that if the trust framework defines a relationship between client_id and request_uri, then requests where they don't match should be refused. Torsten asks about other opinions. Joseph proposes to open a separate issue for this and unblock the PR. David reiterates that there seems to be agreement for most cases and the current disagreement is only whether the wallet should abort or ask the user in that specific case. Oliver asks about x509_san_dns and how this would fit, but Torsten says that this is a different issue and should not be mixed up. Oliver asks to have a separate PR for the current discussion and merge this one. David says that his proposed "w to w" statement in the UML diagram should go into the PR describing the wallet checking the client_id  with the trust framework. Torsten asks David to rework the text after the discussion and make the step optional in the diagram. David agrees and Torsten goes back to the refusing the request for client_id not validating correctly and there is agreement to change from MUST to SHOULD.

----
OpenID4VP ID3:

Joseph mentions that we are approaching a point where an ID3 would make sense and this would help other entities like ISO with a stable version to reference. Joseph brings up the open PRs and proposes for the sd-jwt vc profile, the request_uri extension, the fixes mdoc/mdl section and the security issue over the client_id_scheme not being present in some places to be part of ID3. Joseph asks for people to review the PRs.

----
Interop Profiles for LSP Interop event:

Torsten presents the different tracks that will be tested in the interop event. Torsten shares a link (https://drive.google.com/drive/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR?pli=1) with all of the tracks. Torsten asks if there are particular questions regarding the current proposed tests. Sebastien asks about the Track 1, the MSO mdoc payload. Sebastien asks that in his understanding, the IssuerSignedDehydrated and NameSpacedData are necessary, whereas it is proposed as an "or". Torsten asks Sebastien to join a call following the WG call where this issue can directly be discussed. Juba asks if pre-auth code flow would also be an option, but Torsten answers that PID issuance will in his opinion always happen with the authorization code flow, so that was the focus, but is open for further discussion on this issue. Christian asks if participation might be possible even if not currently registered and Torsten answers that he will bring that question up. Oliver asks if it would be possible to align track 2 and track 1 and make the track 1 requirements a bit less strict/high (DPoP, wallet attestation etc.). Oliver goes on that relaxing the requirements would help with getting more people involved. Torsten asks Oliver to also join the upcoming meeting for test event discussions.