RE: Verifiable Credentials with COSE_Sign1

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,

[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<mailto:tobias.looker@mattr.global>

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

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

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

[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<mailto:orie@transmute.industries>>
Sent: 07 December 2022 12:42
To: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Cc: W3C VC Working Group <public-vc-wg@w3.org<mailto: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<mailto:msporny@digitalbazaar.com>> wrote:
On Tue, Dec 6, 2022 at 5:09 PM Mike Jones <Michael.Jones@microsoft.com<mailto: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<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries/>