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

On Wed, 28 Jan 2026 at 6:56 PM, Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> Updated diagram…
>
>
>
>
>
> *From:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Sent:* Wednesday, January 28, 2026 1:18 PM
> *To:* Jori Lehtinen <lehtinenjori03@gmail.com>; Amir Hameed <
> amsaalegal@gmail.com>
> *Cc:* Daniel Hardman <daniel.hardman@gmail.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* RE: [Email-to-DID Bridge] Exploring a practical migration path
> for email infrastructure
>
>
>
> Loose-related, at the Web 7.0 Foundation, we’re looking at forking the
> open-source ZeroTier project and turning it into a DID-native,
> DIDComm-native router/DID virtual network for DID-native, DIDComm-native
> apps (aka Neuroplexes).
>
>
>
> Michael Herman
>
> Chief Digital Architect
>
> Web 7.0 Foundation
>
>
>
>
>
> *From:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Sent:* Wednesday, January 28, 2026 12:30 PM
> *To:* Amir Hameed <amsaalegal@gmail.com>
> *Cc:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> Daniel Hardman <daniel.hardman@gmail.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* 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
>
>