RE: Saying yes to making @context optional

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>
Sent: Monday, November 28, 2022 9:31 AM
To: Nis Jespersen <nis.jespersen@gmail.com>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; public-credentials (public-credentials@w3.org) <public-credentials@w3.org>; steve capell <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