Re: Verifiable Credentials with COSE_Sign1

It's true that CBOR can be used to build compact representations, but as we
have seen with the mapping done for VC-JWT, the working group is not
guaranteed to build efficient or unambiguous mappings.

Focus would probably help with making the mappings better, another reason
to defer starting large amounts of additional work.

Furthermore, the suggestion that we should "redefine the core data model in
CBOR", can be interpreted as dismissive of the contributions of working
group members and the consensus that was established when accepting those
contributions.

In a sense, going back on working group decisions would erase the
contributions of working group members, and it would replace their work
with a fundamentally different approach.

Why would we ever do this when we have a perfectly useful content type to
switch on? Diversity is beautiful and worth preserving.

As I noted in my original post, I am comfortable defining
`application/credential+cbor` either after the working group finishes
fixing VC-JWT / JSON representations, or in a subsequent charter of the WG,
I will vote for the latter if given the opportunity.

Solutions like SD-JWT or JWP still need to support JSON serialization.

<trolling> Unless they are not planning on supporting JSON at all, in which
case... I question why the JOSE WG is being resurrected from its death as
we speak, </trolling>

Clearly there is still interest in securing JSON... Likely there is even
more interest in securing JSON than CBOR, especially at W3C.

The working group is not learning anything new from these debates, it's the
same people saying the same things they have always said.

That does not make them wrong, but it's not a good use of anyone's time to
keep hearing the same points repeated.

I ask for the chairs (Brent and Kristina) to establish consensus on this
topic, since it appears to be delaying constructive contributions to
specifications.

Does our working group charter permit us to develop 2 core data models
without rechartering?

Please give the working group a clear decision on this, so that
rechartering can start or progress can be made.

Regards,

OS





On Tue, Dec 6, 2022 at 6:06 PM Mike Jones <Michael.Jones@microsoft.com>
wrote:

> Great data point, Tobias!  True CBOR representations can have data
> structure representations that are an order of magnitude smaller than JSON
> representations.
>
>
>
> *From:* Tobias Looker <tobias.looker@mattr.global>
> *Sent:* Tuesday, December 6, 2022 5:03 PM
> *To:* Orie Steele <orie@transmute.industries>; Manu Sporny <
> msporny@digitalbazaar.com>
> *Cc:* W3C VC Working Group <public-vc-wg@w3.org>
> *Subject:* Re: Verifiable Credentials with COSE_Sign1
>
>
>
> Hi All,
>
>
>
> Just chiming in on this thread with some additional context and learnings.
> We successfully rolled out a CWT based VC solution for NZ government
> issuing several million credentials.
>
>
>
> Specification here
>
>
>
> https://nzcp.covid19.health.nz/
>
>
>
> In general the approach was more a mapping based approach as suggested by
> Mike e.g VC Data model -> CWT then securing the data model with COSE_Sign1
> as suggested by Orie. While i'm not opposed to a "securing the data model
> approach" (I can see potential merit), that would not have worked in our
> particular case as the JSON representation would have caused the resulting
> payload to exceed the target QR code version (size) that resulted in
> reliable scanning.
>
>
>
> Thanks,
>
> [image: Mattr website]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>
>
>
>
> *Tobias Looker*
>
> MATTR
> CTO
>
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
>
> [image: Mattr website]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>
>
> [image: Mattr on LinkedIn]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>
>
> [image: Mattr on Twitter]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>
>
> [image: Mattr on Github]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>
>
>
> This communication, including any attachments, is confidential. If you are
> not the intended recipient, you should not read it - please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
> ------------------------------
>
> *From:* Orie Steele <orie@transmute.industries>
> *Sent:* 07 December 2022 12:42
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* W3C VC Working Group <public-vc-wg@w3.org>
> *Subject:* Re: Verifiable Credentials with COSE_Sign1
>
>
>
> EXTERNAL EMAIL: This email originated outside of our organisation. Do not
> click links or open attachments unless you recognise the sender and know
> the content is safe.
>
>
>
> Looks like things have progressed a bit, I had originally created this
> response to Mike's initial comment:
>
> > The “coupling” that you’re not in favor will result in more natural
> implementations, at least as I see it.
>
> There are currently 0 examples of a CBOR core data model, all the
> verifiable credential formats that meet TR 1.0 or 1.1 are in JSON.
>
> The core data model should define a concrete serialization for JSON.
>
> The content type of this serialization should be
> `application/credential+json`
>
> Securing JSON might be accomplished with either JWS or COSE Sign1 (which
> would be more compact than a JWS, but potentially less well supported by
> off the shelf tooling).
>
> I don't see why it would be "more natural" to start by defining a data
> model that has never existed before, and that nobody is using today.
>
> Especially while we don't have a good solution for securing the one that
> we have today, which is JSON.
>
> I also question if the working group has the expertise or bandwidth to do
> a CBOR based data model, it's certainly not a priority for us right now.
>
> Our primary focus is on making it very easy and very safe to secure JSON.
>
> Perhaps in our next charter we might consider adding a core data model
> representation for CBOR.
>
> I think it's a mistake to load up on that in the current charter, and with
> the current issues with VC-JWT...
>
> Better to solve the current can of worms before opening a new one.
>
> Regards,
>
>
> OS
>
>
>
> On Tue, Dec 6, 2022 at 4:34 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> On Tue, Dec 6, 2022 at 5:09 PM Mike Jones <Michael.Jones@microsoft.com>
> wrote:
> > As extensively discussed in the special topic calls, an "open world
> model" is not a interoperability requirement and is not a deliverable in
> our charter.  We can (and I believe will) do better than that.
>
> The specification has asserted that it supports an "open world model" from
> v1.0:
>
> https://www.w3.org/TR/vc-data-model/#extensibility
>
> The VCWG has repeatedly achieved consensus on that during the VC 1.0 work.
>
> Here is the decision from April 2019 when what you are stating above
> was raised (by Microsoft) the first time, discussed by the WG, and a
> consensus position to support open world was made:
>
> https://github.com/w3c/vc-data-model/issues/483#issuecomment-482910429
>
> and the resulting text, that achieved WG consensus:
>
> https://www.w3.org/TR/2019/REC-vc-data-model-20191119/#extensibility
>
> and then again in the VC 1.1 work:
>
> https://www.w3.org/TR/2022/REC-vc-data-model-20220303/#extensibility
>
> Asserting the opposite of what the consensus position has been in the
> group for years doesn't make it true.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> <https://www.transmute.industries/>
>


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

<https://www.transmute.industries>