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

Hello Sirraya Labs team,


Thank you for sharing this work. The emphasis on incremental, opt-in
bridges aligns closely with our own experience.


In earlier work, we explored a mail-based agent-to-agent protocol that
operates in a very similar design space. One core conclusion from that
effort was that email itself is already a mature, globally deployed context
graph: message threading, headers, organizational roles, historical
interaction patterns, and implicit authority relationships are all encoded
there. From this perspective, the challenge is not to replace email or
introduce a new substrate, but to make this existing context explicit,
verifiable, and operable by agents.


In that model, email functions as a context carrier and migration surface.
DID/VC layers then augment identity, delegation, and accountability without
disrupting SMTP-based workflows. Your gateway approach appears well aligned
with this philosophy.


A few observations from our prior implementation that may be relevant:


   -

   Email ↔ DID mapping is fundamentally a lifecycle concern. Treating the
   association as a verifiable, time-bound assertion—supporting revocation,
   role change, recovery, and expiration—proved more robust than static
   bindings.
   -

   Confidence scoring emerged as a useful abstraction layer between legacy
   email signals (headers, DKIM, behavioral history) and agent-level trust
   decisions. This complemented DIDComm-style messaging rather than
   overlapping with it.
   -

   Auditability and explainability mattered more than cryptographic
   maximalism in enterprise settings. Being able to explain why a message was
   routed, deferred, or escalated was often the decisive adoption factor.


One additional dimension where we see strong potential alignment is
cross-LLM entity context preservation. By anchoring identities, roles, and
delegations in DID/VC, we were able to retain coherent entity context
across different language models and agent runtimes, rather than letting
context fragment at each model boundary. Email’s stable contextual graph,
combined with DID-anchored identity, provided a practical way to maintain
continuity even in heterogeneous LLM environments.


Relatedly, within the Semantic Agent Communication Community Group, we are
currently working on defining:


   -

   agent delegation models,
   -

   verifiable proofs of authority and intent,
   -

   and work / task credentials that allow agents to act, delegate, and be
   audited across organizational and technical boundaries.


Much of this work assumes mixed environments where legacy transports
coexist with agent-native protocols, so your Email–DID Router reads as a
concrete, production-oriented instantiation of many of these concerns.


From a W3C standpoint, this kind of work seems particularly relevant as a
migration and interoperability strategy—helping legacy trust systems evolve
toward verifiable, agent-aware communication without requiring disruptive
transitions or “flag days.”


If helpful, we would be glad to:


   -

   compare notes on mail-based agent semantics,
   -

   discuss confidence and trust models for email→DID routing,
   -

   or explore how this fits best as an implementation report or CG
   discussion rather than a new protocol proposal.

We appreciate you opening this up early for feedback. This feels like the
sort of pragmatic bridge work that can meaningfully accelerate real-world
DID/VC adoption.

Best regards,

Tyson

Amir Hameed <amsaalegal@gmail.com>於 2026年1月25日 週日，下午5:51寫道：

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