David-Chadwick
commented
1 year ago But we already have what you require in the current VP-JWT spec that is independent of the embedded VC. This contains the VP issuer (holder/entitlee) and audience (issuer in your unfederated model - which (as an aside) I think is too restrictive). This is the proof metadata of my 4 layer model. So the RP can verify that the VP is intended for it, verify the signature, then go onto inspect the VC that is embedded in the VP to find out which privileges the VP holder is requesting.
SmithSamuelM
mwherman2000
TallTed
brentzundel
Sakurann
I have copied my comments from issue #947 because they got lost in the general discussion.
VD-LD and VCC
This a concrete proposal that IMHO resolves the primary conflict in the community. It has two features:
Discussion
Those who think that VCs are best implemented with a layered model where only the topmost layer may or may not be an open-world model as determined by the application use case can then go build a layered model. And in those cases where the topmost layer benefits from an open-world model based on RDF then those users of VCC can still have high interoperability with VC-LD. For those applications of VCC that do not benefit from an open-world model then the primary advantage of VC-LDs is of little benefit to them and they can then benefit from avoiding the complexity and drag of an open-world model.
Drag
Much of the drag (cognitive dissonance) that we as a community experience (IMHO) is a result of the improper layering of the security concerns associated with the V in VC, and not due to the non-interoperability of an open-world set of claims. The triples in the claims can be conveyed in every case by a container layer to which the claims are opaque. The claims layer may of course, reference any meta-data in the container layer, but operationally this can be viewed as logging the container as an artifact but operationally, all the container layer needs to achieve its function is limited to the closed world set of container properties (not its payload). These container properties look like meta-data to the claims layer or may include identifiers that are subjects of claims. But because the claims layer is opaque to the container layer, there are zero dependencies by the container layer on any claim in the claims layer so contained. Triples in the claims layer may be dependent on properties in the container layer but not vice-versa. To reiterate, this allows the container layer to be a closed world model of limited scope whereas the claims layer may still include any and all triples it so desires.
Protocol Design Flaw
The drag IMHO is due to mistaking the fact that the claims layer can reference properties in the container layer as a license to collapse or flatten the container layer leaving only the claims layer. This is indeed an unfortunate protocol design flaw that is the root cause of our difficulties.
This layering now allows us to limit the interoperability discussion to only those properties necessary to achieve the functionality of the container layer. Any discussion of an open-world model is obviously out of scope and would only add drag.
Such a layered model then allows the user to decide if the payload benefits from open-world interoperability or not. But the payload (including all its claims or triples) has already been authenticated. The container layer makes a cryptographic commitment to the payload. This usually means some serialization of the payload. Any serialization will do from the perspective of the authentication layer. The authenticity is limited to this serialization. Any later expansion that may dynamically introduce semantics may weaken what can be verified against the commitment to the original serialization. But what we have achieved is total interoperability of the authentication layer because it necessarily is a closed-world model. The payload is universally simply a serialized artifact such as a hash or Merkle root or accumulator of the payload regardless of the serialization type (be it JSON, JSON-LD, CBOR, MGPK, CESR or whatever).
Layered Model
Authentication Layer and Authorization Sub-layer
I propose that for a "verifiable" credential, what is primarily being verified is authorship or authenticity, where authenticity is defined to be secure attribution to a DID as issuer. A secondary verification for some credentials is an authorization where authorization is defined to be evidence of entitlement (the dictionary definition of credential). We then have a container that provides an authentication layer whose function to to provide verifiable proof of authenticity (aka secure attribution to a DID as issuer) of its opaque contents, and we have an optional authorization sub-layer that, when employed, provides proof of entitlement to some DID (or another verifiable cryptographic construct) as the target of the entitlement.
The opaque payload could be a true pure unadulterated JSON-LD document (or not, depending on the application use case). All claims in that payload would be authenticated before they are ever opened. Any properties needed to provide proof of authorization (entitlement) would necessarily be provided in the authorization sub-layer, but forensic information about the entitlee could be part of the payload because forensic information is not required to verify the entitlement but for other conditional purposes such as recourse or enforcement.
This layered approach IMHO removes most of the friction this community is experiencing. The security of the "verifiability" employs a closed-world model limited to the authentication and authorization layers, and the open-world interoperability is unfettered by concerns about what happens in the security layer below. Proofs of authenticity look sane because they are clearly poofs of the container of opaque claims and not some ex post facto proof mechanism of an expanded payload.
Presentation Layer
This layered model can be further extended to include the proof of presentation which is different from authentication of the Issuer and authorization by the Issuer.
A presentation exchange protocol then can include the details of graduated or selective disclosure of the payload claims when appropriate. In many cases the payload of forensic information need only be conditionally disclosed especially when the entitlement properties are cleanly separated. Then proof of the presenter as target of the entitlement is the primary function of the presentation proof.
But once again, any property of the presentation layer can be referenced in an open-world claims layer as a artifact or log of the proof but those references in the claims layer are not operationally involved as a dependency of the presentation layer. Once again, we avoid the mistake of wrongly collapsing the presentation layer into the claims (payload) layer merely because a property of the presentation layer may be referenced in the claims layer. We have the discipline to recall that a reference down into a lower layer does not give us a license to collapse that lower layer (the presentation layer in this case).