Open arnoweiss opened 2 months ago
Look into providing profiles for JWT-based and LD proofs. Goal is to be agnostic as possible.
Discussion: focus on VC Data Model 1.1, but discuss 2.0
Interop profile will define a data model, proof type, and potential proof validation
As per our discussion in the DCP call, I think it would make sense to make sure that the exchange protocol (DCP) is agnostic of credential format and proof type.
When we integrate the DIF PEX support, the presentation definition can contain the expected credential format and proof type. Until then, one way the verifier can ask for specific credential format and proof type via scope definition.
An interoperability profile would allow a stricter definition of what is allowed (VC Data Model 1.1, JWS-2020 etc.).
What's missing?
Currently, the spec is agnostic to whether the transported VPs and VCs have enveloping or embedded proofs.
Why should it be in the spec?
I'm not sure that it's necessary - the protocol should probably function with either. I'd still like to see a decision on this.
Where should this be added?
A restriction would have effects on the schemas as well as the spec itself as it deals with both VPs and VCs.
More context
No response