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

Fri May 17 12:49:09 UTC 2024

You can use sd-jwt to produce the W3C Verifiable Presentation object:

https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-presentations-with-sd-jwt

However this requires you to present a presentation as if it were a
credential.

And it creates a situation where you can have key binding in the
credentials and for the presentation layer.

Our implementation supports this, but it's awkward.

This stems from W3C defining a protocol message without having a concrete
protocol that is also defined, as opposed to just a data format.

As far as I know protocols decide if they want to support W3C presentations
or just W3C credentials... And oidc has so far, never supported W3C
presentations.

On Fri, May 17, 2024, 2:20 AM Jan Vereecken via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:

> 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.
>
>
>
>
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240517/596416f1/attachment-0001.html>