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) 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
>    2.
>
>    Her email client performs a standard DNS/MX lookup for company.org
>    3.
>
>    The message is delivered to 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 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
>
>
>    4.
>
>    The SMTP server invokes bridge.handle_email(message)
>    5.
>
>    The bridge consults its internal routing table:
>
>    bob-executive@company.org → did:web:company.org:bob
>    6.
>
>    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 alone controls and stores this
> mapping inside its own infrastructure.
>
> Phase 3: Message transformation
>
>
>    7.
>
>    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
>
>
>    8.
>
>    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
>
>
>
>    9.
>
>    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
>
>
>    10.
>
>    Bob’s DID wallet receives the encrypted message
>    11.
>
>    The message is decrypted locally using Bob’s private key
>    12.
>
>    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.
>
> 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>
> 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) 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
>>>>>>
>>>>>>