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

Oh, just to clarify. When David Chadwick said "I can assure you that
JSON-LD processing is not needed in order to implement a VC eco-system.
JSON processing is all that is needed, along with pre-configured @context
definitions" <-- that is absolutely correct.

You can work with Verifiable Credentials without doing any JSON-LD
processing whatsoever. (Or loading of @contexts, etc). It all depends on
the implementation / library.

It's just that with the vc-js library (the topic of this thread)
specifically, it does happen to do JSON-LD processing. And does need
resolvable contexts.


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

> 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>
>>> !
>>>
>>>