W3C home > Mailing lists > Public > public-credentials@w3.org > December 2021

RE: Verifiable Credentials v1.1 released for public review

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Date: Wed, 1 Dec 2021 16:24:13 +0000
To: "dzagidulin@gmail.com" <dzagidulin@gmail.com>, "public-credentials@w3.org" <public-credentials@w3.org>
CC: Marty Reed <Marty.Reed@randasolutions.com>
Message-ID: <MWHPR1301MB2094D6FA36BCE381B31D61B5C3689@MWHPR1301MB2094.namprd13.prod.outlook.com>
RE: For what it's worth, I think that nesting VCs in each other is often a red flag
If you’re going to declare something like this, can you provide some backup/evidence?

Counter example: A use case I’m working on right now is embedding a VC for an NFT in the credentialSubject of an outer VC.  The outer VC is used to establish ownership of the inner NFT VC (for example).  There’s dozens of use cases that spring from this basic pattern.

For specific use case examples, checkout https://twitter.com/mwherman2000/status/1465372806670176259  as well as all the replies to: https://twitter.com/windley/status/1465379064257003521

Michael Herman
Trusted Digital Web

From: Dmitri Zagidulin <dzagidulin@gmail.com>
Sent: Tuesday, November 9, 2021 5:19 PM
To: public-credentials@w3.org
Cc: Marty Reed <Marty.Reed@randasolutions.com>
Subject: Re: Verifiable Credentials v1.1 released for public review

Hi Marty,

For what it's worth, I think that nesting VCs in each other is often a red flag. In most cases (including the educational / transcript ones), you'd be better off linking to other VCs, instead of embedding. Or using a Verifiable Presentation to bundle.

On Tue, Nov 9, 2021 at 3:54 PM Marty Reed <Marty.Reed@randasolutions.com<mailto:Marty.Reed@randasolutions.com>> wrote:
I did not see it specifically noted in the document, however I have further reviewed and it is in the implementation guide for 1.0 not in the spec itself.

Forgive my lack of experience with standards development here:

Is the implementation guide only developed after approval of the spec?

Would it be prudent to acknowledge in the spec nesting is supported?

Nesting VCs has been a hot topic in the IMS Global OB/CLR Conceptual modeling discussion for 3.0/2.0 respectively.


Marty Reed | Chief Executive Officer
RANDA Solutions | 2555 Meridian Blvd | Suite 300 | Franklin, TN 37067
office 615 467 6387 | direct 615 915 5446 | fax 615 613 0517

Confidentiality Disclaimer: This email and any attached files are confidential and intended solely for the use of the individual or entity to which it is addressed. If you are not the person or entity to whom this is addressed, or the person responsible for delivery of this email to the intended recipient, you have received this email in error. Any use, dissemination, distribution, forwarding, printing or copying of this email including attachments is strictly prohibited. If you received this email in error, immediately delete it from your system without copying and notify the sender so that our records can be corrected.

-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Sent: Tuesday, November 9, 2021 2:35 PM
To: public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: Verifiable Credentials v1.1 released for public review

On 11/9/21 2:03 PM, Marty Reed wrote:
> Will the v1.1 spec no longer support nesting VCs as in the 1.0 spec?

v1.1 is fully backwards compatible with v1.0. If someone thinks that it isn't, please let us know.

Nesting VCs is fully supported when using the `proof` property (via Linked Data Integrity).

Nesting VCs is not supported when using JWTs (but that has always been the case).

Again, what was possible with v1.0 is still possible w/ v1.1. Is there something that led you to believe that this has changed, Marty?

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

Received on Wednesday, 1 December 2021 16:24:29 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:25 UTC