Re: On JSON-LD with DIDs and VCs

I want to make two meta observations.

1. A similar conversation about the value of extensibility has been
unfolding in relation to DID documents. There, I took a strong position
that JSON-LD-style extensibility is not a virtue. Here, I am not. Unlike
DID Docs, I think extensibility for VC schemas is desirable, and that
JSON-LD is a reasonable solution for it. The reason I am arriving at
different answers in different problem domains is that I think the two
domains have different profiles with respect to complexity, creativity, and
interaction patterns. (I'm not trying to argue for my conclusions
here--only pointing out that *assumptions about problem domain complexity,
creativity, and interaction patterns may explain why smart people with
aligned goals would make different tradeoffs*.)

2. Regarding security and privacy with VCs, I just want to enter my
alternate perspective into the record, without attempting to argue for it.
The perspective is this: *as long as the fundamental mechanism for binding
a holder to a cred is a disclosed DID that's a perfect correlator, no
amount of finessing around selective disclosure or JSON-LD @context
resolution/caching will achieve privacy*. This is why I haven't chimed in
to support Oliver's concern; though I think it's a fair point, I see other,
even more fundamental issues overwhelming its relevance. As I said, I'm not
trying to convince anyone of that position here; I just want it noted that
I (and maybe some others?) view Oliver's privacy concern through that lens.

On Wed, Jan 8, 2020 at 9:58 AM Oliver Terbu <oliver.terbu@consensys.net>
wrote:

