Re: On JSON-LD with DIDs and VCs

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

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.

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.

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:

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.

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.

...

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.

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

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

Received on Wednesday, 8 January 2020 16:06:02 UTC