Peer DIDs — What Can You Do With It?

Decentralized Identifiers (DIDs) are a unique type of identifier that allows entities to generate and control their digital identity. Often, these DIDs are implemented on blockchains, databases, IPFS, and other Decentralized Ledger Technology (DLT) systems that establish a public and shared source of truth. These DIDs help the parties involved in a transaction to resolve the DID to a DID document and verify the authenticity of the information with the public keys present in the document.

That said, DID implementations don’t always have to be on blockchains or other systems that establish a public source of truth. It can also be implemented as a direct interaction between the two parties to a transaction. The way that two entities interact with each other directly without involving a network is the core principle of peer DID methods.

The idea behind creating these peer DID methods is to ensure a cheap, fast, secure, and scalable way to create and maintain private relationships between two entities. Let’s say, Alice and Bob are two entities who are interacting with each other, so only both of them care about the transaction and have a need to resolve their respective DIDs.

So, why should the other parties who are not connected to a transaction see their DIDs?

This is why peer DIDs could be a possible solution in cases that involve exactly two parties.

Also, these DIDs can connect back to a chain-based ecosystem when needed, as long as the credentials have not been revoked, and this is what makes them a flexible and versatile choice. And of course, it gives entities complete control over their digital relationships.

How are Peer DIDs Implemented?

In a traditional DID implementation, the public keys of both parties are registered on a blockchain or any other DLT, but in a peer DID, there’s no network. So, Alice creates a DID, puts it in a DID document, and sends it directly to Bob. Likewise, Bob creates a DID, puts it in a DID document, and sends the doc to Alice.

So, both Alice and Bob create their records and send the metadata of their records to each other, so one can use that metadata to look up the record of the other. This information can also be cryptographically encrypted for security.

This is something similar to the analogy where Alice creates a part of a secret and Bob creates a part of the same secret, and they exchange it with each other, so only both of them know the complete secret.

This brings up many questions regarding the creation, security, and storage of DID docs, so let’s delve deeper into them.

How are Peer DIDs created?

To create a peer DID, you need two things — a stored variant and a numeric basis.

Source: DIF

A stored variant is a DID doc that contains the keys, but not the actual DID value. The numeric basis is the 256-bit value you get when you use the sha256 hash value or any other numeric algorithm on the contents of the original DID.

This 256-bit string has to be prefixed with a few other values. First off, you need to mention the numeric algorithm you’re using and the standard is to use the value “1” for sha256. The second value you’ll mention is the binary transformation method used and again the standard is base58 and it is represented by z. This is followed by a bunch of alphanumeric characters that tells the receiver that this is a multi-codec value where 32 bytes are encoded using SHA256 and this is finally followed by the encoded value of the DID contents.

Add all of these to the method prefix — did:peer.

So, your final peer did will look something like this

did:peer:1zdksdnrjq0ru092sdfsd491cxvs03e0

The key takeaway from this is that you create a DID and run it through an algorithm to get a peer DID that can be shared directly with another entity.

How are Peer DIDs Shared?

Next, comes the question of how the peer DIDs are shared?

A popular choice is to use the Aries RFC 0023 DID exchange protocol. But you can also send a DID and a signed DID doc over a TLS session, but watch out for SSL applications between the two of you, as this can bring in an unnecessary middleman into the transaction.

Where are the DIDs stored?

Peer DIDs are stored in a place that’s controlled by both the parties and could be a hard drive, mobile device, data center, etc. The only key aspect is that these two entities alone should have access to this DID doc on any storage device. And as long as it is not available publicly, it is a peer DID.

Should you use Peer DIDs?

Peer DIDs offer many benefits such as,

• No transaction costs involved
• Easy to create and maintain
• Since these DIDs are independent of a central system such as a GDPR controller, they can be scaled as needed
• Offers the highest levels of privacy as only the parties involved can access the DIDs
• No uncertainties or external problems since these DIDs are not associated with any particular network
• No degradation of trust throughout the entire lifecycle.
• In tune with local-first software philosophies
• Reduces unnecessary correlation between a verifier and an issuer of a verifiable credential.

But you can use it only when exactly two parties are involved in a direct exchange of information. So, that’s something to consider when deciding if peer DIDs are the right choice for a transaction.

We hope this was a good starting point to kindle your interest in peer DIDs and the world of verifiable credentials and self-sovereign identity (SSI) in general.

Affinidi provides building blocks for an open and interoperable Self-Sovereign Identity ecosystem. Check out our Developer Resources to know more about how you can implement SSI.