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

Orie Steele orie at transmute.industries
Fri May 17 18:53:55 UTC 2024 

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.

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.



>
>
>
>>
>>
>>
>>> 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 : )


>
>
>
>
>
>>
>> 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, unless the goal
was to show that SD-JWT is less useful for presentations and more useful
for credentials...

This seems like generic feedback for the VCWG... 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.


>
>
>
>
>>
>>
>>>
>>>
>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240517/7cedd06b/attachment-0001.html>

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