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

Hi Jori,


Great points. You’ve identified the semantic gap that many bridge designs
gloss over—specifically, the difference between a simple directory or proxy
and a cryptographically grounded identity system. Let me address your
questions directly in the context of our current architecture.


1. Verification logic — “How is the email verified?”

You’re absolutely right that a mapping is meaningless unless it is
verifiable. In our system, the RuleBased method shown in the logs (score:
0.78) is not a static lookup.

Before a mapping transitions to Active, the router initiates a one-time
OIDC4VC challenge. The user must prove control of the email inbox by
completing an OIDC-authenticated flow, after which a verifiable credential
is issued binding the email identifier to the user’s DID.

At runtime, the confidence score is recomputed per message using both the
original OIDC4VC binding and live SPF, DKIM, and DMARC validation of the
incoming message. The system is therefore not simply trusting the email
channel, but continuously verifying the institutional provenance of the
identifier and its cryptographic association.


2. The signing interface — “Where is the pen?”


This is where the architecture is intentionally hybrid.

For standard SMTP users without wallets, the router acts as a managed
signer backed by an enterprise HSM/KMS. It signs only constrained
assertions, such as organizational role, and the trust boundary is explicit
and auditable.

For wallet-enabled or first-party applications, the router is limited to
discovery and transport. The application resolves an email address to a DID
through the router, initiates a DIDComm session (for example, the UUID
shown in the logs), and if a wallet is present the router exits the trust
path entirely. The user performs the signature directly.


In other words, the “pen” can be delegated for legacy compatibility or
remain fully with the user where first-party cryptography is available.


3. Utility for applications — discovery convergence


The primary value to applications is not identity substitution but
discoverability.


DIDs lack a universal discovery layer, which makes peer initiation
impractical in most real deployments. We use email as a discovery pointer
that resolves to a DID. Once resolved, the application can ignore the
router’s confidence score and proceed with a direct cryptographic session
using standard DID, VC, and DIDComm verification.


We are not replacing verifiable identity systems; we are making them
reachable from existing networks.


If this direction seems useful, perhaps we could simply try it out in the
coming weeks to see whether it meaningfully helps in practice.


Our interest would be to experiment first, evaluate the trade-offs
together, and only then consider whether anything here is worth
standardizing.


The motivation behind this work is to reduce vendor lock-in and align with
the original purpose of this community: enabling interoperable,
user-controlled identity infrastructure rather than creating new
proprietary silos.


This has been an internal technical exploration on our side, not a product
pitch. We are not selling anything, and there is no commercial expectation
attached. Sirraya Labs is simply a technology company, and our intent here
is to contribute engineering work that may be useful to the community if it
holds up under scrutiny.


Best regards,

Amir Hameed

Sirraya Labs


On Sun, 25 Jan 2026 at 6:13 PM, Jori Lehtinen <lehtinenjori03@gmail.com>
wrote:

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