Re: On JSON-LD with DIDs and VCs

I don't understand how hashlinks mitigate the issuer's attack of creating a
new context for each subject.

Is this issue a cousin of revocation issues and should the privacy aspects
of both be addressed in a coherent manner?

Extensibility is critical, as Manu makes clear. Listening to today's
discussions on standardized educational credentials makes me ask: Where is
our best general discussion of extensibility and community-operated
registries?

Adrian

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

> That's an excellent question. I've been ignoring it because Sovrin-style
> presentations use JSON-LD only very modestly thus far--whereas we have
> every intention of using JSON-LD's extensibility heavily on the credential
> side. Perhaps I will catch up to your thinking eventually...
>
> On Tue, Jan 7, 2020 at 3:26 PM Oliver Terbu <oliver.terbu@consensys.net>
> wrote:
>
>> 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
>>>>>
>>>>>