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

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