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

Hey All,

Have a look at our demo run of Universal DID Native Addressing CGs
implementation on a local wifi, looking forward to feedback, comments and
suggestions.

On Wed, 28 Jan 2026 at 05:34, Amir Hameed <amsaalegal@gmail.com> wrote:

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