Re: Understanding @contexts and credentialSchemas

Thank you, Orie!


> On Jun 11, 2021, at 9:43 AM, Orie Steele <orie@transmute.industries> wrote:
> 
> a context describes semantics, a schema describes data shape... There is a right tool for each job, but sometimes you need both.
> 
> `@context` can only help you define JSON-LD semantics.
> 
> `credentialSchema` is much more flexible and can help you define JSON Schema, SHACL, CustomProprietarySchema, or any other schema technology you want to use.
> 
> I would not recommend using `@context` for schemas related to data shape or `credentialSchema` for semantics... but JSON-LD is a lot of rope and it does let you define some data-shape like behaviors.... My experience with it is that there is always a better solution than using JSON-LD "data shape" features like @container... 
> 
> A concrete example, "@type": "@json" <- this is JSON-LD for the JSON Schema  "type": "oneOf <number, null, object, string, array, etc...>
> 
> This can be very useful when your JSON data has no well defined semantics, or where its semantics are rapidly changing, or externally owned... 
> 
> For example: https://spec.smarthealth.cards/credential-modeling/ <https://spec.smarthealth.cards/credential-modeling/>
> 
> "@context": [
>   "https://www.w3.org/2018/credentials/v1 <https://www.w3.org/2018/credentials/v1>",
>   {
>     "@vocab": "https://smarthealth.cards# <https://smarthealth.cards/#>",
>     "fhirBundle": {
>       "@id": "https://smarthealth.cards#fhirBundle <https://smarthealth.cards/#fhirBundle>",
>       "@type": "@json"
>     }
>   }
> ]
> 
> In this case, all we know about "fhirBundle" is that it's JSON... this documentation is incomplete... because what version of FHIR is it?
> 
> fhirVersion needs to be defined, and used to answer that, but together they can allow you to "define only the semantics you need"... in this case, FHIR.
> 
> It's worth noting that there are lots of valid FHIR I could put in "fhirBundle" that could cause explosions... that's where a schema language like JSON Schema would be valuable.
> 
> Working together, they could help both producers and consumers agree to be as specific as is helpful for the VC type, and not "overly pedantic / specific" in ways that are beyond the point of diminishing returns.
> 
> One version of being as specific as is necessary is to say: "this payload is json"... I personally think that is harmful laziness, but you could also see it as a reflection of a lack of certainty regarding what is actually getting signed... and a need to allow anything... regardless of what it is... to be signed.
> 
> When answering the question of "what am I signing or verifying" JSON-LD and JSON Schema (for example) give you different additional confidence... Omitting both is the equivalent of saying you are either highly unconfident in the content you are or will be signing in the future, or you feel that the security benefits of typing and input validation are not relevant to your credential... I would call credentials that lack semantic disambiguation and schema / data shape fundamentally LESS SECURE.
> 
> Consider:
> 
> https://owasp.org/www-project-top-ten/ <https://owasp.org/www-project-top-ten/>
> 
> Of the top 10, the following are mitigated with stricter semantics and data shape constraints:
> 
> - Injection
> - Sensitive Data Exposure
> - Insecure Deserialization
> 
> A credential that lacks semantics and datashape is like a food product with no labeling or a mobile phone built with parts that might have been developed with poor labor practices... the point is that you don't really know, because the issuer chose not to meet those bars, when they decided to sign.
> 
> OS
> 
> 
> 
> 
> 
> On Thu, Jun 10, 2021 at 2:28 PM Kerri Lemoie <klemoie@concentricsky.com <mailto:klemoie@concentricsky.com>> wrote:
> This is helpful, Orie.
> 
> While VC has this credentialSchema property, I assume it would still be acceptable for a context to reference schema(s) directly?
> 
> Thanks!
> 
> K
> 
> 
> 
> 
>> On Jun 10, 2021, at 10:09 AM, Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries>> wrote:
>> 
>> This won't be a complete answer, but at the time of publication I believe that field was used in 2 ways.
>> 
>> 1. with json schema, see this for example - https://w3c-ccg.github.io/vc-json-schemas/ <https://w3c-ccg.github.io/vc-json-schemas/> 
>> 2. with hyperledger indy zkp-cl signature vc's
>> 
>> In both cases, "credentialSchemas" was more about the VC data shape and type, whereas contexts and JSON-LD are best used only for semantics.
>> 
>> There are other tools like SHACL that can help do linked data shape constraints, perhaps someone might use them with credentialSchemas in the future.
>> 
>> but AFAIK, "credentialSchemas" is focused on the credential data shape. and "@context" is focused on the semantics and term definitions used in the credential.
>> 
>> OS
>> 
>> On Wed, Jun 9, 2021 at 5:15 PM Kerri Lemoie <klemoie@concentricsky.com <mailto:klemoie@concentricsky.com>> wrote:
>> Hello all,
>> 
>> I’m reviewing this: https://www.w3.org/TR/vc-data-model/#data-schemas <https://www.w3.org/TR/vc-data-model/#data-schemas>
>> 
>> Could folks please explain to me the uses of credentialSchemas in comparison to @context files in JSON-LD? Is it that @context files name the attributes and credentialSchemas provide the information about how to validate the data/semantics? 
>> 
>> Can you provide some real-world examples? Bonus points for human centered examples such as identity,  education, &  workforce. :) 
>> 
>> Thanks!
>> 
>> Kerri
>> 
>> 
>> 
>> --------
>> Kerri Lemoie, PhD
>> Director, Digital Credentials Research & Innovation
>> badgr.com <https://info.badgr.com/> | concentricsky.com <https://concentricsky.com/>
>> she/her/hers
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> ORIE STEELE
>> Chief Technical Officer
>> www.transmute.industries <http://www.transmute.industries/>
>> 
>>  <https://www.transmute.industries/>
> 
> 
> 
> -- 
> ORIE STEELE
> Chief Technical Officer
> www.transmute.industries
> 
>  <https://www.transmute.industries/>