The Verification Method of a Revocation List Credential MUST match the issuer of a Revocable Verifiable Credential

[OR13]

Yet the current API definitions do not define this behavior.

[peacekeeper]

I don't think that should be a requirement. I believe there are use cases where the entity that issues a credential is not the same as the entity that can revoke it.

E.g. a university can issue a diploma credential, but only a separate academic review panel, or a court, or some government entity, or someone else can revoke it.

[OR13]

@peacekeeper I agree, there are also agility concerns, consider that you may issue a revocation list VC with EdDSA, but then wish to consume an index and issue a revocable credential with ES384... you can't do that today, and would not be allowed to do that in the future once we address these revocation / issuer api issues, unless we change that behavior.

[TallTed]

E.g. a university can issue a diploma credential, but only a separate academic review panel, or a court, or some government entity, or someone else can revoke it.

This is incorrect, as the world stands. See [1], [2]...

I think some other example(s) are needed to confirm that some entity/ies can revoke credentials issued by some other entity/ies.

[OR13]

related concept: https://www.techtarget.com/searchsecurity/definition/Certificate-Revocation-List

[peacekeeper]

This is incorrect, as the world stands.

It was just meant as a theoretical scenario, but I admit that I can't think of any concrete example. Perhaps I should have thought about it more before commenting :)

[OR13]

This issue is blocked pending changes to the issue endpoint, as well as the currently undefined get credentials endpoint.

The problem is that the current APIs require the caller to understand the specifics of the revocation list, and they don't define error cases for attempting to get a signature over a credential with a list that is "not supported" by the issuer.

At a minimum, an issuer should have to disclose how they intend to host revocation lists, for the feature to be supported... if we can't agree, we should remove revocation lists from the api.

[msporny]

This was discussed on 2022-10-04 and there seemed to be at least 3 options. The first was to ensure the same cryptosuite was used to sign both the VC and the revocation list. The second was to allow multiple cryptosuites to be applied in parallel (cryptographic layering) to both the VC and the revocation list (as long as the same cryptosuites are applied to both. The third was to allow different cryptosuites to be applied to the VC and the revocation list. @TallTed was concerned about what happens when a cryptosuite is broken (if only one is used). @jandrieu noted that the DID that created a VC is the one that signs the revocation list -- but DIDs shouldn't be restricted from rotating their verification methods and therefore the verification method might drift over time (and that's ok). @jandrieu noted that the use of SHOULD would be acceptable, it's a good practice. @jandrieu noted that if the Verifier is expecting a specific cryptosuite to be used for VCs, it might be surprising if the revocation list uses a different cryptosuite.

The group came to consensus on the following language which should be added to the specification:

As a best practice, Issuers SHOULD use the same verification method(s) and cryptosuites to protect both the Verifiable Credential as well as the revocation list.