Implementing a new credential model

[rosdec]

Hello everybody and thank you for your effort in keeping alive this community,

we are playing with the idea of implementing a brand new ICredentialIssuer to accommodate our SSI model. In particular, we see some problems with the current interface and we are wondering about which is the most correct way of implementing this.

In our model, the credentials and the presentations can be revoked and have a status that can be queried. Where is the most correct way of implementing this? Should we extend ICredentialIssuer to have the missing functions?

Thank you in advance,
Rosario De Chiara

[mirceanis]

Hello and thank you for your suggestion and willingness to contribute,

We have not added any special API to ICredentialIssuer for adding a revocation layer because we rely on the credentialStatus property of the verifiable credential data model.
This means that as long as you add a proper credentialStatus entry to your credential payload, it will adhere to the spec, and that should allow it to be queried in a standard way.

We have examples of this in the @veramo/cli using a EthrStatusRegistry2019 credential status method.

There are no readily available examples of a query for this status that I can share, but we imagine we will be using the credential-status library as an orchestrator of different status types.
This status query is directly linked to the generalized verification API improvements that are planned (see #375).

Note, that the credential-status and ehtr-status-registry libraries were created before the specs for credentialStatus existed, so there may be inconsistencies with the examples in the VC spec. Also, they work only with JWT credentials for the moment.
These will be fixed once we can spare some time for maintenance. I encourage you to flag anything you find to be broken since that helps a lot.

I hope all this helps, but if it doesn't please add some details of the changes to ICredentialIssuer that you envision.

[rosdec]

Thank you @mirceanis for your prompt response. You gave us some hints and we are still studying to grasp the inner model behind the design of Veramo.

We got the general idea of the ICredentialIssuer interface but we are finding problems in fitting it in our SSI system.

We are wondering what is the best way of integrating the writing of the hash of a newly created credential, in blockchain, right after you call CreateVerifiableCredential.

One educated guess is that we have to write another plugin that would accommodate the blockchain-related processes and integrate them in the current way of using the CredentialIssuer. The idea we are playing with is to design something that can be used as shown below:

var newVerfiableCredential = await agent.createVeriafiableCredential( ... )
var hash = agent.IssueVerifiableCredential(newVerfiableCredential)

the IssueVerifiableCredential will take care of anchoring to the blockchain the verifiable credential and it will be a function offered by a new plugin we would work on and that will be aware of the blockchain.

The same would be done for the Presentations.

What do you think of this approach? Or we are missing something in the general vision of Veramo?

Cheers,
Rosario

[mirceanis]

It looks like a new plugin makes more sense than modifying the ICredentialIssuer.
If your SSI system requires that the hash of the credential is anchored on-chain, then it seems like a good idea to create a new plugin that is used by your system.

In that case, I imagine this would be used like this (based on your example):

var newVerfiableCredential = await agent.createVeriafiableCredential( ... )
var { hash, transactionHash } = await agent.anchorCredentialOnChain(newVerfiableCredential)

Since this is specific to your use-case, I guess it's best if you write and maintain the plugin independently of this repository.
Take a look at this plugin template repository which should help you to write your plugin. The template repo has more than you need, actually, since you are probably not going to write a didManager or keyManager. Instead, you will likely replace all instances of IMyAgentPlugin and its corresponding methods from the template with your own definitions.

Your plugin would expose a anchorCredentialOnChain method (see this line) which might call the key-manager plugin (context.agent.keyManagerSign(...)) to request a signature for the transaction like so.
The transaction is likely to take a long time to mine so I imagine it's better to return the transactionHash along with the hash of the credential.

Looking forward to some progress update!
Consider posting about this plugin in the show and tell part of the discussions board, and if you make it open-source we can try to assist when you run into trouble.

[frazur]

Thanks @mirceanis, this is all extremely useful! We had come to something similar to the repo structure by looking at the Veramo code, but with a template it is much better (would be great to put the link on the https://veramo.io/docs page)

I think in the first instance (as you suggest) we will continue to develop plugins for our specific use case, but we will (try to) design something quite generic so that it can be used in other contexts (and so that it makes sense make it open)

keep in touch

Francesco