How does Veramo store dids on ethereum blockchain and how can we fetch it?

[Ahaana-Jha]

I am new to blockchain technology. I came across DIDs which led me to Veramo. But I am not able to understand how it is storing DIDs on the blockchain. I tried to look for the DIDs generated by Veramo on Ethrescan but it doesn't exist. How can I fetch it from the blockchain? When I dug deep I found out uPort uses a proxy contract, identity manager contract, and relayer contract but didn't get how ether did registry contract is associated with all these contracts. Also somewhere it was mentioned that Veramo doesn't function on contract-based dids, then how is it able to interact with blockchain without meta transactions?

For Veramo I could only find one contract that's the "https://github.com/uport-project/ethr-did-registry/blob/develop/contracts/EthereumDIDRegistry.sol" contract. I tried to use the "0xdCa7EF03e98e0DC2B855bE647C39ABe984fcF21B" in remix but I am not sure how to get the parameter values that it requires to execute any function.

For example in the function------->
function checkSignature(address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 hash) internal returns(address) {
address signer = ecrecover(hash, sigV, sigR, sigS);
require(signer == identityOwner(identity), "bad_signature");
nonce[signer]++;
return signer;
}

How to get values of (address identity, uint8 sigV, bytes32 sigR, bytes32 sigS, bytes32 hash)? How are these values passed to the contract?

My basic requirement is to fetch the DIDs from the blockchain that I have generated using Veramo to check if it actually exists on the blockchain. Please can anyone help?

[mirceanis]

That's a great question and you are almost there with ethr-did-registry, that is indeed the contract that holds the data related to did:ethr identifiers.
The reason you don't see anything related to new DIDs on the block explorer is that for did:ethr creation happens without a transaction. To create a DID you generate an ethereum keypair and prepend did:ethr: to the hex string encoding of the public key, or to the corresponding ethereum address.

Transactions are needed only when you want to update the DID document, to change the owner or add new keys and services.

The relevant docs for how this happens can be found in the did:ethr spec.
The same repository contains the code for the reference implementation of the did:ethr resolver.

[Ahaana-Jha]

Thanks for your response. But I still got a query, what do you mean by when you mentioned: "did:ethr creation happens without a transaction"? Doesn't everything that happens on the blockchain is a transaction?? How is DID creation not a transaction? Can you please explain?

[Ahaana-Jha]

Also, I am not sure about the methods in the "EhereumDIDRegistry" smart contract. I mean how are we using it through Veramo? How data is passed to smart contract through Veramo UI? I might be naive. But a little help here, please.

[mirceanis]

All the explanation for how DID creation happens without a transaction is in the did:ethr spec. Please go through that first and come back with questions.

The simple explanation is that the initial DID just wraps a public key, and there is no need for a transaction to create a public key. The initial DID, being just a public key, references only itself.
Even if the DID is created without a transaction, the resolver still checks on-chain to see if there are any updates, when there are no updates, the resolver returns the default DID document, which contains only the initial public key or address.

For your second question, some methods on the contract (setAttribute) are called from veramo when you execute functions such as didManagerAddKey() or didManagerAddService() for a did:ethr identifier.

Other methods are called by the resolver when building the DID document, to get the last change or the current owner.

[Ahaana-Jha]

@mirceanis Thanks for the quick response and detailed explanation. It indeed helped in better understanding. I had checked the spec earlier but wasn't clear much. I shall look into it again and will get back to you in case I need further explanation. Thanks again.

[Ahaana-Jha]

@mirceanis I get that creating a did doesn't involve interaction with the blockchain. But storing it on the blockchain is a transaction right? I am not able to understand how Veramo stores did on the blockchain. Does it use another smart contract to do it? Because the 'ethr-did-registry' contract only has methods that operate on/return information about the dids that are already stored on blockchain (i.e. the changes made to the did document).

So my question is -->
How Veramo stores did on blockchain and returns blockchainAccountId?

Please correct me if I am wrong and clarify my doubts.

[mirceanis]

Please go through the spec as it explains this in detail.

The DID does not have to be stored on the blockchain by any other means than the registry.

When an ethereum address is created, it does not have to be registered on-chain. It already exists as far as the chain is concerned in the incredibly vast space of ethereum addresses.

