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

Hello Jori,

If DIDs are just a "handshake on top of a handshake," they add no value.
The industry’s failure has been treating DIDs as a marketing layer rather
than an engineering primitive.

Our *Email–DID Router* is not another layer of "conceptual plumbing." It is
a managed bridge designed to solve the two specific problems you
mentioned: *Key
Lifecycle Management* and *Protocol Interoperability.*
1. Why DIDs over existing JOSE/JWT?

You asked what new capability DIDs provide. The answer is *Decoupled Key
Rotation.*

   -

   *The JOSE Problem:* In a standard JWT/JOSE stack, identity is pinned to
   an issuer’s keys (JWKS). If a key is compromised or rotated, every client
   must re-sync with the central authority. Identity is a "leased" service.
   -

   *The DID Capability:* A DID is a *persistent URI for a non-persistent
   key.* It allows the controller (e.g., your zero-knowledge browser agent)
   to rotate keys via an append-only log *without* the verifier ever
   needing to change the identifier they are talking to. It turns identity
   into an *autonomous infrastructure.*

2. Making the Tech "Consumable" (Developer Value Map)

You mentioned that DIDs should be "trivial to use." To illustrate how our
router moves from "implementable" to "consumable," consider the effort
required for a developer to verify a message on your ZK platform:
*Feature* *Implementing Full W3C Resolver* *Using Sirraya Labs Router*
*Code Effort* *300+ lines* (Resolver, Cache, Verification, Crypto libs) *1
line* (Check HTTP/SMTP Header)
*Complexity* Handle DID Methods, JSON-LD, Multibase, & Rotation logs Consume
X-DID-Confidence: 0.95
*Maintenance* Update libraries for every new DID method/spec change Managed
by the gateway; no client-side changes
*Discovery* Build a lookup service for raw DIDs Use existing
executive@company.com handles

*Standard Implementer Experience (The Spec Way):*
JavaScript

// A nightmare of async resolution and crypto-voodooconst doc = await
resolver.resolve("did:example:123");const key = await
ld.expand(doc).getVerificationMethod();const isValid = await
verify(message, key, proof);

*Sirraya Labs Experience (The Consumable Way):*
JavaScript

// Trust as a simple metadata attributeif
(email.headers['X-DID-Confidence'] > 0.75) {
  proceedWithZKClearance();
}

3. Addressing your ZK Use Case

For your "public alias" on a ZK platform, the router provides a *Discovery
Bridge.*

   -

   *The Gap:* Standard ZK proofs are great for verification, but terrible
   for *discovery* (how do I find you to begin with?).
   -

   *The Solution:* The router allows an unknown user to use their existing
   email as a "Discovery Pointer" that resolves to their ZK-compatible DID.
   This prevents backwards-linkability while providing a standard protocol for
   rotation and resolving that peers already understand.

The endgame isn't to replace email or JOSE. It is to provide a *Trust
Spanning Protocol* that allows legacy systems (like email) to interact with
high-privacy systems (like your ZK platform) using a common, verifiable
language.

We’ve optimized this for performance (*1ms–39ms processing*) because we
know that if it’s slow, it’s not infrastructure—it’s just a bottleneck.

Regards,

Amir Hameed

Sirraya Labs

On Sun, 25 Jan 2026 at 03:38, Jori Lehtinen <lehtinenjori03@gmail.com>
wrote:

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