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

Brian Campbell bcampbell at pingidentity.com
Sat May 18 13:34:03 UTC 2024 

On Fri, May 17, 2024 at 12:54 PM Orie Steele <orie at transmute.industries>
wrote:

>
>
> On Fri, May 17, 2024 at 1:33 PM Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
>>
>>
>> On Fri, May 17, 2024 at 10:03 AM Orie Steele <orie at transmute.industries>
>> wrote:
>>
>>> Hey Brian,
>>>
>>> On Fri, May 17, 2024 at 10:44 AM Brian Campbell <
>>> bcampbell at pingidentity.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 17, 2024 at 6:49 AM Orie Steele via
>>>> Openid-specs-digital-credentials-protocols <
>>>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>>>
>>>>> 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
>>>>>
>>>>
>>>> What is/was the rationale for using sd-jwt to produce the W3C
>>>> Verifiable Presentation object?
>>>>
>>>
>>> Conformance to the Core Data Model as described in:
>>> https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#verifiable-presentations
>>>
>>
>> But why? Conformance to the Core Data Model for W3C VCDM v2.0 to secure
>> Verifiable Presentations using plain old JWT/JWS seems more fitting and
>> sufficient (or even COSE if you prefer, which I believe you do). The
>> Verifiable Credential(s) inside the Verifiable Presentation would/could be
>> an SD-JWT but I don't see the rationale for securing the Verifiable
>> Presentation itself with SD-JWT.  What part of the *Presentation* does it
>> make sense to have selectively disclosable?
>>
>
> Holder supplied claims, as I indicated in the previous email.
> Also individual credentials, each which could also have internal
> disclosures.
>

None of that needs or even benefits from selective disclosure at the layer
of securing Verifiable Presentations.




>
> And since it's on the horizon, you can nest SD-CWT just as easily as
> SD-JWT, if not easier because of no string binary inflation.
>
> The argument reduces to an argument against nested tokens, regardless of
> disclosability... nested tokens have use cases.
>

That may be an argument to be had but it is absolutely not the one I'm
trying to make here.





>
>>>
>>>
>>>> As I said over in this PR
>>>> <https://github.com/w3c/vc-jose-cose/pull/270#issuecomment-2108832855>
>>>> (which I'm now regretting having gotten involved in),maybe I'm not seeing
>>>> the grand vision or something but securing a VP with SD-JWT doesn't really
>>>> make sense to me.
>>>>
>>>
>>> Because VPs don't make sense? or because JWT / COSE is a better path to
>>> secure them?
>>>
>>
>> Maybe we are saying the same thing...
>>
>
> I think we might be : )
>

Maybe? Maybe not? I'm not sure anymore :)




>>
>>>
>>> To me, it's JSON with a media type, I am not sure it needs a grand
>>> vision beyond that.
>>>
>>> There are important protocol considerations for VPs though, which are
>>> described here:
>>>
>>>
>>> https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#presentations-including-holder-claims
>>>
>>> You can't have compatibility with this part of the W3C Technical
>>> recommendation if you don't enable a way to secure VPs with JWT, SD-JWT,
>>> COSE or ...
>>>
>>
>> Again, even to have compatibility with that part of the W3C Technical
>> recommendation or however that is said, specifically the very concept or
>> need to secure VPs with SD-JWT is a piece that seems nonsensical.
>>
>
> If the VCWG sees value in securing holder supplied claims with JWT, I
> don't see why it would not make sense to secure them with SD-JWT,
>

Mostly because it doesn't make sense and there's a real cost to having yet
another option in an arena where there are arguably way too many options
already.



> unless the goal was to show that SD-JWT is less useful for presentations
> and more useful for credentials...
>

I have no idea about the goal(s) of the VCWG but SD-JWT is absolutely less
useful for presentations and more useful for credentials (at least in the
way vc-jose-cose and VCDM seem to be wanting to do things).



>
> This seems like generic feedback for the VCWG...
>

You are right, of course, but I've not found a way to engage with that WG
that feels productive. Your email on this thread came across my inbox and
it seemed like a decent opportunity in a different forum to try and ask
about the motivation/rational behind 3.2.2 Securing JSON-LD Verifiable
Presentations with SD-JWT
<https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/#securing-json-ld-verifiable-presentations-with-sd-jwt>,
which I thought you had written. But I just tried to look at some of the
associated history in https://github.com/w3c/vc-jose-cose and it would seem
my assumption of your authorship is wrong. So me asking you to explain
something you didn't do doesn't make a lot of sense either. Sorry! At least
it adds one more point of confusion to an already confusing thread :)



