Re: On JSON-LD with DIDs and VCs

We are reviewing the lingering JSON-LD documentation issue
<https://github.com/w3c-ccg/community/issues/88> (specifically what's
needed to close it) during tomorrow's CCG call. If possible, I'd like to
touch on this as well.

Specifically, I'd like to ensure we're capturing concerns/guidance like
this for other implementors.

On Mon, Jan 13, 2020 at 12:23 PM John, Anil <anil.john@hq.dhs.gov> wrote:

> Manu >> If you are writing production grade software and security is a
> concern, don't let your software retrieve random documents from the
> Internet.
>
> …
>
> Oliver >> that just because something is best practice, so people will use
> it. We should have the mindset that everything that is allowed, can happen
>
>
>
> I agree with Oliver that if developers who are not steeped in the security
> nuances (or do not care even if they are aware) will always take the easy
> way out, whatever the “best practice”. So providing strongly worded
> guidance w/o corresponding enforcement ends up being nothing more than a
> feel-good dust in the wind pointer to how thoughtful the standards creators
> were.
>
>
>
> I came up in the world where we realized that standards in general are the
> result of compromise arrived at by people with different motivations and
> knowledge bases and as such what is more important is to come up with a
> ‘Profile’ of a standard where you constrain the options that are available
> within a standard to achieve particular goals whether that goal is
> security, privacy and/or interoperability.
>
>
>
> If this is such a clearly bad idea, what are the implications of
> constraining how JSON-LD can be utilized within the DID Core Spec and/or
> DID Resolution Spec to prevent/limit remote context retrieval rather than
> leaving it open ended with the end goal that any DID spec conformance test
> suite fails hard if that constraint is not in place?
>
>
>
> Best Regards,
>
>
>
> Anil
>
>
>
> Anil John
>
> Technical Director, Silicon Valley Innovation Program
>
> Science and Technology Directorate
>
> US Department of Homeland Security
>
> Washington, DC, USA
>
>
>
> Email Response Time – 24 Hours
>
>
>
> [image: https://www.dhs.gov/science-and-technology/svip]
>
>
>
>
>
> *From:* Oliver Terbu <oliver.terbu@consensys.net>
> *Sent:* Monday, January 13, 2020 9:00 AM
> *To:* David Chadwick <D.W.Chadwick@kent.ac.uk>
> *Cc:* W3C Credentials Community Group <public-credentials@w3.org>
> *Subject:* 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
> >
>
>