Re: On JSON-LD with DIDs and VCs

Although remote context retrieval is bad practice it is part of the spec.

Oliver

On Mon, Jan 13, 2020 at 3:00 PM Oliver Terbu <oliver.terbu@consensys.net>
wrote:

> 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
>> >
>>
>>