Where will the credential definition be stored?

[thomas-tran]

In the ether-did provider, the identity will be stored in ledger. However, I am wondering should the framework allow the credential definition or its schema to be stored in the ledger as well.

[mirceanis]

Can you elaborate on the use-case, please?
Also, what would be the difference between the credential definition and its schema?

[thomas-tran]

I assumed that the project will implement based on the verifiable credential standard data model here https://w3c.github.io/vc-data-model. The section 5.8 Zero knowledge proof which highlight the credential definition and the schema https://w3c.github.io/vc-data-model/#zero-knowledge-proofs

In the diagram below , the credential schema will be stored in the registry and I am curious how to implement it in veramo

T

[mirceanis]

I suppose the last phrase in the verifiable data registries description paints the proper picture:
"Often there is more than one type of verifiable data registry utilized in an ecosystem."
In the case of veramo, this will depend on the configuration you use.
By using a modular and extensible architecture, the framework enables the use of multiple such registries, depending on the requirements and capabilities of each plugin.
In this repository, you'll find plugins that use an ethereum ledger for managing did:ethr identifiers, or the regular web public key infrastructure governed by certificate authorities and the https protocol for did:web.
Also, if you use the universal resolver wrapper you are effectively using lots more verifiable data registries.

We've also made plans to add basic support for a couple of revocation mechanisms (#334) as well as some controller plugins for other DID methods (#336 #335).

To answer your question more precisely, at the moment there is no veramo plugin that uses a ledger to store credential schemas.
If this is something that you would like to build, then you are welcome to come up with a proposal or use the Show and tell section to present something.