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