Re: [Email-to-DID Bridge] Exploring a practical migration path for email infrastructure

Hi Jori

It’s hard to explain every detail in a single email but since the points
raised are critical I would try best to give a proper walkthrough

Let me walk through the protocol step by step and show precisely where
privacy risks arise and how the architecture addresses them.

Step-by-Step Protocol Flow


Phase 1: Sender initiation


Scenario: Alice (an email user) wants to message Bob (a DID user).


   1.

   Alice composes an email to bob-executive@company.org
   2.

   Her email client performs a standard DNS/MX lookup for company.org
   3.

   The message is delivered to company.org’s SMTP server, which runs the
   bridge


At this stage, privacy behaves exactly like normal email. Alice’s email
provider sees standard SMTP metadata. The receiving SMTP server at
company.org receives the message within infrastructure controlled by that
organization. This is the baseline privacy model of email and cannot be
changed by any overlay system.

Phase 2: Bridge processing


   4.

   The SMTP server invokes bridge.handle_email(message)
   5.

   The bridge consults its internal routing table:

   bob-executive@company.org → did:web:company.org:bob
   6.

   The bridge converts the email into a DID message representation


The critical design decision here is that the email-to-DID routing table is
privately maintained by each organization. There is no global directory and
no shared mapping service. company.org alone controls and stores this
mapping inside its own infrastructure.

Phase 3: Message transformation


   7.

   The bridge constructs a DID message:



   -

   The payload is encrypted using Bob’s public key from his DID document
   -

   Metadata such as sender, timestamp, and subject is preserved
   -

   Email headers are mapped into DID message attributes


End-to-end encryption is applied at this stage. Only Bob can decrypt the
message. The bridge itself handles ciphertext only and cannot read the
content.

Phase 4: Protocol-agnostic routing


   8.

   The bridge inspects Bob’s DID document to discover service endpoints.
   This may include:



   -

   A DIDComm endpoint (preferred)
   -

   A WebSocket endpoint
   -

   An HTTP/HTTPS endpoint
   -

   Or email as a fallback if no DID endpoint is available



   9.

   The message is delivered using the selected transport


Decentralization emerges here because each DID holder independently
controls their service endpoints. Multiple transport options avoid
single-point dependencies, and fallback mechanisms ensure reliable delivery.

Phase 5: Recipient processing


   10.

   Bob’s DID wallet receives the encrypted message
   11.

   The message is decrypted locally using Bob’s private key
   12.

   The message is presented in Bob’s interface (wallet, agent, or email
   client via plugin)


Decryption occurs only on Bob’s device, not on any intermediary system.


Where privacy could break and how it is prevented

One risk is the bridge becoming a centralized surveillance point if
everyone relied on a single service. The architecture avoids this by
treating the bridge as open-source software, not as a hosted service.
Organizations deploy their own instances, control their own routing tables,
audit the code, and remain independent of external operators.

Another risk is metadata correlation. Even with encrypted content, timing
and volume can reveal patterns. Bridges can mitigate this using message
batching, randomized delays, optional padding to normalize sizes, and
privacy-preserving transports such as Tor or I2P for DIDComm delivery.

A third risk is a centralized mapping database. This is avoided because
mappings exist only within each organization’s infrastructure. There is no
global registry of email-to-DID associations.


What decentralization actually means in this design

Each organization retains sovereign control over its routing tables,
security policies, supported transports, and encryption standards.

Multiple implementations are possible because the system is defined through
standard interfaces. Organizations can use a reference implementation,
build their own, or extend it with custom logic, while remaining
interoperable.

Recipients control which DIDs map to which email addresses, which endpoints
they publish, what transports they accept, and whether they participate at
all.


Addressing your core concern

You noted that it is “quite hard to uphold the promise of privacy and
decentralization.” That concern is valid for centralized service models.

This design is different: it is a protocol implementation, not a service.

Privacy and decentralization arise from localized processing inside each
organization’s infrastructure, end-to-end encryption before messages leave
the bridge, recipient-controlled cryptographic identity and endpoints, and
the absence of any central registry.


Realistic boundaries

We cannot change the fundamental architecture of email. When senders use
external providers, those providers will always see metadata.

