search

eclipse-dataspace-dcp / decentralized-claims-protocol

Apache License 2.0
7 stars 13 forks source link

Decision on proof-types #68

Open arnoweiss opened 2 months ago

arnoweiss commented 2 months ago

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

jimmarino commented 2 weeks ago

Look into providing profiles for JWT-based and LD proofs. Goal is to be agnostic as possible.

jimmarino commented 4 days ago

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

hkny commented 4 days ago

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.).