Anonyome Labs has developed a Sudo Platform Decentralized Identity Relay which unites standards-based interoperability with Sudo Platform modularity, reliability, and security. This article by the Sudo Platform DI Relay creator Nicole Khor gives the detail, but in summary:
- The Sudo Platform DI Relay allows decentralized identity peer-to-peer messaging even when a user’s device is offline. Relays receive and store messages for when the user comes back online.
- The Sudo Platform DI Relay is an implementation of Aries RFC 0046 with additional features that allow developers to create secure, compartmentalised relays within their applications.
- The Sudo Platform DI Relay enables Sudo-to-Sudo encrypted messaging, Sudo to out-of-network endpoint encrypted messaging, Sudo-to-Sudo connection establishment using Aries RFC 0160 Connection Protocol, and Sudo to out-of-network communication establishment via the Connection Protocol.
- Our DI Relay sits alongside our other DI offerings, such as the Sudo Verifiable Credentials service, and the Sudo Identity Wallet app (and their associated SDKs, sample apps and documentation)
Let’s dive into the technical detail about the Sudo Platform DI Relay.
What is a DI relay?
A DI relay makes it possible to exchange messages between peer agents. Relays are necessary for DI peer-to-peer messaging because they allow edge agents, such as mobile phones, to store and forward messages, regardless of the agent’s availability. Without a relay, messages cannot be delivered to offline recipients, so the relay acts as an intermediary for receiving and storing messages until the recipient is back online.
What are edge agents?
An edge agent is an application that sits on an edge device, such as a user’s mobile phone. Edge agents can provide an array of DI functionality such as providing wallet and peer-to-peer services. Since many devices are not guaranteed to always be available online, relays act as always-on endpoints for receiving inbound message from sending peers. When the device later reconnects to the network, it requests any received messages stored by the relay.
Edge agents differ from DI cloud agents, which are usually discussed together. Cloud agents are software components similar to edge agents, but cloud agents provide cloud-based services that are always available – they do not need relays because they are always connected to the network.
What is a relay?
A relay is a passive entity in peer-to-peer message delivery that simply receives a message and forwards it to the next service or agent (see Figure 1). Relays may forward these messages on the same or a different transportation medium. This opens the possibility of creating mix networks for communications that are more difficult to trace.
Further, relays do not decrypt or encrypt messages, so the sender does not need to be aware of the presence of a relay or adjust their behavior to account for it. As an example, the sender would not need to manage extra keys to use relays, unlike its mediator counterparts.
Unlike relays, mediators actively participate in the message delivery process by decrypting the outer layer of the packet received (chunk of data that goes across the network). Mediators use the decrypted information to forward the packet onwards to another participant in the delivery process. Because of this additional layer of encryption, senders must manage extra keys to use mediators. For every extra mediator in the message delivery sequence, the sender must manage one extra key. Further, the sender must encrypt the message multiple times using the public key of each mediator, in the precise order of the receiving mediators. For N mediators, the sender must store N additional keys and encrypt the message N times. Figure 2 shows 3 senders using the same mediator to send messages to 3 receivers. Note that each sender must store an extra public key for the mediator.
With the extra complexity, what is the benefit of using mediators? One benefit of mediators over relays is that the additional encryption conceals the end destination from an eavesdropper and deters traffic analysis. Another benefit is ‘herd immunity’, where multiple connections are not easily traced to a single recipient. Users must make a risk decision about whether this additional benefit is worth the extra complexity.
Why use relays and not a mediator as an always-on endpoint?
We chose relays over mediators because the goal was to build a simple transport mechanism for DIDComm connections. Relays provide a lightweight means of transporting DIDComm messages, which are already encrypted. It is possible to build a mediator later as a subsequent iteration if it is deemed necessary to conceal the message route and endpoint destination.
There are some additional costs with mediators that do not fit into the lightweight requirement. The onion-style routing of mediators is difficult to diagnose when communications fail. The routing also relies on the sender encoding the correct source routing. The costs associated with sending messages also grow with the number of encryption operations required for each mediator to the recipient. Further, the herd immunity the mediator provides can be achieved with a simpler relay by implementing separate and anonymous relay connections (or a post box) for each DIDComm connection.
Relays are a standards-based approach to DI peer-to-peer message delivery. Aries RFC 0046: Mediators and Relays defines mediator and relay behaviour for all implementations to follow, allowing interoperability by design. This RFC was initiated in 2018 and the identity community currently accepts it. Due to this, relays built according to standards are interoperable with other solutions from a variety of vendors within the global DI ecosystem.
Enter the Sudo Platform DI Relay
The Sudo Platform DI Relay unites standards-based interoperability with Sudo Platform modularity, reliability, and security. The Sudo Platform DI Relay is an implementation of Aries RFC 0046 with additional features that allow developers to create secure, compartmentalised relays within their applications. This sits alongside other DI offerings, such as the Sudo Verifiable Credentials service, and the Sudo Identity Wallet app (and their associated SDKs, sample apps and documentation) (see Figure 3).
The Sudo DI Relay allows users to participate in peer-based messaging over HTTPS. It provides a unique, always-on endpoint for each connection the user creates. Messages sent to their endpoint are stored in a post box dedicated to that connection. These post boxes can be associated with a Sudo identity to allow for complete compartmentalization between the identities associated with the connections.
Use case 1: Sudo-to-Sudo encrypted messaging
You can see in-network messaging between two Sudo mobile agents in Figure 5. The Sudo mobile agent (A) is the inviter of the DIDComm invitation exchange, and Sudo mobile agent (B) is the invitee. Sudo mobile agent (A) creates their post box and subscribes to inbound messages before the DIDComm invitation exchange. Sudo mobile agent (B) creates their post box and subscribes to inbound messages during the exchange.When the user sends messages to their peer, they can store their outgoing messages in their own post box to store the entire message exchange. Note that these messages are encrypted. Retrieving a list of messages in the post box will retrieve both incoming and outgoing messages.
Use case 2: Sudo to out-of-network endpoint encrypted messaging
Out-of-network messaging occurs when a Sudo DI mobile agent communicates with another non-Sudo DI agent, as seen in Figure 6. The user creates a post box and undergoes a DIDComm invitation exchange directly with the peer. Afterwards, the user subscribes to messages incoming to their post box. Messages are sent back to the peer via the peer’s chosen transport destination. These outgoing messages can be stored in the user’s post box for persistence.
Using the relay to help establish DIDComm connection
Aries RFC 0160 Connection Protocol defines a protocol that allows agents to establish connections. At the time of writing, this protocol is commonly used, but we expect that RFC 0023 DID Exchange will eventually replace Connection Protocol, along with RFC 0434 Out of Band Messaging. These protocols have a similar messages flow with subtle differences in the message contents (which we’ll explain).
Use case 3: Sudo-to-Sudo connection establishment using Connection Protocol
Figure 7 describes how the relay can be used to assist in the Connection Protocol, where Sudo mobile agent (A) is the inviter, and Sudo mobile agent (B) is the invitee. First, the inviter creates a post box and subscribes to messages incoming into that post box. The inviter sends a send_invitation message to the invitee containing the service endpoint (serviceEndpoint), recipient keys (recipientKeys), and other metadata. The service endpoint is the post box endpoint from the Sudo DI Relay. This is sent directly to the invitee via another medium such as QR code. QR codes are often used to initiate in-person connections, because they are fairly impervious to man-in-the-middle attacks.
Upon receiving the send_invitation message, the invitee then creates their post box and subscribes to incoming messages. They can then reply with a connection_request that is sent directly to the inviter’s post box. This message is forwarded to the inviter, who then replies similarly with a connection_response message that is sent directly to the invitee’s post box. The protocol is finished with a final ack sent by the invitee to the inviter.
DID Exchange and Out of Band Messaging can also be achieved using the relay for Sudo-to-Sudo connection establishment. DID Exchange must be preceded by either an implicit invitation with a readily known resolvable DID, or an explicit invitation using an invitation from Out of Band Messaging. The out_of_network message in Out of Band Messaging can replace the send_invitation message in Figure 7. The didcomm_response_message is diagrammatically similar to the connection_request message.
The request message in the DID Exchange protocol has a similar flow to the connection_response in Figure 7. The exchange_response message is diagrammatically similar to the ack message. DID Exchange finishes with a final complete message. While each of these messages have a similar flow between actors in the diagram, their purpose and contents can vary between protocols.
Use case 4: Sudo to out-of-network communication establishment via Connection Protocol
Figure 8 describes how the relay can be used to facilitate Connection Protocol between a Sudo and an out-of-network peer. The send_invitation message is sent directly to the peer. As the connection_request contains a DIDDoc which specifies the peer’s out-of-network service endpoint, the connection_response can be sent to that endpoint. The remaining message flow is similar to use case 3.
DID Exchange and Out of Band Messaging can also be achieved between a Sudo DI agent and an out-of-network peer. The out_of_band message replaces send_invitation on Figure 8. The didcomm_response_message replaces connection_request. The request message replaces connection_response, and the exchange_response replaces ack. DID Exchange completes with an additional complete message.
Publicly resolvable DIDs and the Sudo DI Relay
Publicly resolvable DIDs resolve to a DIDDoc. This DIDDoc contains a service endpoint on which a server listens to invitations. This server should ideally also provide extra features such as traffic filtering, DOS detection and spam identification. It is possible that the Sudo DI Relay can act as this server, but these extra features are not implemented.
To read more about the Sudo DI Relay, refer to the Sudo Platform documentation.
To find out how your business can rapidly deliver customer privacy solutions with the Sudo Platform digital identities and DI capabilities, read our 5-part series.
Photo by Wright Studio
