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

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

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Sat, 4 Apr 2020 11:40:05 +1300
To: Leonard Rosenthol <lrosenth@adobe.com>, Orie Steele <orie@transmute.industries>, Oliver Terbu <oliver.terbu@consensys.net>
Cc: Gregg Kellogg <gregg@greggkellogg.net>, Dmitri Zagidulin <dzagidulin@gmail.com>, Credentials Community Group <public-credentials@w3.org>
Message-ID: <5ef445c0-f045-cb25-45ce-df86f4242222@kent.ac.uk>
Hi All

WRT 1. below, I don't believe it is necessary to look up the JWT 
verification key. It is perfectly possible to carry the public key in 
the JWT header, which is what we do in our implementation.

This was discussed in the DID:KEY spec, see

https://github.com/w3c-ccg/did-method-key/issues/7

I have proposed the following,

did:key:<type>:< type specific encoding>

which we have currently implemented in our eco-system with

did:key:jwt:< base64 encoded type values specified in RFC 7517>

This seems to be pretty standards conforming, and the implementation 
guide can give example of how you encode up different public keys, RSA, 
ECA etc. for JWT

There seemed to be some support for this sort of approach.

However, As an aside

I am not sure what has happened to this spec, as it was agreed in a CCG 
meeting that I would be a co-editor of this spec, but that does not seem 
to have happened and the draft is currently being published by Manu as a 
digital bizarre spec. Manu could you update us please

many thanks

David

On 04/04/2020 05:24, Leonard Rosenthol wrote:
>
> Orie, no disagreement on some of those items (esp. #1).  To that end, 
> I have been working with ETSI (https://www.etsi.org/) on JAdES 
> (https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=52897) 
> which will significantly improve the limitations of JWT signatures in 
> general.
>
> Leonard
>
> *From: *Orie Steele <orie@transmute.industries>
> *Date: *Friday, April 3, 2020 at 11:38 AM
> *To: *Oliver Terbu <oliver.terbu@consensys.net>
> *Cc: *Gregg Kellogg <gregg@greggkellogg.net>, Dmitri Zagidulin 
> <dzagidulin@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, 
> Credentials Community Group <public-credentials@w3.org>
> *Subject: *Re: Performance question for JSON-LD with vc.js
>
> 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 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FCrypto%2Fsubtle&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909169444&sdata=KdJO1YZToxFOsHwgSQ1LgNxu5w9MfvKI%2BNZV%2F%2Bjl2jk%3D&reserved=0>
>
> 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 <mailto: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 <mailto: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
>         <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fvc-data-model%2F%23proof-formats&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909179441&sdata=yHH1jXT2Ma%2B98nhv1Qom683j776%2FDeHHNg0hD5rqC1M%3D&reserved=0>.
>         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
>         <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fuport-project%2Fdaf&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909179441&sdata=OQ17ybaOkBqWK4mwUwLfZ1ZgoQF2HsPCYCATmpgzVLU%3D&reserved=0>
>
>         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 <mailto:gregg@greggkellogg.net>> wrote:
>
>                 On Apr 2, 2020, at 3:07 PM, Dmitri Zagidulin
>                 <dzagidulin@gmail.com <mailto: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
>                 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjson-ld.org%2Fspec%2Flatest%2Fjson-ld%2F%23the-context&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909189434&sdata=w9nXBxcTyMjlsrQa3K3bOx3h7HxqRKP0oT0Lullg1QU%3D&reserved=0>)
>                 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
>             <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fjson-ld11%2F%23the-context&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909189434&sdata=V9wupDNcsA%2BrtSzLJ52neFnxg2eeeu0wmDAecQb1KCE%3D&reserved=0>,
>             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/
>                 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fjson-ld-syntax%2F&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909199431&sdata=%2BZ0edh%2BK%2BGSawxPym%2BHxN7tOaGlzrSOqET4GGWhcEwE%3D&reserved=0>
>
>                 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 <mailto: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
>                     <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjson-ld.org%2Fspec%2Flatest%2Fjson-ld%2F%23the-context&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909199431&sdata=o9z0MdUUmh5I7IkxtbrhbqxT0MY3toT6NreGpo%2BZ7Yc%3D&reserved=0>)
>                     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
>                     <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23contexts&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909209426&sdata=vxR82MzpoFhor0Wx%2BAiUPXOOqHrKGN4LfSmG%2FqaNE6s%3D&reserved=0>).
>
>
>                     I agree that it is recommended to do that
>                     (https://www.w3.org/TR/vc-data-model/#contexts
>                     <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23contexts&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909209426&sdata=vxR82MzpoFhor0Wx%2BAiUPXOOqHrKGN4LfSmG%2FqaNE6s%3D&reserved=0>,
>                     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
>                     <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 1:00 PM
>                     *To: *Leonard Rosenthol <lrosenth@adobe.com
>                     <mailto:lrosenth@adobe.com>>, Credentials
>                     Community Group <public-credentials@w3.org
>                     <mailto: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.
>
>                         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%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909219415&sdata=0c%2Fs6DvYNfGwrFpB9yk6T55uhrYLjjmlgVO3oOdAWRA%3D&reserved=0>!
>
>
> -- 
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
> Image removed by sender. 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=02%7C01%7Clrosenth%40adobe.com%7C856286f2b1a04163f03d08d7d7e502c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215250909219415&sdata=uYnkYggeM1u1F5zHG0fhU4QsJAZSuxn49unvF1O6XXQ%3D&reserved=0>
>
Received on Friday, 3 April 2020 22:40:32 UTC

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