Re: On JSON-LD with DIDs and VCs

I don't think the framing of the context URL is apt. 

Verifiers are NOT going to dynamically retrieve a context to see if they can somehow automatically make sense of it.

Rather, application developers are going to decide which contexts their application can support and code their systems based on that. As such, the contexts will only ever be resolved at development time. At verification time, the verifier simply checks to see if the contexts are ones they already understand. There simply is *no* programmatic way to handle an arbitrary context variation.

Instead, what contexts allow is for self-published standards for delineating otherwise conflicting namespaces. Those self-published "standards" allow rigorous understanding of the semantic intent of JSON properties without forcing the semantics to go through a formal standards process.

So the attack vector of an issuer using a unique context to force phoning home is a non-issue. Verifiers won't be resolving the URLs at verification. Developers however will be able to use contexts to accurately map the properties in the document to their own applications.

There *is* a reasonable argument that the whole point of standards is to standardize. I an appreciate an argument based on a notion of interoperability that desires every verifier to be able to parse every document and understand its relevant parts completely. That is, there should be no extensibility other than through iterating the standard.

However, if we want extensibility, we need issuers to be able to specify that their special extension is distinct from some other issuer's special extension. The verifier's application must already be programmed to handle those distinctions at verification time. JSON-LD was designed to solve this problem and even though I still have reservations about some of the ways it does that, I do believe it solves that problem.

If you don't by my argument that you should never resolve contexts at verification time, can you explain how a verifier application would handle an arbitrary context that assigns previously unknown semantics to unknown properties?

That task feels like an AI-complete task. To my knowledge, we still need human developers to interpret the semantics of a new context in terms of whatever their app does.

-j

On Tue, Jan 7, 2020, at 6:10 PM, Adrian Gropper 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
>>>>>> 

--
Joe Andrieu, PMP joe@legreq.com
LEGENDARY REQUIREMENTS +1(805)705-8651
Do what matters. http://legreq.com <http://www.legendaryrequirements.com/>