RE: Saying yes to making @context optional

I just filed this VCWG issue about enabling CBOR representations of Verifiable Credentials.

https://github.com/w3c/vc-data-model/issues/985


                                                       -- Mike

From: Kim Hamilton <kimdhamilton@gmail.com>
Sent: Monday, November 28, 2022 5:29 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>; Christopher Allen <ChristopherA@lifewithalacrity.com>; Nis Jespersen <nis.jespersen@gmail.com>; dbuchner@tbd.email; public-credentials (public-credentials@w3.org) <public-credentials@w3.org>; steve capell <steve.capell@gmail.com>
Subject: Re: Saying yes to making @context optional

This topic is well-covered by everyone in this thread, and the VC mailing list, so here’s a brief 2 cents from the perspective of a (likely obtuse) implementer of LD and JWT signatures over the past 5 years.

1. We've said "we just need better LD tooling" for years but haven't made meaningful progress. My understanding/experience is that it's been difficult to get the right stakeholders to move this forward.

2. Even if we could sort out #1, IMO, strict dependence on LD from a base standard (VC) introduces risk and bottlenecks: need for tooling (per above), the significant amount of work needed to standardize everything implied by the LD stack, the security reviews and maturity required for production use...Essentially, is this introducing unnecessary barriers and risk to success of the VC standard?

3. Christopher's point about layer violation resonates strongly with me (and is probably a much more concise way to phrase my # 2)


On Mon, Nov 28, 2022 at 9:16 AM Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
I'm wondering if the dichotomy of positions wrt @context and "VC interoperability" strongly correlates with the differences between belonging to:
a) the identity wallet-based solutions camp (e.g. OpenID4VC), or
b) the DIDComm Agent with VC Attachments based software systems camp.

That is, those people focused on pure (or almost pure) identity wallet solutions vs. those building large systems based on decentralized identifiers, DIDComm agents, and DIDComm protocols.

Two cents Canadian (from the latter camp),
Michael

From: Christopher Allen <ChristopherA@lifewithalacrity.com<mailto:ChristopherA@lifewithalacrity.com>>
Sent: Monday, November 28, 2022 9:31 AM
To: Nis Jespersen <nis.jespersen@gmail.com<mailto:nis.jespersen@gmail.com>>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto:public-credentials@w3.org>>; steve capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>>
Subject: Re: Saying yes to making @context optional

I’m not against schema & vocabularies. But I believe they can be form of “layer violation” when they are used for cryptographic verification. Validation of a data set against a schema is a semantic & business process operation, not a cryptographic one. They should be separate.

If your business processes require distinction between two different variant predicates, the business process can require a context (though I
personally prefer labeled property graphs). But that validation  should happen separately from the cryptographic verification.

This “layer” separation between business process validation vs cryptographic verification is important for other reasons. With Envelopes the holder may not give you all the data, it may be elided (either through redaction or by inclusion of an encrypted object as a form of escrow, or refer to an external object by reference). Once that data is cryptographically verified, you still have to do the business process to determine that they give you sufficient information (non-elided) for your risk profile, or request more non-elided data to be sent.

This is essential for progressive trust. In progressive trust architectures you can’t assume that you can get everything you need to know in one data object. Trust is not cryptographic verification!

 If we are to serve privacy, mandates that cryptographic verification solves all problems with a single data object that results in a binary true/false answer will fail us. Business processes must validate against risk profiles. The results are more gray, not black & white.

Verification ≠ Validation ≠ Trust

— Christopher Allen