Re: On JSON-LD with DIDs and VCs

I cannot get my head around this. If remote context retrieval is part of
the JSON-LD spec and this is used in the course of JSON-LD validation, then
this is in scope of the DID Core Data Model spec. Would you agree?

If people don't believe this belongs into the DID Core spec, then I would
argue it should be at least in the DID Resolution spec and we should make
it normative there.

Oliver

On Sun, Jan 12, 2020 at 10:49 PM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> +1 to adding statemens to the Implementation Guidelines to prevent
> remote retrieval. I dont think they can be added to the data model
> standard since protocol is out of its scope
>
> David
>
> On 12/01/2020 20:45, Oliver Terbu wrote:
> > On Sat, Jan 11, 2020 at 9:29 PM Manu Sporny <msporny@digitalbazaar.com
> > <mailto:msporny@digitalbazaar.com>> wrote:
> >
> >     On 1/10/20 7:58 AM, Oliver Terbu wrote:
> >     > If DID Doc consumers have "remote context retrieval" enabled for
> >     > arbitrary URIs
> >
> >     Don't do this in production... ever. :)
> >
> >
> > That is great, then we should add a normative statement to the spec
> > such as "JSON-LD processors MUST not use remote context retrieval" and
> > I will be happy. Because this is JSON-LD specific, this should be
> > added to a separate document.
> >
> >
> >     The attack you are concerned about is completely mitigated by not
> >     allowing software to arbitrarily download and execute code from the
> >     Internet.
> >
> >     This is a general security practice in any software system.
> >
> >     If you are writing production grade software and security is a
> >     concern,
> >     don't let your software retrieve random documents from the Internet.
> >
> >     With respect to the attack you outlined, there is zero difference
> >     between *properly implemented* JSON processors vs. JSON-LD
> processors.
> >
> >
> > The JSON-LD spec allows "remote context retrieval". The JSON spec has
> > nothing like that. Because that is a feature of JSON-LD that is not
> > needed and not desired, we should explicitly discourage this feature
> > by introducing normative language. People were talking about other
> > JSON-LD best practices such as strict mode etc. to be considered as a
> > *proper* implementation. Let's make that normative as well.
> >
> > My point is that I'm not happy with the answer that just because
> > something is best practice, so people will use it. We should have the
> > mindset that everything that is allowed, can happen. If 0.01% of
> > JSON-LD implementations are doing that wrong, then this is already
> > 0.01% too much that could have been prevented easily by mandating
> > certain things and defining a normative JSON-LD profile for DIDs.
> >
> >
> >     > Please note, that this is not an exhaustive list of attacks. It
> >     > would take quite an effort to identify all vulnerabilities that are
> >     > potentially(!) enabled by just using JSON-LD.
> >
> >     You have, to date, identified zero successful attacks for properly
> >     implemented systems using JSON-LD.
> >
> >
> > I always said that the described attacks target implementations that
> > don't follow these best practices. Let's add a normative statement to
> > the spec to resolve that issue. This will allow the industry to come
> > up with certification programs in the future.
> >
> >
> >     > Additionally, I want to explicitly note, that I'm not saying that
> >     > there are no attacks possible on JSON-only DID Docs. But it will
> >     have
> >     > a different risk profile.
> >
> >     You have yet to produce a single attack model that differentiates a
> >     proper JSON implementation from a proper JSON-LD implementation.
> >
> >     ... but this is fun, keep going. :)
> >
> >     We should be critical of these systems and try different attack
> models
> >     to see if there are vulnerabilities.
> >
> >
> > Yep, that is fun :) . I agree, we should think more about attack
> > models. I didn't have much time since my last email. Let's talk at the
> > W3C DID WG meeting how to proceed with this work. It would be great to
> > start some sort of catalogue. We did some work in this area already
> > but the docs cannot be shared.
> >
> >
> >     -- 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
> >
>
>