RE: An idea regarding "jws-2020"

I agree that providing clarity is the coin of the realm.

Mapping between representations, at least as defined for VC-JWT in the 1.1 spec, has proven to be problematic.  Better to have unambiguous native representations without any mapping used.  Eventually, I expect there to be a native JWT representation using normal JWT claims, a native CWT representation using normal CWT claims, and yes, native JSON-LD representations based on the 1.1 and 2.0 VC Data Models (which can be secured either using JWS or with data integrity proofs).

As an aside, why doesn’t draft-birkholz-scitt-architecture use CWT claims for its CBOR claims representation?  Is there a technical reason or they just didn’t do it.  Would it be useful for me to have that conversation directly with Henk?

Have a good weekend, everyone!

                                                       Best wishes,
                                                       -- Mike

From: Orie Steele <orie@transmute.industries>
Sent: Friday, January 20, 2023 6:15 AM
To: Kristina Yasuda <Kristina.Yasuda@microsoft.com>
Cc: Markus Sabadello <markus@danubetech.com>; public-vc-wg@w3.org
Subject: Re: An idea regarding "jws-2020"

> Using “vc-jws” to name another document that also signs using JWS, but payload of a different media-type, would be confusing and inappropriate.

Indeed, it is confusing.... But the confusion highlights important differences between the two approaches.

The payload of `vc-jwt` is not `application/credential+ld+json`.
This means that `vc-jwt` does not secure `application/credential+ld+json`.
This in turn implies that `vc-jwt` does not secure what we have been calling "The VC Data Model"... Instead, vc-jwt secures a wrapper around the vc data model, or in other words, vc-jwt secures a claim set which might contain a member "vc" or "vp".

A major reason for creating a new security format is to maintain the simplest possible approach to securing the vc data model, which means "no wrapper" and "no mapping".

