- From: Oliver Terbu <oliver.terbu@consensys.net>
- Date: Wed, 8 Jan 2020 12:05:43 +0100
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CALu3yZJuWBmFD_ebg+OwVBRnVDkaRwRTasmGVsr5fHQV92TnKA@mail.gmail.com>
I am very glad that Joe pointed that out that there is no AI that would allow applications to process any variation of credentials just because JSON-LD is used. This is exactly what I always said. However, the problem that I described is not about an arbitrary context, it is about the same context under a different URL, or having just an additional meaningless context that serves as a tracking cookie. The JSON-LD spec still allows the retrieval of references to a remote context. Note, the validation checks in the VC spec are non-normative, so technically malicious issuers are able to abuse that behaviour without producing invalid VCs. On the other hand, I now understand that to solve the namespace problem people are happy to sacrifice security and privacy for extensibility. If extensibility is the only feature that is needed and if people want to use the context at development time, then I personally don't see any good reason for verifiers to process JSON-LD as the attack vector and complexity will be increased and a fallback to JSON might have to be implemented to preserve the privacy of the user under some circumstances. If the only thing you need is to identify that a response is a certain object, then there are of course simpler solutions even based on the current W3C VC spec. Oliver On Wed, Jan 8, 2020 at 7:31 AM Dave Longley <dlongley@digitalbazaar.com> wrote: > > On 1/7/20 10:12 PM, Joe Andrieu wrote: > > 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. > > Well said, Joe. I think this is spot on and hopefully helps clarify some > of how this technology works and what the expectations are. > > > > > -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 <mailto: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 <mailto: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 > >> <mailto: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 > >> <mailto:oliver.terbu@consensys.net>> wrote: > >> > >> See my comments below ... > >> > >> On Tue, Jan 7, 2020 at 8:08 PM Manu Sporny > >> <msporny@digitalbazaar.com > >> <mailto: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 <mailto:joe@legreq.com> > > LEGENDARY REQUIREMENTS > > +1(805)705-8651 > > Do what matters. > > http://legreq.com < > http://www.legendaryrequirements.com> > > > > > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > >
Received on Wednesday, 8 January 2020 11:06:32 UTC