What this system provides is end-to-end encryption after the message enters
the recipient organization, full control over identity translation for
domain owners, and a migration path that does not require universal or
immediate adoption.


Discovery model

The bridge serves recipients, not senders.

Bob’s email-to-DID mapping exists only inside his organization’s bridge.
The sender needs only Bob’s email address.

In the DID-to-email direction, if a sender knows Bob’s DID but Bob’s DID
endpoints route through his bridge, the message can be translated to email.
If not, delivery fails, correctly reflecting Bob’s choice not to accept
email delivery.


Practical example

An external partner emails contact@enterprise.com.

The enterprise bridge routes the message to internal DIDs, encrypts it, and
delivers it to internal teams via DIDComm.

Replies are sent as DID messages, translated back into email by the bridge,
and delivered to the external partner.

The partner receives a normal email and is unaware of the DID layer.

The privacy benefit is strongest for the organization and its internal
users, while compatibility with the existing internet is preserved.


Conclusion

Privacy and decentralization are achieved through:


   -

   Distributed deployment, with each organization operating its own bridge
   -

   End-to-end encryption for translated messages
   -

   Recipient-controlled identities and endpoints
   -

   No central mapping or routing authority
   -

   Transparent, auditable implementation

We are not proposing a centralized gateway. We are providing protocol
building blocks that organizations can deploy inside their own security
perimeter, under their own governance and access controls.



Best regards,

Amir Hameed Mir

Sirraya Labs


On Wed, 28 Jan 2026 at 4:48 PM, Jori Lehtinen <lehtinenjori03@gmail.com>
wrote:

