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

Updated diagram…

[cid:image001.jpg@01DC9059.A6208370]

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Sent: Wednesday, January 28, 2026 1:18 PM
To: Jori Lehtinen <lehtinenjori03@gmail.com>; Amir Hameed <amsaalegal@gmail.com>
Cc: Daniel Hardman <daniel.hardman@gmail.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: RE: [Email-to-DID Bridge] Exploring a practical migration path for email infrastructure

Loose-related, at the Web 7.0 Foundation, we’re looking at forking the open-source ZeroTier project and turning it into a DID-native, DIDComm-native router/DID virtual network for DID-native, DIDComm-native apps (aka Neuroplexes).

Michael Herman
Chief Digital Architect
Web 7.0 Foundation

[cid:image004.jpg@01DC9059.9545C920]

From: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>
Sent: Wednesday, January 28, 2026 12:30 PM
To: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>
Cc: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>; W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: [Email-to-DID Bridge] Exploring a practical migration path for email infrastructure

I can totally see it working that way, but how do you deliver the response from Bob's DIDComm client to Alice's email client with end-to-end encryption, wich is obviously the more crucial part here as Bob  is the one that cares about total privacy. I think this can still be a good idea even without e2e encryption guarantee, however if you can solve that part it is always better. An organizations internal messaging can always be "decenralized" by making it centralized to the organization controlled machinery just by self-hosting any regular server software. But as stated I think this can help with "adoption pain" regardless so it is not necessarily a bad idea.

ke 28.1.2026 klo 14.14 Amir Hameed (amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>) kirjoitti:
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<mailto:bob-executive@company.org>
  2.  Her email client performs a standard DNS/MX lookup for company.org<http://company.org>
  3.  The message is delivered to company.org<http://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<http://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

  1.  The SMTP server invokes bridge.handle_email(message)
  2.  The bridge consults its internal routing table:

bob-executive@company.org<mailto:bob-executive@company.org> → did:web:company.org:bob

  1.  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<http://company.org> alone controls and stores this mapping inside its own infrastructure.

Phase 3: Message transformation

  1.  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

  1.  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



  1.  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

  1.  Bob’s DID wallet receives the encrypted message
  2.  The message is decrypted locally using Bob’s private key
  3.  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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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.
[cid:image005.jpg@01DC9059.9545C920]

On Wed, 28 Jan 2026 at 3:26 PM, Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto: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).


  1.  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<mailto:amsaalegal@gmail.com>>
Sent: Tuesday, January 27, 2026 1:05 PM
To: Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>
Cc: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; W3C Credentials CG <public-credentials@w3.org<mailto: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<mailto: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<mailto: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<mailto:amsaalegal@gmail.com>>
Sent: Sunday, January 25, 2026 12:51 PM
To: W3C Credentials CG <public-credentials@w3.org<mailto: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<mailto: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<mailto:chairman@board-of-directors.com> to executive@company.com<mailto: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