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