> I think that would be extremely valuable. But it also might be quite hard
> to uphold the promise of privacy and decentralization there. If you could
> walk us trough the protocol/process step by step, it would be easier to
> consider how it would work exactly and identify + tackle possible issues.
>
> ke 28.1.2026 klo 13.13 Amir Hameed (amsaalegal@gmail.com) kirjoitti:
>
>> Hi Jori,
>>
>>
>> Yes, conceptually there are two symmetric gateway endpoints. One
>> translates SMTP email into DIDComm messages and delivers them to a DID
>> inbox. The other translates DIDComm messages back into email and delivers
>> them via SMTP.
>>
>>
>> The key value is that one side can use decentralized, cryptographically
>> secure messaging (DIDComm) without requiring the other side to migrate,
>> install anything, or even know about DIDs.
>>
>>
>> This removes the adoption barrier that normally kills new identity and
>> messaging systems, while still enabling privacy, authentication, and
>> decentralization where it is needed.
>>
>>
>>
>> Regards
>> Amir Hameed
>>
>> On Wed, 28 Jan 2026 at 4:40 PM, Jori Lehtinen <lehtinenjori03@gmail.com>
>> wrote:
>>
>>> So two endpoints? One that translates email to did, and another one that
>>> translates did to email? And the value proposition is what? Takes email
>>> message and transforms it to a DIDComm message and delivers it to some kind
>>> of DIDComm inbox and the other way around allows to respond with a DIDComm
>>> message turned in to email and gets translated and delivered to an email
>>> inbox. So if another party wants decentralized and private messaging they
>>> can have that with a person that doesn't want to migrate or doesn't care or
>>> something like this?
>>>
>>> ke 28.1.2026 klo 12.10 Amir Hameed (amsaalegal@gmail.com) kirjoitti:
>>>
>>>> Hi Michael
>>>>
>>>> Thank you for engaging, I don’t have single full architecture diagram
>>>> but I just draw one for you and I am attaching it here , I believe it will
>>>> give you an idea of how bidirectional runtime mapping happens between two
>>>> different identifiers, Have a look then we can dive deep into what goes
>>>> under the hood, there are two mappings happening inside runtime, one is
>>>> header mapping and another is message format mapping.
>>>>
>>>> On Wed, 28 Jan 2026 at 3:26 PM, Michael Herman (Trusted Digital Web) <
>>>> mwherman@parallelspace.net> wrote:
>>>>
>>>>>
>>>>>    1. RE: a bidirectional DID ↔ Email bridge acting as a universal
>>>>>    message router
>>>>>
>>>>>
>>>>>
>>>>> This is confusing because “DID” (an identifier) and “Email” (an email
>>>>> message/system/protocol) are “not of the same type”.
>>>>>
>>>>>
>>>>>
>>>>> For example: DID and Email Address are of the same type (both
>>>>> character string identifiers).
>>>>>
>>>>>
>>>>>
>>>>>    2. RE: translates email messages into DID-native formats
>>>>>
>>>>>
>>>>>
>>>>> What is a “DID-native (email message) format”? …an example?
>>>>>
>>>>>
>>>>>
>>>>> Michael Herman
>>>>>
>>>>> Chief Digital Architect
>>>>>
>>>>> Web 7.0 Foundation / TDW™
>>>>>
>>>>>
>>>>>
>>>>> *From:* Amir Hameed <amsaalegal@gmail.com>
>>>>>
>>>>> *Sent:* Tuesday, January 27, 2026 1:05 PM
>>>>> *To:* Daniel Hardman <daniel.hardman@gmail.com>
>>>>> *Cc:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
>>>>> W3C Credentials CG <public-credentials@w3.org>
>>>>> *Subject:* Re: [Email-to-DID Bridge] Exploring a practical migration
>>>>> path for email infrastructure
>>>>>
>>>>>
>>>>>
>>>>> Hi Michael
>>>>>
>>>>> The core idea of this bridge is to be fully protocol-agnostic. While
>>>>> DIDComm is currently the strongest candidate for DID-native messaging, the
>>>>> design is not limited to it—we have already tested WebSockets and
>>>>> HTTP-based delivery methods as well.
>>>>>
>>>>> The real problem we are addressing is that today there are two types
>>>>> of users: those who prefer communicating via DIDs, and those for whom
>>>>> traditional email is perfectly sufficient. In real-world scenarios such as
>>>>> customer support or enterprise communication, both groups must be able to
>>>>> coexist and communicate seamlessly.
>>>>>
>>>>> This becomes a classic translation problem, similar to human
>>>>> languages. If one person speaks Hindi and another speaks English,
>>>>> communication is only possible through a translator. In the same way, the
>>>>> DID world and the email world require a neutral translation layer.
>>>>>
>>>>> That is what this system provides: a bidirectional DID ↔ Email bridge
>>>>> acting as a universal message router. It maps email addresses to DIDs and
>>>>> translates email messages into DID-native formats (and vice versa) at
>>>>> runtime.
>>>>>
>>>>> Rather than being just a mailbox, it functions as a universal message
>>>>> box, capable of handling both email and DID messages simultaneously. Users
>>>>> remain free to choose how they communicate, while the bridge ensures
>>>>> interoperability underneath.
>>>>>
>>>>> The goal is to enable gradual adoption of decentralized identity
>>>>> without breaking compatibility with the existing, widely-used email
>>>>> ecosystem, while keeping the system open-source and extensible for future
>>>>> protocols.
>>>>>
>>>>> Regards
>>>>>
>>>>> Amir Hameed Mir
>>>>>
>>>>> Sirraya Labs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 27 Jan 2026 at 5:55 PM, Daniel Hardman <
>>>>> daniel.hardman@gmail.com> wrote:
>>>>>
>>>>> email + DIDComm work:
>>>>> https://github.com/decentralized-identity/didcomm-messaging/blob/main/extensions/email_transport/main.md
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2026 at 4:57 PM Michael Herman (Trusted Digital Web) <
>>>>> mwherman@parallelspace.net> wrote:
>>>>>
>>>>> Amir, once you’ve mapped an SMTP email address to a DID, which
>>>>> protocol are you using to complete the email message delivery?  …for
>>>>> example, is it DIDComm?
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Michael Herman
>>>>>
>>>>> Chief Digital Architect
>>>>>
>>>>> Web 7.0™ / TDW™
>>>>>
>>>>>
>>>>>
>>>>> *From:* Amir Hameed <amsaalegal@gmail.com>
>>>>> *Sent:* Sunday, January 25, 2026 12:51 PM
>>>>> *To:* W3C Credentials CG <public-credentials@w3.org>
>>>>> *Subject:* [Email-to-DID Bridge] Exploring a practical migration path
>>>>> for email infrastructure
>>>>>
>>>>>
>>>>>
>>>>> Hello CCG community,
>>>>>
>>>>> I'm writing from Sirraya Labs to share an early-stage but
>>>>> production-tested approach we've been developing: an *Email–DID
>>>>> Router* that bridges traditional email infrastructure with
>>>>> decentralized identity (DID/VC) systems. We're keen to gather feedback,
>>>>> explore alignment with related W3C work, and understand whether this
>>>>> direction resonates with the community’s broader interoperability goals.
>>>>> What we’re exploring
>>>>>
>>>>> The system operates as an enterprise-grade gateway that:
>>>>>
>>>>>    - Maps traditional email addresses (e.g., executive@company.com)
>>>>>    to DIDs (e.g., did:example:alice123)
>>>>>    - Transforms SMTP-based emails into verifiable, identity-aware
>>>>>    messages
>>>>>    - Routes messages using confidence-based logic, security
>>>>>    screening, and configurable policies
>>>>>    - Runs with full auditability and measurable performance (tested
>>>>>    in live environments)
>>>>>
>>>>> Here’s a snapshot from a recent run:
>>>>>
>>>>> text
>>>>>
>>>>> [2026-01-25T11:31:28Z INFO  email_did_gateway] Processing incoming email from chairman@board-of-directors.com to executive@company.com
>>>>>
>>>>> [2026-01-25T11:31:28Z INFO  email_did_gateway] Successfully processed email into DID message: 71259949-4f38-46a1-8c74-c86540ba5917
>>>>>
>>>>> [2026-01-25T11:31:28Z INFO  email_did_router] Processed executive email - Confidence: 0.78, Method: RuleBased
>>>>>
>>>>> Why this matters for DID/VC adoption
>>>>>
>>>>> Email remains the dominant channel for business, institutional, and
>>>>> personal communication. Rather than proposing a disruptive replacement,
>>>>> we’re focused on *building incremental, opt-in bridges* that allow:
>>>>>
>>>>>    1. Gradual migration of trust from SMTP+PKI to DID/VC models
>>>>>    2. Immediate value through better routing, security screening, and
>>>>>    audit capabilities
>>>>>    3. Preservation of existing infrastructure and investment while
>>>>>    enabling verifiable communication
>>>>>
>>>>> We see potential alignment with several W3C efforts—DID Comm, VC-API,
>>>>> identity hubs, and trust spanning protocols—and are keen to explore how
>>>>> this work might complement ongoing standardization.
>>>>> Questions for the community
>>>>>
>>>>> Before we formalize or release anything publicly, we’d value your
>>>>> perspectives on:
>>>>>
>>>>>    - *Use cases* we may have overlooked (enterprise, government,
>>>>>    healthcare, education, etc.)
>>>>>    - *Privacy and compliance considerations* (GDPR, residency,
>>>>>    retention, consent)
>>>>>    - *Mapping lifecycle* (persistence, revocation, recovery,
>>>>>    expiration)
>>>>>    - *Confidence and trust models* suitable for email→DID routing
>>>>>    - *Potential alignment* with existing or emerging W3C
>>>>>    specifications
>>>>>
>>>>> We’re particularly interested in whether this kind of bridge could
>>>>> help accelerate real-world adoption of DID/VC systems in environments where
>>>>> email remains non-negotiable.
>>>>>
>>>>> We’re at the stage of gauging interest and refining the approach based
>>>>> on community feedback. If this resonates, we’d be happy to:
>>>>>
>>>>>    - Share more detailed design notes
>>>>>    - Discuss integration with related CCG work items
>>>>>    - Potentially present in a future CCG call
>>>>>    - Explore collaboration with groups working on interoperability,
>>>>>    trust layers, or migration pathways
>>>>>
>>>>> Our goal is to help build *responsible, incremental bridges*—not to
>>>>> replace email or DIDs, but to enable them to coexist and evolve together.
>>>>>
>>>>> We look forward to your thoughts, critiques, and suggestions.
>>>>>
>>>>> Best regards,
>>>>> Amir Hameed
>>>>> Sirraya Labs
>>>>>
>>>>>