Re: On JSON-LD with DIDs and VCs

@Kevin, the approach you mentioned is very similar to hashlinks. Hashlinks
don't address the problem in our context because they are not enforced. A
conformant verifier does not have to use hashlinks. A conformant verifier
that uses remote context retrieval could also except regular URIs.
Especially, in a true open world model where there is a clear separation
between verifiers, users and issuers. A legitimate verifier could be
tricked into that issue by a malicious issuer. I tried to explain why in
this case I see this as a vulnerability rather than a bad feature (see 2.)
on top or as an extension (see 3.) of the VC spec in my previous email.

@Joe, the threat model for DIDs is a bit different. I would at least
identify the following parties (although this is of course an
oversimplification):
- DID Subject (this can be broken down into application/ wallet developers,
etc.)
- DID Method specification authors
- DID Registrar (typically anchoring the DID Document on some ledger or
distributed file system)
- DID Resolver (local/remote)
- DID Document consumer

The above is not an exhaustive list and the number of distinct participants
and additional participants is up to the specific tool chain (+ DID method
spec). However, let's assume that at least the following is technically
possible (without assessing the risk potential).

If DID Doc consumers have "remote context retrieval" enabled for arbitrary
URIs, then this could lead to an exploit in AT LEAST the following cases ...
- The DID Registrar could register a DID Document with a malicious context
if the anchor system stores the whole JSON-LD DID Doc and the resolver
returns the latest version of the DID Doc as it is. In that case, only the
registrar needs to be malicious.
- The DID Resolver (local) returns a DID Document with a malicious context.
In that case, the resolver needs to be malicious. Adding integrity
protection to the DID Doc might help but cannot entirely mitigate that
attack as this type of check is not enforced and in some cases (depends on
the DID spec) it cannot be even enforced.
- ...

I can think of a few other cases but this would be too long to be discussed
here in this email as they require a different combination of malicious and
legitimate participants (se above) as well DID method specs. So, let's
focus on the two cases to understand my concern.

Note, I guess remote resolvers are special as the DID Doc consumer has to
have a strong trust relationship with the resolver anyways, because a
remote resolver could always phone home (if no mixnet or similar is used).

Please note, that this is not an exhaustive list of attacks. It would take
quite an effort to identify all vulnerabilities that are potentially(!)
enabled by just using JSON-LD. Additionally, I want to explicitly note,
that I'm not saying that there are no attacks possible on JSON-only DID
Docs. But it will have a different risk profile.

That is why I would argue for having a plain JSON DID core spec and having
separate specs for different encodings if we agree that certain security
and privacy tradeoffs must not be made. For instance, to mitigate some of
the risks one needs to define a JSON-LD profile and specifically introduce
conformance statements (that Orie, Manu and other people described here as
best practices and I do believe they can solve the issue).  Because this is
JSON-LD or more general encoding specific, this should be a different
document. I do believe that JSON-LD can be secure if the best practices are
implemented.

Another question that I have, do people believe that having a specific
encoding supported such as JSON-LD should be determined by the DID method
specification, by the resolver or by the registrar? I am in favor of having
the DID resolver to decide. Ideally, the DID method spec is agnostic to the
encoding. In that way, people could easily add support for encodings such
as CBOR for existing DID methods.

Thanks,
Oliver


On Fri, Jan 10, 2020 at 9:42 AM Ivan Herman <ivan@w3.org> wrote:

