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

Sat May 18 15:56:37 UTC 2024

<snip>

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.
>

The benefit is that if you were only speaking SD-JWT, you don't need
another format for presentations... Although, in this case, the only
difference might be a trailing tilde on the outermost token.

> 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.
>

I don't think you are arguing this, I think you are presuming it... A VP of
a few VCs is simply a nested token with some special claim semantics.

If you implemented SD-JWT, you already implemented JWT, and therefore you
already have to choose the token type for any nesting cases in profiles:

JWT -> SD-JWT -> JWT ...
SD-JWT -> JWT -> SD-JWT ...
SD-JWT -> SD-JWT -> SD-JWT ...
JWT -> JWT -> JWT ...

Were it not for the tilde, all of these could have just been the last one,
with different crit headers.

I've taken us off the core issue of VCs and VPs, because I care more about
the cryptographic building blocks, than their assembly in a specific W3C
profile.

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

I think we agree that VPs are confusing, but we seem to disagree that
limiting the securing format for them is less confusing.
Perhaps I am biased by my past experience at W3C and other SDOs, where it
often takes more text to explain things, and the outcome is not necessarily
better clarity.

> 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.
>

If you are processing an application/vp+ld+json+jwt (sigh)... of an
application/vc+ld+json (data integrity) and an
application/vc+ld+json+sd-jwt (sd-jwt+kb) and an
application/vc+ld+json+cose....
Yes, you're paying (in CPU cycles and CVE attack surface) for the
indecision of the W3C VCWG... but I don't think limiting the securing
formats of a VP saves you much... That's like $5 off a $10k purchase.

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

: ) the purpose of "vc-jose-cose" is to secure the media types defined in
the core data model (application/vp+ld+json, and application/vc+ld+json),
using the most natural standard cryptographic building blocks from IETF.

SD-JWT is included because it is presumed to be a future IETF standard with
lots of implementations and adoption in use cases that will care about the
media types above.

If a sufficient number of implementers of those use cases showed up to W3C
and requested SD-JWT to be limited to credentials, I imagine the W3C
Editors would be forced to make those updates.

> 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 wrote some of the text in those sections, but I don't control the design
of the VCWG.

If I had a magic wand I could wave to help industries adopt digital
credentials this is what I would do:

1. Move the parts of mDoc that are not already at IETF to IETF so people
could easily read them.
2. Leave SD-JWT where it is, but explain in slightly more detail that it's
meant for use cases where CBOR and mDoc can't be used, including cases
where the claimset is a special flavor of JSON, or the issuer and verifier
ecosystem can't afford to upgrade to CBOR, but holders could benefit from
more control and autonomy.
3. Have the W3C VCWG only define the structure of credential claimets in
JSON-LD, make securing them with COSE a MUST and securing them with SD-JWT
a SHOULD, allow other approaches, but make them NOT RECOMMENDED.
4. Ship a simpler version of presentation exchange much earlier that worked
for SD-JWT and mDoc.

What makes W3C VCs and VPs confusing is that their scope is large, and
there is built in extensibility at every layer, except for JSON-LD (notice
the +ld+json on the media types)...

Identity: Certificates, DID Documents, Issuer/Holder Metadata
Credentials: JSON-LD
Presentations: JSON-LD
Extensions (Schema or Status): JSON-LD
Security: DataIntegrity (only for JSON-LD), JWT (only for JSON),
SD-JWT  (only for JSON), COSE (could secure other media types, beyond
+json), ... (implicitly anything that secures JSON-LD, could be used to
create VCs and VPs)

Early versions of vc-jose-cose were just COSE and SD-JWT... JWT was added
because selective disclosure appeared to not be an essential requirement,
and there were concerns that SD-JWT might not be widely enough adopted to
be an easy way to secure the core data model.... We might argue that in
2024 every credential should support selective disclosure and key binding,
but I doubt that argument is winnable at W3C.

W3C WGs have charters that expire, and work needs to be done within the
window, this makes coordinating with other organizations potentially
difficult, since normative dependencies may not be stable in time for
publication, or production rollouts.

This impacts what is included in the TR, it's often stuff that *might* gain
adoption in the gap between chartering (did:web gained adoption between DID
Core charters), and it's often framed in such as way that if a few options
fail, there is still at least one solution which the market can rely on...
at least that's been my observation of W3C DIDs and VCs.

It will be interesting to see what happens between the current VCWG charter
for 2.0 and 3.0... I don't have a crystal ball, but I would suspect there
will be more adoption of cose (which is what mdoc is), sd-jwt and data
integrity.

Even if there is a "clear winner", some parts of the industry will continue
to rely on other formats, I'm still reviewing drafts that rely on XMLDSig
at IETF...
Perhaps 10 years from now, someone will be sighing and reviewing VPs in
SD-JWT format : )

<snip the rest>

So where does this leave OIDC4VP?

Any protocol that can carry VCDM v2.0 Verifiable Presentations can carry
SD-JWT VPs...
Regardless of if that is a thing that makes sense for the use case the
protocol is deployed to support.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-03#section-3.2.2.1.1

Defines the "vct" claim, which expresses the type of verifiable credential,
which is analogous to https://w3c.github.io/vc-data-model/#types

AFAIK, there is no "vpt" claim, because as we have discussed, W3C VPs don't
make much sense to folks who are not working in JSON-LD.

Luckily, v2.0 of the VCDM has addressed this problem, by making the payload
of an application/vp+ld+json+sd-jwt a media type defined in the core data
model: application/vp+ld+json

So if you wanted to "type" your SD-JWT JSON-LD VP, you can do so using the
same approach you would use to "type" your JSON-LD VC.

DIF presentation exchange already used this mechanism:

https://identity.foundation/presentation-exchange/#presentation-submission---verifiable-presentation-2

"""
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://identity.foundation/presentation-exchange/submission/v1"
  ],
  "type": [
    "VerifiablePresentation",
    "PresentationSubmission"
  ],
...
"""

And folks working on supply chain traceability also use this mechanism:

https://w3c-ccg.github.io/traceability-vocab/#workflow-instance

"""
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/traceability/v1"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type":
  [
    "VerifiablePresentation",
    "TraceablePresentation"
  ],
"""

This approach is compatible with one of the original links you provided:

https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.2.3-5

With the only caveat that "data integrity proofs" are not the only
mechanism for securing VCDMv2 conformant Verifiable Presentations, as we've
hopefully now demonstrated... for better or worse.

Happy to answer any questions about this, or if you fear a public list
discussion, you may DM me directly.

Regards,

OS

-- 

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/20240518/fde2fa68/attachment-0001.html>