Re: On JSON-LD with DIDs and VCs

Thanks for raising this issue.

1. Why is embedding a context object (possible a very large one) better
than using a hashlink?
2. Assuming the use of a hashlink, why would anyone ever do anything but
cache the contexts they use?
3. Assuming the use of cached contexts, does this security issue persist?

The attack of issuing a VC with a custom tracker context in it is
detectable, and while the processing of the context is observable if the
documentLoader is allowed to make arbitrary network requests, a secure
processing mode that only relied on cached content addressed contexts would
not leak processing information.

When testing JSON-LD I often disable network resolution of contexts to make
sure that I know every context that is used for verifying a graph signature.

It's a best practice to minimize the number of contexts associated with a
VC, and...

It's a best practice to minimize network requests, because making them
slows down the verifying process.

In the context of credential issuance and verification these network
resolutions are detectable, but as you point out, an evil corporation or
government could still craft credentials that when processed in an unsafe
manner would leak information.

This is a major reason why I believe we should assert that DID Documents
and VCs must be processed in strict mode.

See:
https://github.com/digitalbazaar/jsonld-signatures/blob/59372054de4c0f8a74704a0f27f7eddd3d3727e4/lib/documentLoader.js#L51

OS

ᐧ

On Tue, Jan 7, 2020 at 12:23 PM Oliver Terbu <oliver.terbu@consensys.net>
wrote:

> I see your points and the blog article is much appreciated. However, I
> feel I have to raise one of my concerns as a counterstatement.
>
> We recently had a conversation about a privacy concern with JSON-LD and I
> have not received a satisfying answer yet. So, for those who are members of
> DIF, this text might look familiar, so please apologize for seeing this
> twice.
>
> One of the reasons why I am so excited about SSI is that the interaction
> between a verifier and an end user CAN happen privately between them, i.e.,
> no third party has to be necessarily involved and tracking CAN be
> mitigated. So, imagine a malicious government issues VCs to their citizens
> that contain a custom context. That context points to a URL at some
> government backend and that URL is COMPLETELY different for each user,
> i.e., contains their SSN or any other identifier which the gov can use to
> uniquely identify the user. The content of the context itself can be the
> same for each user. Because verifiers see a completely different URL for
> each user, they won't be able to cache the context. That means, each time
> the user shares their VC with a verifier, the verifier will establish a
> connection with the gov which allows the gov to track where a SPECIFIC user
> (identified by the unique URL) uses the credential.
>
> There are technical and political solutions such as hashlinks and trust
> frameworks for this. Probably, the best option is an inline context
> although I can see issues with the increased size of VCs. Unfortunately,
> nobody can force anyone to apply these measures. If the government or
> company is big enough, e.g., "we all know some good examples", verifiers
> would accept credentials of these entities anyways. On the other hand, if
> the verifier is big enough, e.g., a big web shop, then users will share
> their data regardless. The average user does not understand security and
> privacy in the same as we do. We are talking about security critical
> protocols and having JSON-LD expands the attack vector unnecessarily.
>
> Note, that JSON-only processors won't have that issue and you can replace
> "government" with any type of issuers that have an interest in the online
> behavior of the user.
>
> No bikeshedding, I just want to have an answer to address my concern
> because I see that as an issue.
>
> Thanks,
> Oliver
>
> On Tue, Jan 7, 2020 at 6:47 PM Orie Steele <orie@transmute.industries>
> wrote:
>
>> We wrote this blog post on JSON-LD in the context of VCs and DIDs:
>>
>>
>> https://medium.com/transmute-techtalk/on-json-ld-and-the-semantics-of-identity-42d051d3ce14
>>
>> Its meant to explain some of the historical context behind JSON-LD, and
>> some of the integration benefits for choosing it.
>>
>> It's a technology we at Transmute use and love, but which we know is
>> challenging and not always a welcome dependency for everyone.
>>
>> Our hope is that if you don't know anything about JSON-LD, this blog post
>> might help provide some context.
>>
>> Regards,
>>
>> OS
>>
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>> ᐧ
>>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>