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

Hi,


My first question is: what is the endgame here?


Right now this looks like yet another handshake layered on top of existing
handshakes.

Email is already identity-aware. It already has verification, routing, and
trust semantics.


Second: the #1 driver of adoption is immediate developer value.

If you want DID-based authentication to be used, it must be:

• trivial to use a registry

• trivial to write software in the controller role

• trivial to write software in the verifier role

• backed by simple SDKs

• integrated into host platforms


After scanning the specs, the only fundamental difference from JOSE seems
to be:


• append-only, hash-linked rotation history

• distributed, eventually consistent resolution


Those are meaningful, but they are not communicated as such.

Right now the messaging is abstract and marketing-heavy, and byrocratic.


You need to clearly state what new capability DIDs provide over existing
cryptographic stacks, and why a developer should care today.


And then make the tech consumable, not “implementable.”


The fastest path to real adoption is:


• native Web APIs

• first-class support in cloud/BaaS platforms

• resolvers and registries as managed services

• SDKs that feel like JWT libraries, not specs


Until then, DIDs will remain conceptual plumbing rather than practical
infrastructure.


In summary:


• Explain the concrete value over existing systems

• Put the technology where developers already are


For me personally, the value I see from DIDs is that on my zero-knowledge
platform an unknown user can make a genesis event to publish a “public
alias” that peers and my service can verify. I could do it in other ways,
but standardized rotation and protocol semantics make me gravitate toward a
DID here if possible.


So depending on what market (of developers) DIDs are meant for, talk about
what they solve exactly, because things already get cryptographically
verified and authenticated, why do these make it better?


For me, in the privacy-preserving space, it is a way branching a separate
identity as a “public alias” that can only be controlled when the private
key is discovered through zero-knowledge clearance. Peers and my own
service can then use it to verify things, and there is a standard protocol
for rotation and resolving. So controller for me would always be hosted by
the browser. Both other browsers and servers might want to verify and my
server would host the registry/resolvers. And local caches may be temporary
hosts.


And also the possibility of the ’public alias’ DID pointing to a hosted
public wrap key that can be used to initiate messaging to the ’public
alias’ by creating an ephemeral symmetric key, encrypting the message, and
wrapping the key. So yes, for me it is a convenient way to achieve
verifiable public discovery on a zero-knowledge platform.


And ’public alias’ because I want to avoid backwards linkable surface
between zero-knowledge resources and an identifier communicating with
others.


Regards,

Jori Lehtinen


su 25.1.2026 klo 11.53 ap. Amir Hameed <amsaalegal@gmail.com> kirjoitti:

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