Re: On JSON-LD with DIDs and VCs

My apologies for conflating VC and VP in my previous email. While I agree
that this separation exists, I don't see that this can mitigate the
described issue in all cases as the VP can still include the VC and the
potentially malicious context.

In that case, enforcing the validity checks at the verifier would cause
verifiers to fail if the issuer had malicious intent. If there is enough
pressure or incentive on verifiers to support these VCs, the system would
need a fallback to support plain JSON to preserve the user's privacy. Then,
the question is why should that not be the default case as it is also much
simpler?

Oliver

On Tue, Jan 7, 2020 at 10:21 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> I think one of the reasons why the community has agreed to think of a
> presentation and a credential as two different (though highly related)
> types of data is that making the distinction allows us to make different
> extensibility vs. security/privacy tradeoffs in credentials versus
> presentations, per circumstances. Extensibility of *credentials* need not
> trigger sacrifices in security/privacy of *presentations*, if we don't
> conflate the two. But as long as we conflate the two, we create unnecessary
> baggage in either direction.
>
> On Tue, Jan 7, 2020 at 2:01 PM Oliver Terbu <oliver.terbu@consensys.net>
> wrote:
>
>> See my comments below ...
>>
>> On Tue, Jan 7, 2020 at 8:08 PM Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> On 1/7/20 1:22 PM, Oliver Terbu wrote:
>>> > 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.
>>>
>>> JSON-only processors that don't have an extensibility mechanism will
>>> fail to enable diverse industries to create their own credential types
>>> and will fail in the market. What am I missing?
>>>
>>
>> That is not related to the issue. However, I don't see that necessarily
>> to happen without having JSON-LD but I recognized that this is a discussion
>> where we will likely not come to a shared conclusion (see the most recent
>> W3C DID WG discussion).
>>
>>
>>>
>>> This isn't purely a JSON vs. JSON-LD issue -- it's a more specific
>>> version of the phone home problem and there are mechanisms (as Orie
>>> deftly outlined in the previous email) that can prevent phone home if a
>>> URL is going to be used to retrieve external information as a part of
>>> the verification process. Note that the spec talks about this very
>>> attack:
>>>
>>> https://www.w3.org/TR/vc-data-model/#validity-checks
>>>
>>> There are also multiple solutions to this specific concern (among the
>>> ones that Orie has already mentioned), but the easiest ones at a higher
>>> level are:
>>>
>>> * Wallets should mark VCs as potentially being used to track them if the
>>>   JSON-LD Contexts are not well known.
>>>
>>> * Verifiers should reject VCs containing contexts that are not well
>>>   known and/or loaded from a cache.
>>>
>>
>> Companies that are large enough could exert enough pressure to dilute
>> these checks. Furthermore, many of these checks are prone to errors as the
>> complexity is quite considerable.
>>
>>
>>>
>>> ... and in the very worst case:
>>>
>>> * Industry launches a mix-net caching proxy for JSON-LD contexts if this
>>>   really becomes an issue.
>>>
>>>
>> I guess that could work :)
>>
>>
>>
>>> Does that answer your question, Oliver?
>>>
>>
>> Partially, yes.
>>
>> Note, that does not mean that we won't support processing of JSON-LD in
>> VCs.
>>
>> Still, I don't see any good reason why we should prioritise extensibility
>> over security and privacy at theses layers.
>>
>> Oliver
>>
>>
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny (skype: msporny, twitter: manusporny)
>>> Founder/CEO - Digital Bazaar, Inc.
>>> blog: Veres One Decentralized Identifier Blockchain Launches
>>> https://tinyurl.com/veres-one-launches
>>>
>>>