Re: On JSON-LD with DIDs and VCs

Adrian, hashlinks solve the issue partially because you cannot have
different URLs per the same context as the hash would change. Based on the
hash you could decide whether to load the content from cache or not without
having to go to the URL itself.

Oliver

On Wed, Jan 8, 2020 at 1:02 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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