There are production rules that currently apply to vc-jwt, that make this wrapper / mapping approach not acceptable to stakeholders who wish to leverage the vc data model.
In a JSON only world, I believe the wrapper might be acceptable by itself, but the mapping + dropping properties part is more problematic.
One way of thinking about this problem is to describe "vc-jwt" in terms of `application/credential+ld+json`.... This is the approach that was taken in 1.1, even though we had not yet registered a media type which makes it clear.
Under the vc-jwt 1.1 production rules, you start with `application/credential+ld+json` and map from it into claim set members to produce `application/credential-1.1+json` (proposed name see https://github.com/w3c/vc-jwt/pull/40).
Then if you decide to take the "normatively legal approach" of dropping all "mapped properties" from the `vc` member which would otherwise be of media type `application/credential+ld+json` you can obtain the "instead of" representation.
If you don't perform that last step, you end with the "in addition to" representation.
Both the "instead of" and "in addition to" "payload types" are different from `application/credential+ld+json`.

The fact that these 2 "vc-jwt" representations differ so substantially between each other and from `application/credential+ld+json`, is the primary reason some stakeholders prefer a seperate and simple way to secure `application/credential+ld+json` with a JWS.

A couple of informal proposals to consider:

1. Separate media types for "instead of" and "in addition to"... ( application/credential-1.1+json; mapping=instead-of .... application/credential-1.1+json; mapping=in-addition-to) ... names obviously for communication purposes and not real proposals.
2. Remove the "instead of option" (this would allow folks to rely on the `vc` member to behave exactly as `application/credential+ld+json`, which seems like a compromise to some degree... not a very elegant solution).
3. Create a new JWS profile for securing `application/credential+ld+json`, since neither existing JWT representation can be relied on to do so.

Perhaps, with working group consensus on refinement (breaking changes) to "vc-jwt" we can avoid the need for option 3 by leveraging 1 or 2.

However.... If we extend this conversation to consider CBOR, other wrinkles emerge, especially if we don't take option 3 above.

Will a future CBOR representation also contain `vc` or `vp` members?
Will a future CBOR representation also "drop mapped properties"?
Is it too late for us to set the correct precedent here?

The COSE community seems to prefer securing content types without mutating them...
https://ietf-scitt.github.io/draft-birkholz-scitt-architecture/draft-birkholz-scitt-architecture.html#name-envelope-and-claim-format

> payload type (label: 3): Media type of payload as a string, for example application/spdx+json
I feel that there is alignment with COSE that this working group should be considering.

The suggestion that the proposed "vc-jws" is "inappropriate" implies the approach taken by SCITT is also "inappropriate"....
We have discussed this in the IETF SCITT WG (which I also contribute to), and we feel confident in the current proposed approach.
As a side note, we chose that approach specifically because there are a LOT of important and unique media types that need to be secured to protect the integrity of software supply chains, "types of tokens" is not enough.

If we think that people are going to use both "mapped" and "unmapped" approaches with JOSE and COSE... If we think that they will use both "web token" and "signature over media type"...
I feel it would be more appropriate to define both approaches, and attempt to keep both approaches as simple as possible.

The good news is that thanks to our use of `media type` to communicate about the structure, we can clearly see the options on the table, and if we want, we can close or open doors to cross JOSE  / COSE alignment.

Regards,

OS



On Fri, Jan 20, 2023 at 1:24 AM Kristina Yasuda <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>> wrote:
A document, whose scope is “a profile of JWS for securing application/credential+ld+json”, would be a different document from vc-jws-2020, whose scope is “a profile of Data Integrity Proofs to use JWS to sign a payload”. So If the WG agrees to work on this new document, it would need to create a separate work item, and decide how to proceed with a current vc-jws-2020.

(Chair hat off) it is JWS that is used to sign in a document currently named “vc-jwt”. Using “vc-jws” to name another document that also signs using JWS, but payload of a different media-type, would be confusing and inappropriate.

If the WG decides to have two documents that both use JWS, but sign over a payload of a different media-type, it would be cleaner/clearer if both documents have the consistent naming – something like “vc-jws-<identifier of a media type>”. Which might mean clarifying the scope of the current vc-jwt and renaming it.

Best,
Kristina


From: Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>>
Sent: Thursday, January 19, 2023 2:08 PM
To: Markus Sabadello <markus@danubetech.com<mailto:markus@danubetech.com>>
Cc: public-vc-wg@w3.org<mailto:public-vc-wg@w3.org>
Subject: Re: An idea regarding "jws-2020"

Thanks for the feedback Markus and Shawn.

I agree with your comments.

I also agree with what Manu said on the recent WG call,
perhaps it would be better to just create a separate work item for "vc-jws"
that has a title that makes it clear it's a profile of JWS for securing application/credential+ld+json.

Also excellent points on the details of vocab behavior with and without transformation to RDF.

Catching those details can be important, but it costs compute.

I look forward to discussing further on a future call.

Regards,

OS



On Thu, Jan 19, 2023 at 3:25 PM Markus Sabadello <markus@danubetech.com<mailto:markus@danubetech.com>> wrote:

It's really confusing that vc-jws<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmute-industries.github.io%2Fvc-jws%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901792536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UecBT5ssFiYwAzX9htFC9P1hCpIouF8D1rCEbWtiHDw%3D&reserved=0> and vc-jws-2020<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fvc-jws-2020%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901792536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HFTKWcMA0oh9qJipc4BmnFcOUXpLixntr9%2BbrGITSsM%3D&reserved=0> sound so similar, but are very different things, so +1 to a naming discussion.

What I like about the quite recent vc-jws proposal is that it cleanly separates the data model layer from the security layer, unlike the commonly used vc-jwt which mixes the layers.

The downside of vc-jws as opposed to vc-jws-2020 is of course that it only signs the JSON-LD document, not the RDF dataset behind it.

If a JSON-LD @context changes, then a vc-jws signature would still be valid, even though the underlying data has changed, whereas a vc-jws-2020 signature would not be valid anymore.

This difference probably has some special significance in relation to the "default @vocab" proposal.
E.g. imagine a situation where some term is initially undefined in a @context, and then later it gets defined.
In this situation, a vc-jws signature would remain valid, whereas a vc-jws-2020 signature wouldn't.

Markus
On 1/18/23 14:55, Orie Steele wrote:
First, there is a proposal to change the name of the spec:

https://github.com/w3c/vc-jws-2020/issues/31<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fvc-jws-2020%2Fissues%2F31&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cc%2FOA0lh9ObdIiV%2BqOJIviOCMKijvLCRSUna3SHDAag%3D&reserved=0>
https://github.com/w3c/vc-jws-2020/pull/32<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fvc-jws-2020%2Fpull%2F32&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BthylROB0Go2x0%2Bz%2BKnFBDBG1F50OQXc0TpTTg20P24%3D&reserved=0>

Separate from this, we now have a way to secure "application/credential+ld+json", without using URDNA 2015.

https://transmute-industries.github.io/vc-jws/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmute-industries.github.io%2Fvc-jws%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8PCoHbyW8Ps6BzdEgG%2FQYFGJBBdwmOv8uquB8aziXjs%3D&reserved=0>
https://github.com/transmute-industries/vc-jws/blob/main/test-vectors/generate.js#L22<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftransmute-industries%2Fvc-jws%2Fblob%2Fmain%2Ftest-vectors%2Fgenerate.js%23L22&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sUaIP%2FZk7LbZ8IAMvTwkfFftKE1G0fIwC0DFgBQe1lA%3D&reserved=0>

This raises questions for me on the value of retaining this "data integrity suite".

Perhaps it would be more valuable to just define how to secure the media type for the core data model with JWS.

The working group has very limited bandwidth for technical contribution.

Since its inception, this work item has received very low contribution.

If I had to choose between having JsonWebSignature2020 or having a W3C spec that using JWS to secure the core data model (without URDNA2015),
I would happily take the latter... and if enough others made the same choice, I see no value in the former.

Wondering if we might drop URDNA2015 from JsonWebSignature2020, and refactor the spec to align with the vc-jws proposal above.

Regards,

OS

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wSsCwAC3Sv6zOjfa75ruodT203CKnxhRi3xUZyGzHP4%3D&reserved=0>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LY8%2B8TXTp6pYQ5EiBOaY5In8yiDl4Y8xvR85tFtboDY%3D&reserved=0>


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C06aa4eeaaeda42c3ea2e08dafa69a468%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638097628901948773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LY8%2B8TXTp6pYQ5EiBOaY5In8yiDl4Y8xvR85tFtboDY%3D&reserved=0>


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries/>