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

Maybe I'm missing something but doesn't V1 of the spec allow for JWT -
(with a blank @context field) the super easy simple way to sign a whole
blob of data with no semantics other then the words in the name-value
pairs.
Isn't that "simple" ?
If this is not "obvious" to developers who want to do things "the easy way"
then maybe more documentation / pointers to this path could be created by
those in the community who care about it a lot.
- Kaliya

On Mon, Jan 30, 2023 at 3:10 AM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

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