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