Open KendallWeihe opened 6 months ago
v2.0 will be more straightforward -- there is no mapping needed. the semantics of each layer are preserved. https://w3c.github.io/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose
there is guidance that you should not conflict...like
Implementers SHOULD avoid setting JWT claims to values that conflict with the values of verifiable credential properties when a claim and property pair refer to the same conceptual entity, especially with pairs such as iss and issuer, jti and id, and sub and credentialSubject.id. For example, JWK claim iss should not be set to a value which conflicts with the value of verifiable credential property issuer.
1.1 follows unfortunate mapping rules defined here https://www.w3.org/TR/vc-data-model/#jwt-encoding
this gives us optionality to include or delete properties that overlap between the layers (e.g. issuer/iss or id/jti) and so far we've chosen to remove them from the VC during JWT encoding and rely on the JWT values.
Originally spurred during the work on #150. We currently have
crates/credentials/src/vc.rs
and that implement VC Data Model 1.1, but we should consider how VC Data Model 2.0 will fit into our code. Furthermore, are the JWT implementations for each distinct or is there overlap?