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

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

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Thu, 2 Apr 2020 10:12:45 -0700
Message-Id: <1E994445-1F02-4D1C-9379-EF7B36E77CC4@greggkellogg.net>
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Credentials Community Group <public-credentials@w3.org>
To: dzagidulin@gmail.com
> On Apr 2, 2020, at 10:00 AM, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:
> 
> 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.

Speaking of Ruby Gems, the json-ld-preloaded gem [1] includes pre-compiled versions of several popular contexts, including Verifiable Claims. By including that gem, the Ruby JSON-LD gem will use any cached contexts found before attempting to load them; you could/should use a custom document loader to reject attempts to load external contexts in any case.

A pre-loaded cache of such contexts is really a good idea in any case, particularly with the wide use of schema.org <http://schema.org/>, to prevent hitting servers unnecessarily. It could also be done with a custom document loader to cache the JSON-LD documents, but this has the added benefit of reducing context parsing and processing time.

Gregg

[1] https://github.com/ruby-rdf/json-ld-preloaded <https://github.com/ruby-rdf/json-ld-preloaded>

> 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. 
> 
>  
> 
> Leonard
> 
>  
> 
> 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%7C56767c2b6869424a7ebf08d7d71c07b3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214387714608325&sdata=IZ610%2FFVghWmn%2BhhVDiygL9jkBnzsC%2BSS%2FxUQHXh5wc%3D&reserved=0>!
> 


Received on Thursday, 2 April 2020 17:13:02 UTC

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