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

Somehting like this seems easy enough:

const doc = await resolver.resolve(“did:example:123”);

const key = await ld.expand(doc).getVerificationMethod();

const isValid = await verify(message, key, proof);


If there is a library that implements the latest DID resolution and role
semantics, let me know.


I don’t think email resolution fits my needs, but let’s examine the
mechanics.


For a DID resolved through your router to be meaningful, the email must be
verified at least once on your side.

Then a first-party application would ask for an email from the user, to
resolve a DID document from you, and attempt to verify something.


Where is the interface to sign messages, to assert a verifiable identity
behind a message?

Or is the application only trusting the router’s trust score?


Email can be a good interface for a user to interact with their DID since
it’s familiar, but I don’t see how that extends to be useful for
applications relying on verifiable identity.


Regards,

Jori Lehtinen


su 25.1.2026 klo 1.50 ip. Amir Hameed <amsaalegal@gmail.com> kirjoitti:

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