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

Ι 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://urldefense.us/v3/__https:/w3c-ccg.github.io/citizenship-vocab/__;!!BClRuOV5cvtbuNI!Te6WC0mssBfU3y2-E6vZVPp8nwrFzFh6D4yPWUljTq5owSbuMs_NyqfeD24CvW2sqG4H$> https://w3c-ccg.github.io/citizenship-vocab/ 
* W3C CCG Supply Chain Traceability Vocabulary -  <https://urldefense.us/v3/__https:/w3c-ccg.github.io/traceability-vocab/__;!!BClRuOV5cvtbuNI!Te6WC0mssBfU3y2-E6vZVPp8nwrFzFh6D4yPWUljTq5owSbuMs_NyqfeD24CvUxluxD2$> https://w3c-ccg.github.io/traceability-vocab/ 

 

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> https://github.com/w3c/vc-data-model/issues/953
[2]  <https://github.com/w3c/vc-data-model/pull/1001> 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

 

 <https://www.dhs.gov/science-and-technology>