RE: An idea regarding "jws-2020"

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>
Sent: Thursday, January 19, 2023 2:08 PM
To: Markus Sabadello <markus@danubetech.com>
Cc: 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>