Re: Performance question for JSON-LD with vc.js

Thinking about this further, I suspect there might be confusion about what
a @context _is_.

It's a space-saving mechanism. It's a way to have globally unique property
names (using URLs), but for space-saving reasons, to be able to specify
short names for those URLs. (I walk through this, sort of from first
principles, in the article Understanding Linked Data
<https://medium.com/@codenamedmitri/understanding-linked-data-91b31ba544ec>
).

A @context is always a key-value map. (Of short names to longer URLs.) Now,
_where_ that key-value map lives is up to you as a developer. It can live
_embedded_ in your JSON-LD object. Or it can live on some server somewhere,
and you reference it by a URL. Except that as a security precaution, the
vc-js library (and other similar libs) does not fetch it via HTTP
automatically, but makes the developer allow that operation explicitly.

So.. a @context _is_ a JSON object. That either lives locally, or on a
remote server. Saying that it must or must not be machine readable doesn't
make any sense - it's machine readable by definition, otherwise it's not a
context...





On Thu, Apr 2, 2020 at 6:07 PM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> > There is *NOTHING* in the JSON-LD specification, in the definition of
> context (https://json-ld.org/spec/latest/json-ld/#the-context) that
> mandates that the URI/IRI be (a) resolvable or (b) that any such resolution
> be machine readable.
>
> It might be worth bringing up that concern to the JSON-LD CG for the next
> version of the spec, over at https://github.com/w3c/json-ld-syntax/
>
> Further down, in that same section, the wording "In JSON-LD documents,
> contexts may also be specified inline. This has the advantage that
> documents can be processed even in the absence of a connection to the Web."
> is the part that points out that contexts need to be resolvable (and,
> again, in actual implementation it's recommended that they're stored
> locally, like npm packages, and not fetched over the web).
>
>
> On Thu, Apr 2, 2020 at 5:43 PM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
>> Thinking of a context that way, Dmitri, is not correct.
>>
>>
>>
>> There is **NOTHING** in the JSON-LD specification, in the definition of
>> context (https://json-ld.org/spec/latest/json-ld/#the-context) that
>> *mandates* that the URI/IRI be (a) resolvable or (b) that any such
>> resolution be machine readable.  Same is true with the VC spec (
>> https://www.w3.org/TR/vc-data-model/#contexts).
>>
>>
>>
>> I agree that it is recommended to do that (
>> https://www.w3.org/TR/vc-data-model/#contexts, paragraph 4, under
>> @context) – no question about it.  However, it is **not** a requirement
>> (MUST) and as such using a context in that way still produces a 100% valid
>> LD doc and VC.
>>
>>
>>
>> Standards are written with very clear language for a reason and they
>> should be implemented accordingly.
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *Dmitri Zagidulin <dzagidulin@gmail.com>
>> *Reply-To: *"dzagidulin@gmail.com" <dzagidulin@gmail.com>
>> *Date: *Thursday, April 2, 2020 at 1:00 PM
>> *To: *Leonard Rosenthol <lrosenth@adobe.com>, Credentials Community
>> Group <public-credentials@w3.org>
>> *Subject: *Re: Performance question for JSON-LD with vc.js
>>
>>
>>
>> Hi Leonard,
>>
>>
>>
>> So, you can think of a context as exactly functionally equivalent to an
>> NPM package (or Maven, or ruby Gem, or whatever).
>>
>> Which means that, by definition, is has to be machine readable (it's a
>> common source of confusion to confuse contexts and human-readable vocab
>> documentation -- think of the human-readable part as a README file for an
>> npm package).
>>
>> Does it have to be accessible - sure, but just like with NPM packages,
>> you have the control of /when/ it's accessible.
>>
>> You /could/, in theory, override your require() functions so that it
>> loads NPM packages from the web, in your code. But even with caching, that
>> would be a wildly impractical approach, full of performance and security
>> issues.
>>
>> Instead, what most developers do (and what we recommend to do with
>> contexts), is to fix them at /build time/. That is, version them, bundle
>> them locally with your code, and only allow your document loaders to
>> interface with those local versions.
>>
>>
>>
>> Does that make more sense?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 2, 2020 at 12:41 PM Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>>
>> Dmitri – that also forces all contexts to be (a) accessible and (b)
>> machine readable…neither of which a mandatory requirement of either JSON-LD
>> or VC itself.
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *Dmitri Zagidulin <dzagidulin@gmail.com>
>> *Reply-To: *"dzagidulin@gmail.com" <dzagidulin@gmail.com>
>> *Date: *Thursday, April 2, 2020 at 11:39 AM
>> *To: *Anil Lewis <anillewi@ca.ibm.com>, Credentials Community Group <
>> public-credentials@w3.org>
>> *Subject: *Re: Performance question for JSON-LD with vc.js
>> *Resent-From: *<public-credentials@w3.org>
>> *Resent-Date: *Thursday, April 2, 2020 at 11:38 AM
>>
>>
>>
>> Hi Anil,
>>
>>
>>
>> > When using vc.js, I have observed that if the pre-configured contexts
>> are not loaded, I am unable to even sign/verify the credential. I might
>> have to come up with our own processing code to circumvent this issue.
>>
>>
>>
>> For security reasons, the vc-js library /does not/ allow loading of
>> arbitrary contexts from the web. You have to explicitly allow-list them, by
>> providing a document loader function tailored to your usecase.
>>
>> Absolutely happy to walk you through this, please feel free to open an
>> issue on https://github.com/digitalbazaar/vc-js/issues
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalbazaar%2Fvc-js%2Fissues&data=02%7C01%7Clrosenth%40adobe.com%7Ca959982f4c084abc396e08d7d72760d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214436440165151&sdata=fDhYF5mSzspb%2Bp9681N%2BdDOoImIl3KTFD2FkmGqrrS8%3D&reserved=0>
>> !
>>
>>