[Openid-specs-digital-credentials-protocols] Minutes from 16th May 2024 DCP WG call

Fri May 17 07:19:50 UTC 2024

Hi Joseph and other members,

Regarding

> Two people asked about how to return multiple credentials fulfilling the same single requirement; that hadn’t come up before and we probably need a way to express if the verifier wants all the matches or just one - new issue to be opened for that.

I just want to qualify my question further.

I was thinking more of the case where a single presentation is answering multiple credentials requests.

Specifically W3C VCDM enables presentation of multiple credentials, bound to the same identifier, in a single presentation object. In contrast, to my knowledge,  SD-JWT VC does not have this.

For the example, let’s conceptually represent this as jwt_vp_json_a = [jwt_vc_json_1, jwt_vc_json_2], where jwt_vc_json_1 answers my_cred_1 and jwt_vc_json_2 answers my_cred_2.

Does the solution envisaged then repeat the presentation object and figure out in the submission how to reference the correct credential

{
  “my_cred_1”: “jwt_vp_json_a”,
  “my_cred_2”: “jwt_vp_json_a”
}

Or, do we require multiple presentation object, each one replying to exactly one of the request

jwt_vp_json_b = [jwt_vc_json_1]
jwt_vp_json_c = [jwt_vc_json_2]

{
  “my_cred_1”: “jwt_vp_json_b”,
  “my_cred_2”: “jwt_vp_json_c”
}

Or, do we allow more flexibility, but increasing complexity in response structure.

[
  {
    “request”: [“my_cred_1”, “my_cred_1”],
    “response”: “jwt_vp_json_a”
  }
]

Regards,
Jan

From: Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols-bounces at lists.openid.net> on behalf of Joseph Heenan via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net>
Date: Thursday, 16 May 2024 at 18:34
To: Digital Credentials Protocols List <openid-specs-digital-credentials-protocols at lists.openid.net>
Cc: Joseph Heenan <joseph at authlete.com>
Subject: [Openid-specs-digital-credentials-protocols] Minutes from 16th May 2024 DCP WG call

Participants:

Joseph Heenan
Kristina Yasuda
Daniel Fett
Andreea Prian
Arjen van Veen
Bjorn Hjelm
Brian Campbell
gabe
Jan Vereecken
Jin Wen
Juba Saadi
Michael Jones
Oliver Terbu
Pedro Felix
Rajvardhan Deshmukh
Ryan Galluzzo
Sebastian Birckerle
Sebastian Bahloul
Sudesh Shetty
Lukasz Jaromin

Events:

There will be a hybrid meeting with in-person participation for those at Identiverse; if you would like to attend in person please register on eventbrite:

https://www.eventbrite.com/e/openid-foundation-dcp-wg-hybrid-meeting-at-identiverse-tickets-902324616217

It was proposed to cancel the normal working group meetings during Identiverse & EIC and no one objected.

VP Query Language Proposal:

Daniel shared the latest thoughts on the query language, presenting an evolution of the proposal created during IIW that meets the various requirements that were agreed by the working group, that includes some feedback from implementers that looked at the previous proposal: https://hackmd.io/1siVhjzOTWOE9ppdF_t57A?view

There was some discussion over the how the logic of “and/or” requests is expressed; Daniel said the current proposal is the simplest they could come up with.

Two people asked about how to return multiple credentials fulfilling the same single requirement; that hadn’t come up before and we probably need a way to express if the verifier wants all the matches or just one - new issue to be opened for that.

Jan asked where both ‘format’ and the name of the format specific parameters object (e.g. “vc+sd-jwt”) are required. Daniel said that ‘format' is necessary so there is a clear place for the verifier to figure out if it supports the requested format, and then there’s also a desire to collect the format specific keys into a sub-object.

Jan asked about implementations. There aren’t any yet that we’re aware of.

Kristina asked if we wanted to proceed with a new query language format and if this proposal was a good way to proceed.

Jan, Arjen, Brian, Michael J, Oliver, Gabe agreed it was a useful starting point. No one raised objections to using it as a starting point. Oliver wasn’t sure about the advances syntax features in example 7.

Next step is to open an issue.

VP Transaction Data:

Kristina has opened 4 new issues for 4 specific points that need discussion, all tagged with the ’transaction data’ label.

Issue 173: The verifier needs an easy way to check the wallet is approve what it’s requested; given the difficulties of comparing json objects having the transaction request base64url encoded in the request & response seems like the best solution right now.

VP PRs:

#175 Add text/diagram for siopv2 conditional cred req flow
https://github.com/openid/OpenID4VP/pull/175 to solve https://github.com/openid/OpenID4VP/issues/86

Please read and give feedback.

VCI PRs/issues:

https://github.com/openid/OpenID4VCI/pull/314

Removed authorization_pending as discussed in previous meetings and notified to mailing list. No objections raised.

https://github.com/openid/OpenID4VCI/pull/319

As per previous working group discussions, clarify how encryption works on batch endpoint - please review.

https://github.com/openid/OpenID4VCI/pull/321 - adds a new error code to credential endpoint for the issuer to indicate it’s denying the request - please review.

https://github.com/openid/OpenID4VP/issues/171 - “nonce” handling should be more explicit.

Kristina pointed out that SD-JWT & W3C LDP sections do contain wording; Oliver will review it and raise a PR if it can be improved.

https://github.com/openid/OpenID4VP/issues/124 - client_id_scheme security considerations

We need to come to a decision on this. The feeling when discussed at OSW seemed to be folding the client_id_scheme into the client_id in some way so the existing iss/aud fields in JWTs can be used etc. To be discussed on next week’s WG calls.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240517/4b055f3d/attachment-0001.html>