This is what happens when you create a did:ethr and this is why it doesn't have to be explicitly stored on-chain when it is created.

After you create a DID, if you want to modify it, you will have to send a transaction to the registry contract, signed by the DID owner address. For a fresh DID, the owner address is itself.

If the did:ethr is created using a public key, the owner ethereum address and implicitly the blockchainAccountId can be computed from the public key without interacting with the chain.

When the resolver queries the registry for a DID that has no changes, the registry returns an empty list of changes, so the resolver knows it can return the default DID document, which references the key and/or ethereum address that is part of the DID string being resolved.

I hope this clarifies things a bit.

[vijay05155]

@mirceanis What do you mean by this, "When an Ethereum address is created, it does not have to be registered on-chain, it already exists as far as the chain is concerned in the incredibly vast space of Ethereum addresses" ,Can you please explain this in details.

Do you mean that when a did is created it references to already existing blockchain addresses or an new address is created first then it refers to the dids.

[mirceanis]

All ethereum addresses already exist, just as all numbers from 0 to 2^160 already exist.

When you create an ethereum wallet, you generate a private key (a big number) from which another big number is computed, the public key. Then the public key is hashed and the last 160 bits of the hash form the ethereum address. These are just numbers. They already exist. Just as when you created your metamask account, there was no transaction.

Now, when you create a did:ethr, you go through the exact same process, and at the end, you prepend the string did:ethr: to the hex encoding of the key or ethereum address.

Any ethereum address plus a did:ethr: prefix is a valid DID. Since all ethereum addresses already exist, all did:ethr already exist, they don't have to be registered.

I don't know how else to explain it.
I hope this is enough.

[Ahaana-Jha]

@mirceanis
I got a few more questions:

1. Where do you store the DID docs and VCs?
2. How do you do the comparisons to verify the authenticity of VCs?
3. Do you use IPFS to store DID Docs and issued VCs?
4. If IPFS is used, are the hashes of DID docs and VCs stored on the blockchain as well? If yes, which smart contract is used to do so?

[mirceanis]

It's important to note first that Veramo is modular and that there is no single storage system in use for all situations. Veramo deployments can be adapted to fit the needs of the application where it's being used.

That being said, let me try to answer on point:

