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

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