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

I have to correct a typo. It is certainly considered to be BAD practice.

Oliver

On Fri, Apr 3, 2020 at 12:03 PM Oliver Terbu <oliver.terbu@consensys.net>
wrote:

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