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

Hi — thanks again for the detailed explanation of the discovery model and
packet flow. The care you’ve taken around trust boundaries and latency is
very clear, and it’s helpful to see this grounded in operational
measurements.


One clarification that may help frame possible alignment more precisely.


Within the Semantic Agent Communication CG, our scope does not include
defining protocols. What we are working on is intentionally
protocol-independent:


   -

   an agent communication ontology (identity, role, delegation, intent,
   work),
   -

   corresponding agent credentials expressed via DID/VC,
   -

   and an agent interface description layer (an IDL-style model, currently
   explored as a WebIDL extension), describing agent actions, authority, and
   delegation at a semantic boundary rather than a transport boundary.


This work is meant to sit above and across concrete protocols, providing a
shared semantic contract that different transports or runtimes can carry
without reinterpretation.


From that perspective, your Email–DID Router design reads as a very strong
downstream experimentation surface rather than something that needs to live
inside the CG scope. It provides a concrete environment where:


   -

   agent ontology and credentials can be exercised,
   -

   delegation and revocation semantics can be observed in practice,
   -

   and lifecycle and latency characteristics can be measured,

   all without coupling those semantics to a specific transport or protocol
   definition.


In other words, the CG work would remain focused on defining what agent
communication means, while implementations like your router can serve as
protocol-level testbeds that validate those meanings across non-web and
legacy transports.


Framing your work as a downstream design note or implementation report
seems like a clean way to capture this relationship, keeping
responsibilities well separated while still enabling practical
interoperability experiments.


If useful, we’re happy to share the current state of the ontology,
credential categories, and interface models purely as inputs for
experimentation, not as protocol requirements.

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