1. DID documents are never stored by Veramo, instead we use the @veramo/did-resolver plugin to resolve DIDs to their corresponding DID documents as needed. For a lot of DID methods, the DID document is never stored as a file, but constructed as needed (example, did:ethr, did:key, did:pkh), while for others it might make sense to think of the document as a file stored somewhere(did:web, did:3)`.
   As for VCs, Veramo uses a local database in our existing implementations, but that can also be mixed and matched. As long as a new storage plugin uses the same plugin interface, other plugins don't care where exactly data lives.

2. When verifying VCs, Veramo interprets the issuer as a DID, then resolves the DID to get the DID document and then tries to see if the signature of the VC could have been produced by one of the relevant keys in the DID document.

3. We don't use IPFS right now (v3.1.0), but we are working towards an integration with ceramic/3box where IPFS is a core component.

4. There is no core component of Veramo that relies on a blockchain, but some plugins use it.
   For example, did:ethr uses an ethereum blockchain to store DID document modification events. We also had a proof of concept credential revocation registry based on ethereum, and tentative support for did:ion where the bitcoin network is used.

[Ahaana-Jha]

@mirceanis We are thinking to implement DID using private network. Is it possible? Do you have any future plans to provide did method for private network as well?

[mirceanis]

did:ethr already works on private ethereum networks.

To use it on a private network you have to deploy the registry contract to that chain.
And then configure your resolver to point to that chain.

When used in Veramo, you need to add a provider for that chain as well.
Here is an example where the local ganache node is used.

[Ahaana-Jha]

@mirceanis As per client requirement, we need to implement a private network using hyperledger and not Ethereum-based private network. So is it possible to use Veramo in that case? Hyper ledger does provide Aries, Indy and Ursa for DID implementation but was curious if we can implement the same using Veramo?

[mirceanis]

Of course.
Veramo is agnostic to the types of DIDs that are in use.
To make use of a particular DID method in Veramo you need a resolver for that DID method and a provider for it.

The resolver gets called automatically when you do stuff like verifying credentials (and in certain scenarios also when issuing credentials or when packing DIDComm messages)
The DID provider is used by the DIDManager plugin for all the Create/Read/Update/Delete operations.

We already have some implementations for DID resolvers and providers for did:ethr, did:key, did:web. We plan to add some more DID methods to the core offering, but it is not a high priority at the moment.
But, since Veramo is very modular, you can implement this support yourself and use it with Veramo without the need to wait for an implementation from us.

There are also some Aries protocols for credential exchange that are on our roadmap (#266 #270 and others), but it will be a while until we are able to dedicate some development bandwidth to add that support.

[Ahaana-Jha]

@mirceanis I need a suggestion with the below scenario-
Let's say I have a mobile DID wallet (created using Veramo) and I want to login into a video session (third party app) using my DID, how will this third party app verify that the DID belongs to me or I am a valid user? Can this application verify a user if it doesn't have a Veramo agent?

[Ahaana-Jha]

@mirceanis Thanks for the response. I appreciate it. 🙂

[Ahaana-Jha]

Usually the initial exchange of contacts is just a simple exchange of DIDs. Messages should be signed so that the service (video session app in your example) knows that the user is actually in control of the DID they claim to have.

During this initial exchange, the service learns the DID of a user. The fact that the user is valid or not is not something that can be determined by the DID itself. This is application specific. You can think of this as the user-registration part.

Then, in all the following interactions, when the user logs in using the same DID, they prove to the service that they are the same user that registered before.

The service needs some verification capabilities for this system to work. This can be done by Veramo or other libraries.

@mirceanis When we create a VP, is it signed automatically or do we need to call any method for signing? What did you mean by when you said "Messages should be signed so that the service (video session app in your example) knows that the user is actually in control of the DID they claim to have"? Please explain a bit.

[mirceanis]

In Veramo, both VCs and VPs are signed automatically, there is no need to call another method.

I'm not sure what to explain. Can you tell me what confuses you?

[Ahaana-Jha]

Actually, we were looking into your uPort application and planning to implement a similar approach but didn't quite understand how the mobile application and web application are communicating. What is in the QR? Does it have SDR request? Is this request directly sent to a mobile app or any other server first and then to the mobile app?

Considering the same scenario where there is a mobile wallet and a web application, we are planning to implement a solution as follows:

the web application has a QR with JWT/SDR request which is sent to the mobile app using a socket on scanning. Now the mobile app resolves the SDR request and generates the response which is further fetched by the web app using another QR. Do you think it's a good approach? Or can you suggest a better solution?

[mirceanis]

In the uPort ecosystem, the initial QR code, presented by a webapp is a JWT/SelectiveDisclosureRequest(SDR).
This request could also include a reply_url and an encryption public key, in case the reply should be encrypted.

The uPort app would scan this request and produce a signed response containing:

• the initial SD request (used as a stateless challenge/response mechanism)
• the DID of the user
• an encryption key (further messaging is end-to-end encrypted)
• a token usable with push messaging services
• any VCs requested in the initial request

This response would be signed by the user DID and sent back to the reply_url. This response could also be presented by the mobile app as a QR code, but not many webapps have QR code scanning capabilities.

The webapp would verify the response, extract the initial request from it and verify that it was issued by itself, and then extract the user-shared details.
The web app could then send encrypted messages to the user using the push messaging token and the encryption key, or create new QR codes that the user app could scan.

You can get more info about the original uPort protocol from the spec. And you can try to implement a similar mechanism, or extend the one we have in Veramo.

---

In @veramo/selective-disclosure we partially implement this protocol with a few changes:

• there is no push-messaging, because there is no longer an assumption of a mobile app
• encryption and direct messaging is done only through DIDComm, there is no reply_url or encryption key being directly exchanged.
• the reply is a VP
• the stateless nonce mechanism is not implemented.

We did not re-implement the full uPort SDR flow in Veramo because we saw that more generalized presentation exchange standards were being developed in DIF and thought we would implement those directly once they are close to being finalized. There were also existing ARIES protocols that could also have been implemented.

It seems that the uPort SDR is the only one that remained stateless and has the smallest number of roundtrips between parties, so I think it is still worth continuing, but at the moment we don't have bandwidth for it.