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

Re: Understanding @contexts and credentialSchemas

From: Juan Caballero <juan@identity.foundation>
Date: Tue, 15 Jun 2021 13:26:29 +0200
To: Snorre Lothar von Gohren Edwin <snorre@diwala.io>, Kim Hamilton <kimdhamilton@gmail.com>
Cc: Kerri Lemoie <klemoie@concentricsky.com>, Orie Steele <orie@transmute.industries>, W3C Credentials CG <public-credentials@w3.org>
Message-ID: <b3db94d0-f4e1-ff85-4699-21f424c8f8ae@identity.foundation>
There most certainly is! Open to PR's when people want 
particularly-useful CCG threads or other resources to be findable.

https://identity.foundation/faq/#what-is-the-difference-between-a-json-ld-context-and-the-credentialschemas-property-whats-the-division-of-labor

https://github.com/decentralized-identity/faq/commit/7a045384023229bacda9ab348e4994d61f68df0a

On 6/15/2021 10:57 AM, Snorre Lothar von Gohren Edwin wrote:
> There is a DIF faq: https://identity.foundation/faq/ 
> <https://identity.foundation/faq/>
> ᐧ
>
> On Fri, Jun 11, 2021 at 8:17 PM Kim Hamilton <kimdhamilton@gmail.com 
> <mailto:kimdhamilton@gmail.com>> wrote:
>
>     FYI, Orie’s latest response should be elevated to a CCG FAQ entry,
>     if we had such a thing. Having this handy would save a lot of time
>     for folks (having seen this be a major point of confusion over
>     several years).
>
>     On Fri, Jun 11, 2021 at 11:03 AM Kerri Lemoie
>     <klemoie@concentricsky.com <mailto:klemoie@concentricsky.com>> wrote:
>
>         Thank you, Orie!
>
>
>>         On Jun 11, 2021, at 9:43 AM, Orie Steele
>>         <orie@transmute.industries
>>         <mailto: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 <http://www.transmute.industries>
>>
>>         <https://www.transmute.industries/>
>
>
>
> -- 
> *Snorre Lothar von Gohren Edwin
> *
> Co-Founder & CTO, Diwala
> +47 411 611 94
> www.diwala.io <http://www.diwala.io/>
-- 
------------------------------------------------------------------------

Juan Caballero, PhD.
Community & Communications, Decentralized Identity Foundation 
<https://identity.foundation>
Freelance <https://www.caballerojuan.com> researcher, consultant, and 
free thinker
Signal/whatsapp: +1 415-3101351
Berlin-based: +49 1573 5994525, CEST/UTC+2
Native: English, Español; Functional: Deutsch, Français, Português
Received on Tuesday, 15 June 2021 11:27:01 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 15 June 2021 11:27:24 UTC