Credential module (final form)

After considering the matter from different angles, I think the best way to proceed would be to keep the existing implementation, but add a new parameter to the module that is the "allow list" for credential definitions.

It will work this way: let's say we have a credential definition that is for revocation lists and is: https://anamika.id/definitions/revocationList2020 . This definition describes the current implementation of the revocation list. This type of credential is useful only if it's on-chain, on the other hand, we don't want somebody to make a credential definition with PII in it and publish it on-chain.

So we list the https://anamika.id/definitions/revocationList2020 in the allowList of the credential module. As a consequence, when the msg_server receives a request to issue a PVC, it checks that the definition of the credential is in the allowList

This solution has the advantage that, we can define a set of definitions that we accept to be published online such as:

Revocation list
Zone manifest (for the chain registry)
Public Credential Manifest (to anchor the link of a credential that is hosted off-chain)

and in case there is the need or desire for another schema to be allowed on-chain, a definition can be published on-chain and added to the allowList via gov vote.

elesto-dao / elesto

Credential module (final form) #260