Layering/Composability of Verifiable Credentials (was: Re: Market Adoption of VCs by Fortune 500s (was: Re: DHS Verifier Confidence/Assurance Level Expectation/Treatment of non-publicly defined Vocabulary/Terminology -- by using @vocab))

On Sun, Jan 29, 2023 at 7:42 PM Michael Herman wrote:
> Your reply also missed my point.


I guess I'll join Kaliya and Kim, then, in failing to grasp what
you're getting at. At least I'm in good company.

I'll try one more time (below) and then wait for you to clearly
articulate something concrete that's actionable.

> I wasn't commenting negatively about JSON-LD as a standalone specification or its usage. In fact, in my opening remarks to Anil, I said something to the effect that I believe JSON-LD can be quite useful/valuable.

Interesting, I can't seem to find the text to which you are referring.
Can you provide a link, please?

To be clear, my response was not only about JSON-LD, but Verifiable
Credentials as well. The uptake cited was for BOTH technologies,
specifically as it relates to some of the Fortune 500 companies you
were asking about.

> The niche specification that I was referring to is the current VCDM specifications that are littered with JSON-LD/RDF notes, examples, and requirements.

So, you're asserting that the problem with the VCDM is that it is
littered with notes, examples, and requirements on a technology
(JSON-LD) that you note can be "quite useful/valuable"? :)

> ...making the current and draft VCDM specifications overly complicated, more difficult to implement, and more difficult to program against by software developers.
> I think we need a layered Internet Credential architecture reference model (ICredential-ARM) that is desired and used by the broadest range of software architects and developers possible - working for small, medium, and large organizations.

We already have a layered, composable architecture with Verifiable
Credentials today.

I know that there are a few people that keep insisting that we don't,
who (like you) are also proposing their own alternatives, but to
suggest that Verifiable Credentials are not a layered architecture
today is a misrepresentation of the technology. This is even more true
with the VC 2.0 data model, which now adds a default vocabulary in
order to quiet JSON-LD processor error reporting.

So now any JSON data structure that conforms to the Verifiable
Credential 2.0 data model is also a valid JSON-LD document (because
there is now a default vocabulary for undefined properties). Granted,
some organizations that find clear semantics useful find this
concerning. The concern is that some vendors will inevitably try to
get away with not defining clear semantics for their Verifiable
Credentials, but (by design) it's detectable when a vendor decides to
not define their semantics and applications consuming that data can
choose to throw an error, or mark the incoming data as less
dependable, or take the vendor aside and have a discussion with them
on whether or not undefined properties are something that is
acceptable in their ecosystem.

At the lowest layer, the data model layer (Layer 1), you don't have to
care about JSON-LD if you don't want to. You can choose to skip
defining any semantics, throw some JSON at the wall (that conforms to
the VC 2.0 data model) and it'll stick. This approach is designed to
try and get developers started quickly and avoid any JSON-LD tooling
headaches that were there in v1.0. So, at the data model layer, we
have JSON that has to follow some fairly simple rules that are defined
in the VC 2.0 specification.

At the next layer (Layer 2), developers can choose to define the
structure of their credential using JSON Schema, their semantics using
JSON-LD, or just use the defaults (no schema, undefined semantics),
and go up to the next layer, which is securing the data model.

When securing the data model (Layer 3), you have at least the
following options: VC Data Integrity (proposed in 2012), VC-JWT
(proposed in 2018), VC-JOSE (proposed in 2022), and VC-COSE (proposed
in 2022). Again, you have options at this layer and each option gives
you different capabilities and each has its own set of benefits and

Once you've secured the data model, you move on to protocol (Layer 4),
and that can be: CHAPI (proposed in 2017), DIDComm (proposed in 2019),
VC-API (proposed in 2019), OID4 (proposed in 2022).

So this concept that seems to be making the rounds lately, about VCs
not having a layered architecture, is just nonsense.

I do expect that some of this is due to the specifications needing to
be more clear about these layers, the tooling needing to do a better
job to make developers lives easier, and education initiatives needing
to improve and scale as more developers come into the ecosystem. On
each of those points, we're working on it, but clearly need more help
to make everything better at a faster rate than we're currently going.
All of the above is competing for time w/ customers, who have their
own needs that have to be fulfilled.

Hope that helps address your request for a "layered Internet
Credential architecture reference model"... though, I won't be
surprised if I've missed your point yet again. :)

-- manu

Manu Sporny -
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)

Received on Monday, 30 January 2023 03:22:33 UTC