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

Hi jori

You’re  right that Bob→Alice cannot be true E2E without Alice participating
cryptographically. We intentionally accept this in Phase 1 to avoid
breaking compatibility.


The design secures the recipient side immediately (which is where
organizations face the highest risk), while creating a clean upgrade path
to bridge-to-bridge E2E as adoption grows.


In other words: we optimize for deployability first, and asymptotically
approach full decentralization and E2E as the network evolves.


We think small steps actually help with breaking anything and it’s a well
thought out approach to on ramp


Regards

Amir Hameed



On Wed, 28 Jan 2026 at 6:00 PM, Jori Lehtinen <lehtinenjori03@gmail.com>
wrote:

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