Re: DHS Verifier Confidence/Assurance Level Expectation/Treatment of non-publicly defined Vocabulary/Terminology -- by using @vocab

Several tools exist for that purpose:

-
https://v.jsld.org/2fkT9aJhvb6WdLmbVFqfGJuncAmN8uQHiAoLh6a3NsYpfcUaBiZ6NY36nVMfiaikKeHuXAL2y22nRGCWa5eKNEh7aGrQP6GNtjD1v1KvXkrDYgbw9wPpNSE5Sw49f3hU5p8AX43AuCjQUUkK8BXx8n8KGFmwXMjkLpzeCuEAST64jrd4okyULZNLcWuUGEygKXtdfVuLs1ENsXc39bh

-
https://w3c-ccg.github.io/traceability-vocab/#certificates-with-undefined-terms

OS


On Mon, Feb 6, 2023 at 3:44 PM Nikos Fotiou <fotiou@aueb.gr> wrote:

> Ι believe that developers should be educated that
>
>
>
> > the anticipated use of @vocab is that it allows for the use of
>  “private attributes”
>
>
>
> My recent experience with ETSI’s NGSI-LD (which is almost identical to
> JSON-LD) showed that (i) developers abuse @vocab either for convenience or
> because they do not know how to create a @context file, (ii) @vocab
> prevents developers for detecting errors in their JSON-LD files.
>
>
>
> I think it would be useful to have something like this but for JSON-LD VCs
>
>
>
> https://didlint.ownyourdata.eu/
>
>
>
> This tool will accept as input a JSON-LD formatted VC and will examine if
> all attributes are defined in the context files(s). JSON-LD playground can
> do that but its output is a bit “overloaded”.
>
>
>
> If somebody has already developed something like that, please share it in
> the list 😊
>
>
>
> Best,
>
> Nikos
>
>
>
>
>
>
>
> *From:* John, Anil <anil.john@hq.dhs.gov>
> *Sent:* Thursday, January 26, 2023 9:27 PM
> *To:* public-credentials@w3.org
> *Subject:* DHS Verifier Confidence/Assurance Level Expectation/Treatment
> of non-publicly defined Vocabulary/Terminology -- by using @vocab
>
>
>
> Hello Everyone,
>
>
>
> I wanted to share broadly some of the considerations that we are currently
> working through regarding data quality (as represented by incoming JSON-LD
> formatted VCs) and its impact on good decision making.
>
>
>
> As a refresher, the following is what the current version of our W3C
> VC/DID Implementation Profile notes:
>
>
>
> Verifiable Credentials and Verifiable Presentations, as defined in [VC
> DATA MODEL], SHALL be serialized as [JSON LD] in compacted document form
>
> ·         A Verifiable Credential SHALL define all terms using @context
>
> ·         A Verifiable Presentation SHALL define all terms using @context
>
> o   [JSON LD] SHALL define all types using @type
>
> o   [JSON LD] SHOULD leverage objects instead of strings to refer to
> Issuers and Holders
>
> o   *[JSON LD] MAY rely on @vocab to automatically define terminology*
>
>
>
> I wanted to focus on the last bit; while this does not apply to DHS
> (either CBP or USCIS) as issuers of credentials, given that we clearly and
> publicly define our vocabulary:
>
>    - W3C CCG Citizenship Vocabulary -
>       https://w3c-ccg.github.io/citizenship-vocab/
>       <https://urldefense.us/v3/__https:/w3c-ccg.github.io/citizenship-vocab/__;!!BClRuOV5cvtbuNI!Te6WC0mssBfU3y2-E6vZVPp8nwrFzFh6D4yPWUljTq5owSbuMs_NyqfeD24CvW2sqG4H$>
>       - W3C CCG Supply Chain Traceability Vocabulary -
>       https://w3c-ccg.github.io/traceability-vocab/
>       <https://urldefense.us/v3/__https:/w3c-ccg.github.io/traceability-vocab/__;!!BClRuOV5cvtbuNI!Te6WC0mssBfU3y2-E6vZVPp8nwrFzFh6D4yPWUljTq5owSbuMs_NyqfeD24CvUxluxD2$>
>
>
>
> However it does have a bearing on us when we consume
> credentials/attestations i.e. act as Verifiers.
>
>
>
> My understanding of the anticipated use of @vocab is that it allows for
> the use of  “private attributes” that are agreed upon by parties in some
> out-of-bound manner rather than being openly and publicly defined.
>
>
>
> To date, much of the conversations that we are tracking [1] [2] looks to
> be very much from the perspective of technologists and developers and not
> really from the perspective of an end customer like Us,  so we wanted to
> make sure that we shared our perspective to ensure that it is reflected and
> considered as folks make implementation choices on how they represent
> attributes in credentials/attestations.
>
>
>
> To that end, from the perspective of a VERIFIER (i.e. CBP or USCIS in
> consumption mode), this looks to be something that is clearly falls in the
> following bucket:
>
>
>
> “How much confidence do we have in this data that just came in the door,
> and what manner of out-of-band work do we need to do, or made a
> non-automated decision on, to  treat this data as equivalent to data
> vocabularies that is clearly and openly agreed upon” i.e.
> Confidence/Assurance Level we can place in the data.
>
>
>
> So, where we have landed on in our deliberation is that
> credentials/attestations that utilize vocabularies that are openly/clearly
> defined will be treated as having higher assurance/confidence level than
> data that is coming in via the @vocab route, which may require additional,
> out-of-band and in many cases non-automated processing by the Verifier to
> determine its validity and quality. (This will be something that we add to
> the Informative section of our Profile going forward)
>
>
>
> [1] https://github.com/w3c/vc-data-model/issues/953
> [2] https://github.com/w3c/vc-data-model/pull/1001
>
> Best Regards,
>
>
>
> Anil
>
>
>
> Anil John
>
> Technical Director, Silicon Valley Innovation Program
>
> Science and Technology Directorate
>
> US Department of Homeland Security
>
> Washington, DC, USA
>
>
>
> Email Response Time – 24 Hours
>
>
>
> [image: A picture containing graphical user interface Description
> automatically generated] <https://www.dhs.gov/science-and-technology>[image:
> /Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395]
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>