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

bikeshed begin

re 1: As far as I know, the kid issue was being discussed in the DID WG and
DIF, and we have proposed a solution for that but I must admit that during
the last few weeks my standards activities were pretty low due to a recent
change of my role.

re 2: Either participants of a system agree on how they are going to use
JWTs for this which probably happens in 99% of all cases. This assumes
issuers are aware of each other and agree to a certain spec. Or you have to
transform the JWT to the JSON-LD VC counterpart if the system is more open.

re 3: Nobody prevents you from transforming the JWT into JSON-LD if this is
required. The JSON-LD processor would then throw a warning or an error in
case the validation failed.

bikeshed end

I am happy to discuss a final solution for 1 in a separate thread because I
don't want to derail the original question/discussion.

Oliver

On Fri, Apr 3, 2020 at 5:38 PM Orie Steele <orie@transmute.industries>
wrote:

> I want to raise some concerns with the JWT Proof Format for VCs...
>
> 1. No Standard Way to Lookup Verification Keys
>
> Lack of clear binding between iss / kid and verificationMethod... in
> other words... how are keys used for JWTs meant to be expressed in the JWT
> Header... we've seen this continuously trip developers, who think that kid
> should either look like: "did:example:123#fingerprint" or "fingerprint"...
> but then software needs to know how to resolve the verification key
> material... this is not OAuth, we don't have
> https://YOUR_DOMAIN/.well-known/jwks.json... there is essentially no
> standard way of looking up the key used to sign a VC-JWT.
>
> 2. Many Equivalent Spec Compliant Representations
>
> there are many ways a VC JWT might have a proof applied, and they are not
> aligned with how the ld proof may look... this makes the proof formats
> essentially not interoperable, and given the optionality defined here: "For
> backward compatibility with JWT processors, the following JWT-registered
> claim names MUST be used instead of, or in addition to, their respective
> standard verifiable credential counterparts: [exp, iss, nbf, jti, sub,
> aud]"... there are lots of equivalent VC-JWT representations, verifiers are
> required to support all of them?
>
> 3. No Processing of JSON-LD
>
> As Oliver mentioned, there is no actual processing of the JSON-LD embedded
> in the JWT.... so it's trivial to issue and verify credentials which are
> not valid JSON-LD, just add properties that are not defined in the
> context... You won't get any warnings or errors, until someone actually
> tries to use the JSON-LD... which they are likely to do at some point,
> since they see an `@context`... In other words, the fact that there is no
> performance hit for VC-JWT context parsing indicates a security
> vulnerability... unless people believe it's a good thing that there is no
> validation of the VC JSON-LD... which seems crazy to me... why include an
> `@context`, if you don't intend to rely on it.
>
> That being said, if these issues were addressed, VC-JWT stands to the be
> an incredibly valuable part of the ecosystem, with some really
> significant benefits:
>
> A. Single Verification Key for Multiple Proof Formats
>
> Assuming a solution to 1, you could register a single JWK key, and use it
> for both LD and JWT VC Proofs.
>
> B. Most Widely Supported Tooling
>
> JOSE is by far the most widely supported web compatible crypto standard on
> the planet. Has built in support in browsers, including with software
> isolation for keys:
> https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle
>
> Support in almost every programming language.
>
> Used in almost all modern identity software (OAuth, OIDC)
>
> In conclusion, I personally would not recommend VC-JWT until the issues
> above are addressed... I really wish they were addressed because of the
> reasons above as well.
>
> I'm happy to help get these issues addressed, if that's possible to do.
>
> OS
>
>
>
>
> On Fri, Apr 3, 2020 at 5:08 AM Oliver Terbu <oliver.terbu@consensys.net>
> wrote:
>
>> 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>
>>>>> !
>>>>>
>>>>>
>>>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>