> Hi Jori, hi Tyson,
>
>
> Thank you both for the thoughtful engagement. It’s encouraging to see this
> work resonate from both the DID/VC security perspective and the emerging
> Semantic Agent Communication workflows.
>
>
> Jori — I particularly appreciated your emphasis on the “stable base point”
> and the placement of the trust boundary. That concern was one of the
> original motivations for our design: preserving the discovery reach of
> email while maintaining cryptographic sovereignty at the DID layer, rather
> than shifting trust into the transport or the gateway.
>
>
> Tyson — your comments on agentic continuity and mixed environments closely
> match the operational assumptions we have been working from (legacy
> transports, heterogeneous agent runtimes, and partial adoption).
>
>
> To address both of your points concretely, I’ll outline two parts of the
> current design: the hashed discovery model (for privacy-preserving
> resolution) and the end-to-end packet flow we are using to keep identity
> resolution non-blocking for agents.
>
>
> 1. Hashed discovery model (PII-minimizing resolution)
>
>
> We agree that requiring raw email identifiers for discovery is unlikely to
> be acceptable in a global, standards-based architecture.
>
>
> Our current approach uses a blind-resolver pattern:
>
>
>    -
>
>    Derivation: The sender derives a deterministic identifier
>
>    H = SHA-256(email || salt)
>    -
>
>    Resolution: The router only receives H and resolves it to a DID
>    document reference.
>    -
>
>    Property: The resolver never observes the plaintext identifier, and
>    the mapping can be rotated or revoked by changing the salt or binding.
>
>
> Functionally, this behaves as a “zero-knowledge directory” for discovery,
> while keeping the email address itself outside the trust boundary of the
> routing layer.
>
>
> We would be very interested in feedback from the group on how this
> compares to other privacy-preserving lookup approaches being discussed.
>
>
> 2. Packet flow and latency envelope (~39 ms)
>
>
> One concern we share is that identity and verification layers should not
> become the pacing bottleneck for agent-to-agent interaction.
>
>
> In our current prototype, the steady-state path looks roughly like:
>
>
>    -
>
>    Ingress (~2 ms): SMTP interception / MTA hook
>    -
>
>    Discovery (~12 ms): Hashed lookup against a global index
>    -
>
>    Validation (~10 ms): Rule-based confidence scoring combining legacy
>    signals (SPF/DKIM, reputation) with DID state
>    -
>
>    Egress (~15 ms): DIDComm wrapping with attached VCs
>
>
> This keeps end-to-end resolution under ~40 ms on commodity infrastructure,
> which has been sufficient for interactive agent workflows in our testing.
>
>
> 3. Possible collaboration path
>
>
> We view this less as a standalone proposal and more as a candidate
> reference implementation for incremental migration from SMTP-centric trust
> models toward DID/VC-anchored, agent-aware communication.
>
>
> If useful to the groups, we would be happy to:
>
>
>    -
>
>    Share a more detailed architectural write-up covering lifecycle
>    management (binding, rotation, revocation), confidence scoring, and
>    delegation flows.
>    -
>
>    Participate in a small implementation pilot or interoperability
>    exercise, using the router as one concrete testbed alongside other
>    approaches.
>
>
> Jori, Tyson — from your perspective, what would be the most appropriate
> way to formalize this within your current CG / WG structures (e.g.,
> implementation report, design note, or a focused task force)?
>
>
> We’d be glad to contribute specifications and empirical findings in
> whatever form is most useful to the process.
>
>
> Best regards,
>
> Amir
>
> Sirraya Labs
>
>
> On Sun, 25 Jan 2026 at 7:46 PM, Jori Lehtinen <lehtinenjori03@gmail.com>
> wrote:
>
>> Hi Amir,
>>
>>
>> I do see the value of using email as a routing surface for DID discovery.
>>
>>
>> Thinking about this in code and structured data, the model I’m forming is
>> that the presented identifier in a first-party application would be the
>> email, and the router or gateway is then used to resolve that email to a
>> DID and verification material.
>>
>>
>> For example, if I receive a message in a first-party app, it could look
>> something like this:
>>
>>
>> {
>>
>> header: {
>>
>> iss: “amsaalegal@gmail.com”,
>>
>> sig: “held1537Xjso153738”,
>>
>> alg: “…”
>>
>> },
>>
>> body: {
>>
>> …
>>
>> }
>>
>> }
>>
>>
>> The application would then use Sierra’s gateway to resolve iss to a DID
>> document and verify the signature.
>>
>>
>> So in this model, the email becomes the presented and verifiable identity
>> handle. What I’m trying to understand is:
>>
>>
>>    1.
>>
>>    Where does the signing key live?
>>
>>    How does the application initially gain access to the private key
>>    corresponding to the email-bound identity, so that the sender user-agent
>>    can sign and recipients user-agents can verify via the resolved DID
>>    document?
>>    2.
>>
>>    Who is authoritative for key state?
>>
>>    If the controller can update their DID document locally, how does the
>>    email router or registry reach eventual consistency so that verifiers
>>    reliably discover the current verification keys? What is the convergence
>>    model between the controller’s state and the router’s cache or registry?
>>    3.
>>
>>    What is the trust boundary?
>>
>>    If the router is sometimes the signer (for legacy email) and
>>    sometimes only a resolver (for wallet or first-party apps), then the system
>>    is operating with two very different security models. I want to understand
>>    precisely where authority lives in each case and how an application
>>    distinguishes between them.
>>
>>
>> I do see the value of email → did router as a stable base point for peer
>> networks to discover DIDs, and then cache them, and verify each other’s
>> actions and identities. What I’m trying to find is a surface I understand
>> and that aligns with my needs. If that can be found, I would genuinely like
>> to use this service.
>>
>> However I still probably would not do it email based because it is
>> personally identifiable information and I would not want to require
>> exposing PII from my users just so they can verify each other.
>>
>> Regards,
>>
>> Jori Lehtinen
>>
>>
>>
>> su 25.1.2026 klo 3.01 ip. Amir Hameed <amsaalegal@gmail.com> kirjoitti:
>>
>>> 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
>>>>>>>
>>>>>>