Use Case for Veramo

[praveensankar]

Hello,

In the documentation, detailed explanation of the user-agent is provided. Is there any documentation available which shows how the user agent can be integrated with issuers and verifiers for some use case ? I am looking for end to end analysis of particular use case and what role veramo plays with other entities.

Thanks,
Praveen

[mirceanis]

Veramo can be used to build agents for both issuers, holders and verifiers.

Example credential flow:

• Issuer uses agent.createVerifiableCredential() to issue a credential.
• Issuer may use agent.packDIDCommMessage() and agent.sendDIDCommMessage() to send the credential to the holder, if they can establish a DIDComm channel.
• Verifier requests credential from Holder, perhaps using @veramo/selective-diclosure, or maybe also DIDComm, but many other protocols can also be implemented and used with Veramo.
• Holder uses agent.createVerifiablePresentation(), or agent. to package the credential.
• Holder sends the presentation to the Verifier (using DIDComm, or other protocols).
• Verifier calls agent.handleMessage() to interpret, verify and optionally store the presentation and the credentials it contains.

Note: The verification API is undergoing some changes see #375 so it will likely be a lot more flexible and decoupled from the message handling logic.

I hope this helps.

[mirceanis]

Can you clarify what you mean by "verification and issuance process with some blockchain"?

In Veramo issuers, verifies, holders are usually identified by DIDs, which in many cases are anchored on blockchains (depending on the DID method).
DID resolution is performed for credential or presentation verification or for DIDComm communication. For DIDs that are anchored on blockchains, this usually means that some blockchain read operation is done.

Veramo is agnostic to the DID methods involved, as long as plug-ins exist to facilitate these interactions. We provide some plug-ins that interact with Ethereum blockchains for did:ethr, and have also experimented with did:ion which is based on bitcoin. We also provide plug-ins for did:key and did:web which are not anchored on blockchains.

[mirceanis]

We also experimented with credentialStatus using the ethr-status-registry, but it is not a direction we have pursued strongly because of costs and a spec that was not even defined at the time, therefore it is not part of the default offering of veramo.

It is very easy to create such integrations, but I would recommend waiting for a more mature specs/implementations for these status checks.

[praveensankar]

Thanks for the answer. I was thinking that veramo itself act as different did method and provide it's own rules for the use cases. Your answer has helped me realise my misunderstanding.

If i am correct, veramo is trying to support as many as did methods as possible starting with did:ethr, did:web, etc. To provide tech stack to create and transfer the verifiable credentials.

But the tricky part is when different DID methods have different ways to communicate with different blockchain systems, how does the veramo framework plan to address this ? It would be really useful to have this information.

[mirceanis]

We don't plan to provide the Blockchain access layers for everything that is out there, but instead rely on DID method drivers (that can be either libraries or endpoints).

For example, we use a library driver for did:ethr and call an endpoint to resolve did:io.

Also, the modular and extensible nature of Veramo makes it so that different implementations can co-exist. We don't have to be the ones deciding which DID methods are supported.

[praveensankar]

Thanks for the great explanation. I understand that It's the job of the resolver to communicate with the storage and retrieve the documents.