- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Wed, 8 Jan 2020 10:58:49 +0000
- To: public-credentials@w3.org
On 08/01/2020 03:12, 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. Spot on. This is exactly what our implementation does. We will not only check that we know all the @context values, but also that all the short form aliases are correct and that no extra ones have been inserted into a vc or vp. (we dont mind if some are missing) David > > 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 <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> > >
Received on Wednesday, 8 January 2020 10:58:57 UTC