RE: 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))

Re: 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"? :)

Again, Manu, I feel your reply is trying to contort the discussion.  

It is perfectly OK to support JSON-LD as a separate technology/specification and also believe that JSON-LD doesn't need to figure so prominently in the VCDM V1 and VCDM V2 specifications.


-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com> 
Sent: Sunday, January 29, 2023 9:22 PM
To: public-credentials@w3.org
Subject: 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.

*lol*

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

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 - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/

Received on Monday, 30 January 2023 06:19:55 UTC