Re: Question About Signatures & Contexts

That’s exactly what I needed to know. 

I was reminded this week that the Open Badges V2 spec still considers a badge valid if it contains extra fields. It’s hard to know how many may do this but as we are strategizing for the next version of Open Badges as VCs, it sounds to me like the recommendation is if additional fields are needed, include an additional @context to describe them much like Open Badges extensions do already.

Thanks!

Kerri





> On Jul 30, 2021, at 10:15 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 7/30/21 9:31 AM, Kerri Lemoie wrote:
>> Is a VC still considered to be valid if it contains fields that are not 
>> described in its context file(s)? Does it depend on the signature type?
> 
> The short answers are "maybe" and "yes".
> 
> The VC Data Model specification does not require values to be expressed in the
> `@context` because there was a contingent of people that didn't want to use
> JSON-LD in the original VC WG. So, an uneasy compromise was made that
> `@context` was required, but you didn't have to process the VC as JSON-LD.
> This allowed the people that just wanted to use JWTs with no JSON-LD
> processing to achieve their goals.
> 
> As you know, if a value doesn't exist in the `@context` and you do JSON-LD
> processing AND the `@context` doesn't declare a default vocabulary, the value
> is dropped and some JSON-LD signature libraries will complain loudly that the
> signature attempt failed because of an undefined term.
> 
> It's broadly viewed as a really bad idea to not define all terms in the
> `@context` -- it leads to all sorts of interop issues.
> 
> Some people have gotten around this (and I mean that in a negative way) by
> specifying a term where the value is of type `@json`, which means that JCS is
> used and you can shove whatever JSON you want to into that term. The downside
> there being that there are no semantics associated with the inside of that
> content. This is typically done in experiments (which is fine), when trying to
> encapsulate legacy JSON data (which is fine), or when trying to say you're
> technically JSON-LD and VC compliant while violating the spirit of what the
> spec was trying to do (which is not fine).
> 
> Much of this comes down to "Do you care about the semantics of what you are
> signing?" and "Do you care about interop between JSON and JSON-LD?".
> 
> But most importantly... if you're asking yourself the questions at the top of
> this email, you're probably already on the wrong path.
> 
> -- 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/
> 
>