Re: On JSON-LD with DIDs and VCs

See my comments below...

On Tue, Jan 7, 2020 at 7:56 PM Orie Steele <orie@transmute.industries>
wrote:

> Thanks for raising this issue.
>
> 1. Why is embedding a context object (possible a very large one) better
> than using a hashlink?
>

It is just better from a security point of view by reducing the attack
vector. Additionally, it mitigates the risk of making the context
unavailable and hence the DID/VC useless. I do like the hashlink approach
better.


> 2. Assuming the use of a hashlink, why would anyone ever do anything but
> cache the contexts they use?
>

My point was that you cannot control how issuers specify the context. A
malicious issuer would not use hashlinks.


> 3. Assuming the use of cached contexts, does this security issue persist?
>

Caching can solve the issue. My point was that there is an issue with
preventing verifiers to do so based on the information they receive in the
DID/VC.


>
> 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.
>

I agree but this is again a verifier policy, prone to errors and does not
solve the problem of having big companies that are big enough to exploit
this behaviour.


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

I agree but you don't need many to cause damage. Additionally, one argument
for JSON-LD I often heard was the extensibility feature.


>
> 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.
>

I agree but this is again a verifier policy as described above.


>
> 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>
>