> I guess I have to clarify a few things because apparently the whole AI
> thing was misunderstood. Find my comments below.
>
> On Wed, Jan 8, 2020 at 5:08 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 1/8/20 6:05 AM, Oliver Terbu wrote:
>> > On the other hand, I now understand that to solve the namespace
>> > problem people are happy to sacrifice security and privacy for
>> > extensibility.
>>
>> No, that's not what's being said at all. I don't think you understand
>> what people are saying in this thread.
>>
>> People are saying: We don't have to sacrifice anything -- you can get
>> security, privacy, AND extensibility with Verifiable Credentials as
>> designed.
>>
>
> I do think that having JSON-LD-enabled for verifiers has security and
> privacy implications as described in my previous emails. This security and
> privacy considerations could have been completely mitigated by not using
> JSON-LD. Note, I am NOT saying the VC spec is flawed. The spec allows
> verifiers to decide whether to make use of JSON-LD:
>
> "Though this specification requires that a @context property be present,
> it is not required that the value of the @context property be processed
> using JSON-LD. This is to support processing using plain JSON libraries,
> such as those that might be used when the verifiable credential is encoded
> as a JWT."
>
> However, my question then was, why should verifier use a JSON-LD library
> at all?
>
>
>>
>> > 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.
>>
>> Yes, but no one that knows what they're talking about has ever said
>> that JSON-LD is a magic bullet that will solve that problem. You seem to
>> be presenting a strawman argument.
>>
>> I also reject the notion that AI can solve this problem... let's not
>> even talk about that as an option. Every time someone alludes to "AI"
>> solving anything, I just replace "AI" with "magic". Please stop, AI is
>> magic. Generative Adversarial Neural Networks specifically tuned to a
>> particular problem space are not magic, and again, are not a silver
>> bullet. :)
>>
>> We don't need any of that magic for Verifiable Credentials to operate as
>> designed.
>>
>> You seem to be asserting that someone has stated that by using JSON-LD
>> that they'll be able to *safely* process Verifiable Credentials where
>> they don't understand the semantics of the credential. If someone has
>> stated that, they are completely and absolutely wrong. That is magic.
>>
>>
> Absolutely agree! Please let's don't talk about AI. I never said anything
> else, or it was just misinterpreted. :)
>
>
>> JSON-LD isn't magic that enables you to understand semantics that you
>> had previously not understood. Software always needs to be written to
>> understand the semantics -- for the next decade or more, by a human
>> being that understands the semantics. What JSON-LD gives us is the
>> ability to precisely identify semantic concepts in a decentralized
>> manner such that every market vertical on the planet isn't forced
>> through some slow W3C/IETF/OASIS standards setting process just so that
>> they can have the Verifiable Credential that their market vertical needs.
>>
>
> Yes, I do understand that. This is what I referred to as "extensibility"
> which I do see as a benefit but which I don't see as a legitimate reason to
> accept any tradeoffs on security and privacy. That is why I'm arguing for
> JSON-only verifiers.
>
>
>>
>> That is, JSON-LD gives us the ability for people to innovate at the
>> edges with the types of Verifiable Credentials that are produced and
>> consumed. JSON-LD *does not* give a computer the ability to magically
>> understand semantics that it isn't programmed to understand.
>>
>
> Fully agree and I have never said anything else.
>
>
>>
>> If you think the latter, you fundamentally misunderstand JSON-LD. If you
>> think the JSON-LD community is espousing the latter, you fundamentally
>> misunderstand the community's mental model.
>>
>> > 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.
>>
>> The Verifiable Credentials spec uses a restricted form of JSON-LD. The
>> discussion in this thread is about best practices and implementations.
>> If we find that we all agree on the best practice, then we can update
>> the spec to contain the limitations we're discussing right now. To put
>> it another way:
>>
>
> I would support that and introduce some normative requirements for JSON-LD
> verifiers for validation checks.
>
>
>>
>> C, Rust, Java, Python, Javascript, TLS, and JSON parsers all give you a
>> thousand ways to blow your foot off. That doesn't mean that those specs
>> are wrong -- they're flexible by design. What separates good programs
>> that use those technologies from bad ones is that the bad ones blow your
>> foot off when you don't expect them to, and the good ones protect all
>> your toes.
>
>
> JSON does not have these issues, it is a data interchange format and
> nothing else. JSON-LD on the other hand defines a lot of characteristics
> that are not needed. Amongst others, retrieving a remote context, is one of
> them and that is the reason why we are having this discussion.
>
>
>>
>> We have text that talks about this in the spec, namely:
>>
>> https://w3c.github.io/vc-data-model/#extensibility
>>
>> """
>> Though this specification requires that a @context property be present,
>> it is not required that the value of the @context property be processed
>> using JSON-LD. This is to support processing using plain JSON libraries,
>> such as those that might be used when the verifiable credential is
>> encoded as a JWT. All libraries or processors MUST ensure that the order
>> of the values in the @context property is what is expected for the
>> specific application. Libraries or processors that support JSON-LD can
>> process the @context property using full JSON-LD processing as expected.
>>
>
> I'm aware of this language in the spec and I'm quite ok with that. My
> point is that why should anyone do anything else as a verifier? Because
> ignoring JSON-LD as a verifier would result in a more interoperable, more
> secure and more efficient solution.
>
>
>>
>> ...
>>
>> A dynamic extensibility model such as this does increase the
>> implementation burden. Software written for such a system has to
>> determine whether verifiable credentials with extensions are acceptable
>> based on the risk profile of the application. Some applications might
>> accept only certain extensions while highly secure environments might
>> not accept any extensions. These decisions are up to the developers of
>> these applications and are specifically not the domain of this
>> specification.
>>
>> Developers are urged to ensure that extension JSON-LD contexts are
>> highly available. Implementations that cannot fetch a context will
>> produce an error. Strategies for ensuring that extension JSON-LD
>> contexts are always available include using content-addressed URLs for
>> contexts, bundling context documents with implementations, or enabling
>> aggressive caching of contexts.
>> """
>>
>> If that's not good enough, we can improve that text in the future once
>> the 2020 VCWG spins back up. We can add text to elaborate on this in the
>> implementation guidance.
>>
>
> Yes, I would support that.
>
>
>>
>> > 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.
>>
>> Simpler solutions, like?
>>
>
> I'm not against the context in general. For example, you could still use
> the information provided in the context for that. Note, I was
> concerned about JSON-LD verifiers and I was not worried about providing a
> valid context in the VC.
>
>
>>
>> -- 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
>>
>>