> I tried to explain this previously:
>
> https://github.com/transmute-industries/audacious-presentations
>
> The conclusion I came to from discussions was that it was going to happen
> regardless of how confusing it is...
> The only way to eliminate it would be for the VCWG to drop verifiable
> presentations, which they won't do.
>

This is not unrelated but a bigger topic than I was trying to get at.

I will just take the opportunity to comment, however, that we are trying to
move away from the term Fnord to describe an SD-JWT with a Key Binding JWT
and nearly six months later look close to settling on using SD-JWT+KB.



>
>
>>
>>
>>
>>
>>>
>>>
>>>>
>>>>
>>>> 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.
>>>>>
>>>>
>>>> Again, maybe I'm not seeing the grand vision or something but that
>>>> doesn't sound right to me*. I would agree though that the protocol and
>>>> message layering in all this is sometimes confused and often confusing.
>>>>
>>>> *  these seem like they are W3C Verifiable Presentations...
>>>>
>>>> https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.1.3-5
>>>>
>>>> https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.2.3-5
>>>>
>>>
>>> This is not a W3C VP:
>>>
>>>  {
>>>     "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
>>>     "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
>>>     "aud": "https://client.example.org/cb",
>>>     "nbf": 1541493724,
>>>     "iat": 1541493724,
>>>     "exp": 1573029723,
>>>     "nonce": "n-0S6_WzA2Mj",
>>>     "vp": {
>>>         "@context": [
>>>             "https://www.w3.org/2018/credentials/v1"
>>>         ],
>>>         "type": [
>>>             "VerifiablePresentation"
>>>         ],
>>>         "verifiableCredential": [
>>>             "eyJhb...ssw5c"
>>>         ]
>>>     }
>>> }
>>>
>>> it's an object that contains a claim called "vp" which might contain a
>>> JSON-LD VP, but it's malformed, because of the structure of
>>> "verifiableCredential".
>>>
>>> See:
>>> https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#enveloped-verifiable-credentials
>>>
>>> Also, per
>>> https://w3c.github.io/vc-jose-cose/#securing-verifiable-credentials
>>>
>>> The JWT Claim Names vc and vp MUST NOT be present in any JWT Claims Set.
>>>
>>
>> This seems to be a miscommunication about versions of the W3C VCDM and/or
>> OIDF protocols. Which does further confuse these discussions and I
>> apologize for my part in confounding any such confusion.
>>
>
> Seems like you are providing more clarity than harm here, cross SDO
> coordination is not required to make sense : )
>
>
>> You are correct in saying "oidc has ... never supported W3C
>> presentations" where OIDC is OpenID Connect. But I'm pretty sure that
>> "OpenID for Verifiable Presentations" (which is not OpenID Connect)
>> supports Verifiable Presentations, even W3C ones, although to your points
>> above it seems that explicit support is only for v1.1 of the VCDM and not
>> v2.0.
>>
>
> Yes, and as a general comment, most protocols that want to use nonces, or
> key binding, or attestation will probably be frustrated with verifiable
> presentations... because it's prescribing a protocol format, that doesn't
> work nicely in every protocol or transport... for example, if I am doing
> NFC / Bluetooth with CBOR or TLV... why do I need to wrap my presented
> credentials in JSON... short answer is, you need to do that to comply with
> the W3C spec and produce a conformant presentation, or explain why you
> produce conformant credentials but you don't support conformant
> presentations with holder asserted claims.
>
>
>>
>>
>>
>>
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged material for the sole use of the intended recipient(s). Any
>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>> If you have received this communication in error, please notify the sender
>>>> immediately by e-mail and delete the message and any file attachments from
>>>> your computer. Thank you.*
>>>
>>>
>>>
>>> --
>>>
>>>
>>> ORIE STEELE
>>> Chief Technology Officer
>>> www.transmute.industries
>>>
>>> <https://transmute.industries>
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240518/f96d83ee/attachment-0001.html>

More information about the Openid-specs-digital-credentials-protocols mailing list