> There was a discussion in the JSON-LD Working Group on adding subresource
> integrity to context references, see issue #108[1]. The current standpoint
> was to postpone to later work, and get JSON-LD 1.1 out of the door (1.1 is
> in CR right now). The issue is kept open, although undecided if, and when,
> this will be picked up in future.
>
> Note that the usage of hashlinks (it was mentioned in the same thread
> already) may play a similar role.
>
> Ivan
>
> [1] https://github.com/w3c/json-ld-syntax/issues/108 (the issue is
> complex because SRI was part of a larger set of questions)
>
> On 10 Jan 2020, at 01:25, Kevin Poulsen <dean@authenticity.ac> wrote:
>
> re: the discussion below about remote @context in JSON-LD credentials
> posing a vulnerability:
>
>
> There’s a very simple solution to the @context vulnerability that Manu has
> spoken of where poisoned DNS can point to a different @context:
>
> Subresource Integrety —
> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
>
>
> A similar potential vulnerability exists when using remotely stored
> Javascript frameworks, as many web developers do.  If the DNS redirects to
> a modified version of that framework, malicious code can be run.  The
> original source could also be altered.  The solution is quite simple:
>  Include a hash of the intended resource.  If the hash doesn’t match, don’t
> utilize the remote resource.
>
> Here’s how it’s formatted in HTML/Javascript:
>
> <script src="https://example.com/example-framework.js"
>
> integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
>         crossorigin="anonymous”>
> </script>
>
>
> If you're worried about remote @context causing a problem with JSON-LD
> credentials, just include hashes for any remote @context and other remote
> resources.  Fixed.
>
> Linked Data capabilities are going to be important in the context of
> Verifiable Credentials, IMHO.
>
> Thanks,
> Kevin Poulsen
>
> p.s.  I’ve tried to get on the official list of participants.  But, I’m
> not affiliated with any sponsoring organizations.  I’m most interested in
> Solid and WebID.  If anyone can help me get involved, please tell me what I
> need to do.
>
>
>
>
> ———————
> On Wed, Jan 8, 2020 at 5:08 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> “I do think that having JSON-LD-enabled for verifiers has security and
> privacy implications as described in my previous emails."
>
> context:
>
> On 1/8/20 6:05 AM, Oliver Terbu wrote:
> > On the other hand, I now understand that to solve the namespace
> > problem people are happy to sacrifice security and privacy for
> > extensibility.
>
> No, that's not what's being said at all. I don't think you understand
> what people are saying in this thread.
>
> People are saying: We don't have to sacrifice anything -- you can get
> security, privacy, AND extensibility with Verifiable Credentials as
> designed.
>
> *I do think that having JSON-LD-enabled for verifiers has security and
> privacy implications as described in my previous emails.* This security
> and privacy considerations could have been completely mitigated by not
> using JSON-LD. Note, I am NOT saying the VC spec is flawed. The spec allows
> verifiers to decide whether to make use of JSON-LD:
>
> "Though this specification requires that a @context property be present,
> it is not required that the value of the @context property be processed
> using JSON-LD. This is to support processing using plain JSON libraries,
> such as those that might be used when the verifiable credential is encoded
> as a JWT."
>
> However, my question then was, why should verifier use a JSON-LD library
> at all?
>
> .
> .
> .
>
> JSON does not have these issues, it is a data interchange format and
> nothing else. JSON-LD on the other hand defines a lot of characteristics
> that are not needed. Amongst others, retrieving a remote context, is one of
> them and that is the reason why we are having this discussion.
>
>
>
> Some research:
> https://github.com/json-ld/json-ld.org/issues/213
> “An attacker could poison the DNS to make http://purl.org/payswarm/v1
> point to a document that switches source/destination.”
>
>
>
>
>
> On Wed, Jan 8, 2020 at 4:19 PM Joe Andrieu <joe@legreq.com> wrote:
>
> .
> .
> .
> However, an issue under consideration is whether or not JSON-LD is an
> appropriate mechanism for DID Documents or if JSON is sufficient. This is
> absolutely in scope for the current working group (and that part of this
> discussion should probably more to the DID WG).
>
> To that end, Oliver, is there a version of this concern that applies to
> how a DID Document's @context is an attack vector? I would be better able
> to respond to that concern if you could describe how that could happen.
> .
> .
> .
>
>
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: https://orcid.org/0000-0003-0782-2704
>
>