Verifiable Credentials revocation mechanism for VC based on Peer DID

[jayzhan211]

Is it possible to issue VC based on Peer DID? Should we include VC revocation registry besides DID Doc?

The scenario that I am thinking about is, Alice as a user, would like to issue data access control VC to VC Holder, Bob (or an org), so Bob can request data from Verifier by issued VC, where Verifier is an organization that holds Alice's data, such as Bank, Government or School.

It is clear to me that Alice can issue her data access control VC that is verifiable with Alice Public DID (public key) and her VC revocation registry (non-revocation Proof).

What if I would like to issue VC based on Peer DID? We can get the key from DID Doc. How about VC revocation registry for Holder to get non-revocation Proof?

[dhh1128]

Yes, it's straightforward to issue a VC to a peer DID. No special effort is required, as long as the issuer supports peer DIDs and has received the peer DID value from its owner. Later, no special effort is required to verify, either -- as long as the verifier also supports peer DIDs and has received the peer DID value from its owner.

A revocation registry can list a VC issued to a peer DID exactly like it lists a VC issued to any other DID method. No adaptation is required.

A peer DID is best suited to scenarios where its usage is not public -- but there is nothing that prevents a peer DID from being shared publicly, if desired.

[jayzhan211]

I forgot to clarify that the revocation registry what I would like to talk about is off ledger, something like peer VC?

A revocation registry is stored in VDR in other DID method, so what I want to make sure are,

1. A revocation registry is defined by CRDTs like peer DID Doc? Add/Delete revoked VC list is just like Add/Delete key and service endpoint?
2. It SHOULD be one per relationship?
3. If we need DID Doc, revocation registry, credential scheme/definition for each relationship, should they be separated 3 things or one for all? Should this be specified in spec or decided by the implementation?

Should they be added in spec or they are out of scope and should be added in peer VC spec or VC spec?

[jayzhan211]

Friendly ping @dhh1128

The more general question might be,

Similar to DID, there is a public one and a private one (peer DID). Is it useful that we have private VC (ledger-less VC) that is based on peer DID?

I did not find some references related to this, but they are most likely associated with peer DID, or somewhat similar to it.

Any comment about private VC?