Re: Verifiable Credentials v1.1 released for public review

Hello all,

As Marty mentioned, this has been a hot topic in the IMS Global OB/CLR Conceptual Modeling group and at VC-EDU. While it is reasonably straight-forward to issue single achievement VCs, in education there’s use cases for embedded VCs and also chained VCs that should be modeled if there is to be acceptance in this space. 

I think it would be a great idea to have a CCG meeting agenda dedicated to the complex questions that are best answered by those who are experts on the signatures as well as the wallet app implementers who are considering how to handle this data. Beyond knowing what is possible, we need to consider what is reasonable to recommend for education organizations that can’t always rapidly respond to evolving technologies. Somewhere there’s a middle ground that meets some/ most of the needs now and opens up innovation.  

I can work with others at VC-EDU to bring the use cases and the questions. 

Thanks,

K.

--------
Kerri Lemoie, PhD
Director, Digital Credentials Research & Innovation
badgr.com <https://info.badgr.com/> | concentricsky.com <https://concentricsky.com/>
she/her/hers






> On Nov 10, 2021, at 8:52 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 11/10/21 5:58 AM, David Chadwick wrote:
>> I don't think this is exactly correct. Nesting of JWTs is already
>> supported when a JWT VP incorporates a JWT VC.
> 
> Uh oh. Looks like more vagueness in the JWT section of the VC spec. A few
> comments:
> 
> I believe the VC-EDU work requires arbitrarily nested VCs, so just a
> collection of VCs in a VP isn't the only thing they need to do. They may need
> to embed signed VCs in other signed VCs... you can't do that with JWT-based VCs.
> 
> You can do this if you use `proof` and Linked Data Integrity since that
> technology was designed to allow arbitrary nesting of VCs in other VCs.
> 
> The JWT stuff was never specified to support arbitrary nesting of VCs in VCs
> or multiple levels of signed nesting.
> 
> I've just now gone back and checked the JWT section of the spec (which I
> didn't write or implement), and it looks like there is no normative statement
> that says that you have to base-64 encode the `vp` property. All the spec says
> normatively is:
> 
> https://w3c.github.io/vc-data-model/#json-web-token-extensions
> """
> vp: JSON object, which MUST be present in a JWT verifiable presentation. The
> object contains the verifiable presentation according to this specification.
> """
> 
> That presumes a non-JWT encoding, so looks like the JWT section of the spec is
> missing any normative statement wrt. transformation to/from JWTs wrt.
> Verifiable Presentations.
> 
> ... and then there is one non-normative comment beside an example that hints
> that vp's are encoded in base64:
> 
> https://w3c.github.io/vc-data-model/#example-31-jwt-payload-of-a-jwt-based-verifiable-presentation-non-normative
> 
>> Thus it would be perfectly possible to nest a VC JWT in another VC JWT. It
>> is just that we do not have an example of this in the v1.0 or v1.1 spec.
> 
> We do have an example in the spec (link above), but it's clearly not based on
> any normative language in the specification.
> 
> VC 2.0 is probably going to extract the JWT section of the VC Data Model spec
> out into its own specification alongside the other LDI stuff, so we can fix
> this at that point.
> 
> -- 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/
> 
>