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

@Daniel Hardman @Manu

Thank you for the pointers , I will look into this work and see if there is
an overlap and potential way to take it forward together

Regards
Amir

On Tue, 27 Jan 2026 at 6:35 PM, Amir Hameed <amsaalegal@gmail.com> wrote:

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