W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

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

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Thu, 2 Apr 2020 21:43:13 +0000
To: "dzagidulin@gmail.com" <dzagidulin@gmail.com>, Credentials Community Group <public-credentials@w3.org>
Message-ID: <D68FA1A7-74B9-4E5B-9C88-882E638849A5@adobe.com>
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.


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<mailto: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.


From: Dmitri Zagidulin <dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>>
Reply-To: "dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>" <dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>>
Date: Thursday, April 2, 2020 at 11:39 AM
To: Anil Lewis <anillewi@ca.ibm.com<mailto:anillewi@ca.ibm.com>>, Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Performance question for JSON-LD with vc.js
Resent-From: <public-credentials@w3.org<mailto: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>!
Received on Thursday, 2 April 2020 21:43:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC