Re: On JSON-LD with DIDs and VCs

This is an excellent discussion, but I still am hoping for answers to my
questions immediately below.

Somewhat tangentially, I appreciate the AI argument around custom contexts
and imagine that many issuers with sufficient market power will simply
self-publish a context they support and expect verifiers to “deal” with or
without AI. This is not a security or privacy issue. I’m not sure if it's a
-LD issue either.

Adrian

On Tue, Jan 7, 2020 at 9:10 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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