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: 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, here's is a copy&paste replay of the 4 times I’ve previously stated what the primary issue/concern is with the current and draft VCDM specifications ("my point" that no one has responded to so far).



Statement #1

Yes, there’s no doubt there is huge value represented by the use of JSON-LD (and RDF graphs) but is it necessary to have these as extensions/requirements in the basic Verifiable Credential data model specification? …why is it necessary to complicate a “data model” specification with JSON (and RDF) extensions?

Can JSON-LD (and RDF) be moved to a separate W3C “application” Note? …or put into a VCDM layer of their own? …for example: https://github.com/w3c/vc-data-model/issues/982#issuecomment-1405138086




Restatement #2

If the true primary goal was to drive wider, deeper, early adoption of VCs, the strategy should be to make the VCDM simpler and more compact; not more complicated, more niche, and less desirable to use.

The current direction is to make the VCDM more complicated and more niche and less desirable to use from the perspective of the silent majority of developers that Christopher is referencing.

...and indirectly what Sam Smith references here: https://github.com/w3c/vc-data-model/issues/982


...and myself here: https://github.com/w3c/vc-data-model/issues/1008#issuecomment-1407376853


...maybe DIF or ToIP is a better home for a better, layered VC specification: https://youtu.be/7LpVR0u18s0




Restatement #3

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.

...and not a niche specification that is unnecessarily complicated, difficult to implement, and difficult to program against.



Restatement #4

The niche specification that I was referring to is the current VCDM specifications that are littered with JSON-LD/RDF notes, examples, and requirements ...making the current and draft VCDM specifications overly complicated, more difficult to implement, and more difficult to program against by software developers.



Lastly, the following is an example of a Structured Credential …an example of an alternative structuring or shape of a VC for the color red (did:color:red). Manu, do you consider this a valid VC2CM credential?  …a text version of this VC is attached.



[cid:image001.jpg@01D93468.F83EAB00]



Michael Herman

Web 7.0



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