Re: On JSON-LD with DIDs and VCs

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