w3c / vc-data-model-2.0-test-suite

W3C Verifiable Credentials v2.0 test suite
https://w3c.github.io/vc-data-model-2.0-test-suite/
Other
12 stars 15 forks source link

Add readme section about the `EnvelopingProof` tag usage. #128

Closed PatStLouis closed 1 month ago

PatStLouis commented 1 month ago

This is to partially address the concerns raised in #127.

It's not a requirement to use data integrity to be conformant with this test suite. This test suite doesn't test the securing mechanism, only the data model.

BigBlueHat commented 1 month ago

approving, but do remember the issuer.id becomes issuer in the actual VC which is relevant as an issuer should not being issuing a VC from another issuer.

@PatStLouis @decentralgabe any thoughts on what you'd expect to see set as issuer.id in an enveloping proof scenario? We typically recommend/support did:key or HTTP URL values there for the test suites. Thoughts?

aljones15 commented 1 month ago

approving, but do remember the issuer.id becomes issuer in the actual VC which is relevant as an issuer should not being issuing a VC from another issuer.

@PatStLouis @decentralgabe any thoughts on what you'd expect to see set as issuer.id in an enveloping proof scenario? We typically recommend/support did:key or HTTP URL values there for the test suites. Thoughts?

I believe kid is the issuer: https://w3c.github.io/vc-jose-cose/#jwt-issuer

it should be a did:key for the sake of simplicity and being in line with this test suite. Not sure how you can get around the alg though which even in the spec is set to eddsa.

decentralgabe commented 1 month ago

the semantic layer and securing layer are distinct. the issuer property will still be present after you decode the vc jose cose payload.

PatStLouis commented 1 month ago

I would say for envelopes it would be a did:jwk:?

edit: I also want to suggest that for this specific test-suite, it doesn't really matter. As long as it matches the vcdm 2.0 spec of being a valid URI. It would matter more in something like a VC-JOSE test suite, which is another reason why I would like to keep this type of testing separate and focus on the data model here, not the semantics of the securing mechanism.

PatStLouis commented 1 month ago

I will also open a PR on the implementations repo to add the same information.

decentralgabe commented 1 month ago

There are no requirements for it to be a did:jwk, did:key, or any other DID method (or controller document URI) would work too.

aljones15 commented 1 month ago

@decentralgabe all other test suites use did:key at the moment so that would ensure other implementers at least support the did method used for issuance. We do actually specify only did:key for issuer/verificationMethod in some of the other suites although I believe the VC 2.0 suite does not have such a condition set down in it.

decentralgabe commented 1 month ago

thanks @aljones15 that makes sense. we can stick to did:jwk in our test suite to make things easier.