Re: On JSON-LD with DIDs and VCs

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 <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 <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 <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 <mailto: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 <https://github.com/json-ld/json-ld.org/issues/213>
> “An attacker could poison the DNS to make http://purl.org/payswarm/v1 <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 <mailto: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