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> 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>
> *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>
> 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://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
>
>
>
>
> <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

<https://www.transmute.industries>