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

> It's really confusing that vc-jws
> <https://transmute-industries.github.io/vc-jws/> and vc-jws-2020
> <https://w3c.github.io/vc-jws-2020/> 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://github.com/w3c/vc-jws-2020/pull/32
>
> 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://github.com/transmute-industries/vc-jws/blob/main/test-vectors/generate.js#L22
>
> 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://www.transmute.industries>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>