Re: An idea regarding "jws-2020"

Inline:

On Fri, Jan 20, 2023, 6:38 PM Mike Jones <Michael.Jones@microsoft.com>
wrote:

> 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?
>
The purpose of what SCITT calls "claims" or "signed statements" is to
secure media types used in the wild, such as:

https://www.iana.org/assignments/media-types/application/spdx+json

There exist many unique and none interoperable media types that support the
software supply chain...  Including software bill of materials,
vulnerability disclosure reports, container images, etc....

The SCITT COSE header leverages the registered claim names to secure these
various formats... But this requires the entire payload to be dedicated to
the media type, leaving only the header to carry what the vcwg would call
"proof metadata".

  Is there a technical reason or they just didn’t do it.
>

Technical reason, see above.

Would it be useful for me to have that conversation directly with Henk?
>
>
>
Certainly, we'll both be at the next IETF in person.

As an aside, SCITT uses RATs terminology which is very similar to VC Data
Model.

https://www.rfc-editor.org/rfc/rfc9334.html#section-3

The RATs WG has an interesting, and inspiring token spec:

https://www.ietf.org/archive/id/draft-ietf-rats-eat-19.html#section-1.2

Which I think highlights very well that tokens and generic signatures over
media types are both useful approaches.

Have a good weekend, everyone!
>

Likewise.

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