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

It might be probably worth pointing out that a non-JSON-LD and non-LD-Proof
version of Verifiable Credentials is the JWT proof format:
https://w3c.github.io/vc-data-model/#proof-formats. It is kind of hidden in
the W3C VC standard. For JWT VCs, you don't need JSON-LD processing. The
only thing that is needed as per W3C VC spec is to add the correct @context
values in the VC.

An implementation can be found here: https://github.com/uport-project/daf

On a separate note, we were recently debating about the security
implications of remote context fetching in W3C CCG and that it is
considered to be practice but had to admit that there is nothing
*normative* in the JSON-LD spec and W3C VC spec that prevents people from
doing that.

Oliver

On Fri, Apr 3, 2020 at 2:05 AM Gregg Kellogg <gregg@greggkellogg.net> wrote:

> On Apr 2, 2020, at 3: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.
>
>
> The proper reference is to https://www.w3.org/TR/json-ld11/#the-context,
> not the CG draft. It is at Candidate Recommendation on the way to Proposed
> Recommendation soon. Also, that section is not normative.
>
> In any case, there is no normative requirement that contexts be
> dereferencable; in many cases, this is an anti-pattern, and for the case of
> VC (IIRC) it is intended to act as an identifier that a conformant
> application running in JSON-LD mode, would use to provide the context that
> might otherwise be dereferenced from that location, possibly using a custom
> document loader.
>
> This is the case for other specs as well, where there is either the
> inability to dereference remote contexts at runtime, or a desire to avoid
> such traffic for other reasons.
>
> 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).
>
>
> An inline context would be an object value for @context within the main
> document. Generally, when there may be a large external context, or the
> content is closely managed, using the reference as an identifier which is
> resolved by a custom document loader is probably the best way to go. This
> also allows a document loader to notice attempts to access other external
> contexts, which could be specified in a document, and either whitelist or
> blacklist depending on your needs.
>
> Gregg
>
> 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>
>> !
>>
>>
>