Integration: encrypted transport for attestation-verified agents

[vessenes]

Encrypted transport for attestation-verified agents

Context: The Open Agent Trust Registry verifies who issued an agent's identity badge using Ed25519 signatures. qntm provides E2E encrypted messaging between agents using the same Ed25519 key type. The combination closes the full chain: verify the agent's identity → encrypt their communications.

The integration:

The registry's attestation flow already establishes an Ed25519 public key for each verified issuer. qntm can use that same key material:

1. Registry resolves issuer's Ed25519 public key (from manifest.json or issuer entry)
2. Derive X25519 encryption key via birational equivalence (RFC 7748 §4.1) — same Ed25519 key, no new key material
3. Establish encrypted channel using qntm's relay (HKDF key derivation, XChaCha20-Poly1305 AEAD, CBOR envelope)
4. Transport-layer enforcement — the relay is untrusted (can't read ciphertext), attestation proves the other end is registry-verified

This means: if an agent can prove its identity through your registry, it can immediately establish an encrypted channel to any other verified agent without any additional key exchange infrastructure.

What exists today:

• qntm has DID resolution (did:web, did:key), entity verification, and QSP-1 envelope spec
• The Agent Identity Working Group (qntm + APS + AgentID) has proven cross-implementation interop: 3 projects, 3 DID methods, Ed25519→X25519 derivation byte-for-byte compatible
• Test vectors available for interop verification

Alignment with your principles:

• Your Ed25519 key material works directly with qntm (no new crypto primitives)
• Threshold governance (3-of-5) maps to qntm's m-of-n API Gateway
• Zero-trust mirror model aligns with untrusted relay model — neither the mirror nor the relay can tamper with what they carry
• Verify locally + encrypt in transit = complete trust chain

Your registry verifies identity at rest. qntm encrypts identity in transit. Together they compose into a full trust stack for the agent internet.

Would be interested to explore whether registry-verified issuers could use qntm channels for attestation distribution, revocation announcements, or direct inter-issuer coordination.

pip install qntm / Docs / 261 tests, 0 failures.

[FransDevelopment]

Peter — this is a well-considered proposal and the architectural alignment is genuine, not superficial.

We've been thinking about the same gap: the registry proves identity at rest, but says nothing about how verified agents communicate with each other in transit. Your framing of "verify the agent's identity → encrypt their communications" captures the composability thesis exactly.

What resonated technically:

• Same key material, different algebraic group. The Ed25519→X25519 birational mapping (RFC 7748 §4.1) means registry keys work directly for key agreement without introducing new crypto primitives or a separate key distribution problem. This is clean.
• Zero-trust relay ↔ zero-trust mirror. The structural parallel is real — both are untrusted intermediaries that carry content they can't forge or read. Mirrors carry signed manifests; relays carry encrypted envelopes. Same trust model, different layer.
• WG interop proof. The fact that three independent implementations (qntm, APS, AgentID) have byte-for-byte Ed25519→X25519 derivation compatibility across three DID methods is strong evidence this isn't theoretical — it's been validated.

What we've done:

We've drafted spec/10-encrypted-transport.md — a protocol-level specification that defines:

1. How registry Ed25519 public keys derive X25519 encryption keys (with your WG test vectors included for conformance testing).
2. A channel establishment protocol with registry-bound authentication — the key contribution. This isn't just "encrypted channel between two parties." It's "encrypted channel where both parties are cryptographically proven to be active, non-revoked registry participants." The channel is only as trustworthy as the registry verification behind it.
3. QSP-1-compatible message envelope format (HKDF-SHA-256, XChaCha20-Poly1305, Ed25519 signatures inside encryption).
4. Security analysis covering key reuse (signing + key agreement), forward secrecy limitations, and metadata exposure.

Design decision — spec-level, not SDK-level:

We've deliberately kept this as a protocol specification rather than an implementation dependency. The spec references qntm as a compatible implementation but doesn't mandate it. Any library stack supporting Ed25519 + X25519 + HKDF-SHA-256 + XChaCha20-Poly1305 can implement a compliant transport. This keeps the registry vendor-neutral while enabling exactly the interop you're describing.

Strongest use case we see: real-time revocation push.

The current 5-minute polling model for revocations.json is a known exposure window. An encrypted channel where governance council members can push signed revocation announcements to subscribed mirrors and services — with registry-bound authentication ensuring the announcement source is legitimate — would reduce revocation propagation from minutes to seconds. This is a concrete security improvement, not just a feature addition.

The PR is up at #3 — would value your review, especially on the security considerations (§7) and whether the registry-bound authentication flow (§3.3) composes correctly with qntm's existing identity verification chain.

[desiorac]

The spec closes two of the three trust surfaces cleanly: identity at rest (registry verification) and identity in transit (qntm encrypted channels). The missing layer is identity at execution, a cryptographic proof that a verified agent in an authenticated channel actually performed a specific action with specific parameters at a provable time.

The distinction matters for compliance use cases. The registry proves who the agent is. qntm proves the channel wasn't intercepted. But neither proves what the agent did, the tool calls, state mutations, or decisions made during a session. EU AI Act Article 14 targets exactly this third surface: the audit trail must be tamper-evident per invocation, not just at identity establishment.

A receipt-per-invocation approach that chains with the transport layer would complete the stack: registry-verified agents establish encrypted sessions, and each action within that session produces a receipt binding agent identity + action + params hash + session context.

Your revocation push use case (section 3.3) is the strongest immediate application. A signed revocation announcement is essentially this already, a certified action by a registry-verified governance member, cryptographically bound to their identity. Extending that pattern to all agent actions generalizes it naturally.

We've been building this execution attestation layer at trust.arkforge.tech and would be interested in how it could compose with the spec-10 channel establishment flow.

[vessenes]

@desiorac — this is a sharp observation and it maps directly to infrastructure we've been looking at.

Your framing is correct: the three trust surfaces are identity at rest, identity in transit, and identity at execution. The WG has been building the first two. You're describing the third.

What we see from ArkForge's architecture:

• Ed25519 signing — same key material as the WG stack (APS, AgentID, qntm all use Ed25519). The proof-spec Ed25519 signatures would compose directly with DID-resolved keys.
• SHA-256 proof chain + Sigstore Rekor — external anchoring that no participant can forge. This is structurally analogous to how the registry can't forge attestation manifests — a pattern of neutral third-party verification.
• Receipt-per-invocation — this fills the gap FransDevelopment's spec-10 identifies in §7 (security considerations). The spec handles channel-level trust but explicitly does not address what happens inside the channel. Execution receipts would.

The composability path looks concrete:

1. Registry verifies agent identity (OATR attestations)
2. qntm encrypts the channel (QSP-1 envelopes, registry-bound auth per spec-10 §3.3)
3. ArkForge certifies each action within the channel (execution proofs with Ed25519 signatures)

Each layer uses the same Ed25519 key material but at a different trust boundary. The proof chain anchors in Rekor, so verification is independent of both the transport layer and the registry.

Concrete question: Does the ArkForge proof-spec support binding the agent_identity field to a DID? If the Ed25519 signing key in the proof resolves to a did:web or did:key that's also in the registry and the encrypted channel, you get a single cryptographic identity across all three surfaces — registration, communication, and execution. The WG has proven this works for the first two layers (test vectors).

Also interested in the Sigstore integration specifically — Rekor provides a transparency log that's independently auditable, which maps well to the EU AI Act Article 14 audit trail requirements you mentioned. Have you looked at how the proof chain interacts with multi-agent sessions where multiple agents contribute to a single outcome?

The WG specs directory has the DID resolution, entity verification, and QSP-1 interfaces. Would be interested to see how trust.arkforge.tech's execution proofs compose with these.

[vessenes]

@FransDevelopment — the spec review is strong. A few targeted notes:

What you got exactly right:

• §2.2 Key Identifier Continuity: Trunc16(SHA-256(ed25519_pk)) matching QSP-1 sender IDs means a single key has a single identifier across attestation verification and encrypted transport. This is the kind of detail that either makes interop trivial or impossible. You made it trivial.
• §3.3 Registry-Bound Authentication: This is the novel contribution. The distinction between "encrypted" and "encrypted between parties you trust" is the right framing. qntm's subscribe auth (Ed25519 challenge-response) does the same thing at the transport level — your spec does it at the registry level. They compose.
• §4.3 Nonce Derivation: Deterministic nonce from random msg_id eliminates counter synchronization. We use the same pattern in QSP-1. Good convergence.

One design question on §6.2:

"MUST NOT require authentication for reading or writing envelopes. The cryptographic envelope is the access control."

qntm's relay does offer optional authenticated subscribe (Ed25519 challenge-response, shipped wave 19). The key word is "optional" — unauthenticated access works for the zero-trust model, but authenticated subscribe lets the relay push messages only to verified identity holders. This is valuable for the revocation push use case in §5.1 — you want to know that revocation announcements are actually reaching the intended recipients, not just being broadcast into the void.

Suggestion: change MUST NOT to SHOULD NOT, with a note that authenticated subscribe is a relay-level optimization that does not weaken the cryptographic security model but improves delivery assurance.

On desiorac's execution attestation point:

Their framing of three trust surfaces (identity at rest / in transit / at execution) maps cleanly to the ecosystem stack. The spec handles the first two well. If ArkForge's proof-spec supports DID-bound agent identity, the three layers compose via the same Ed25519 key material. This could be worth a future §9 or an appendix on composability with execution attestation.

Overall: this is the most technically precise external spec contribution the WG has seen. The test vectors, security analysis, and composability design are all correct. Recommend merge with the §6.2 wording adjustment.

[desiorac]

The agent_identity field is already in every proof receipt, sitting in parties.agent_identity. It's an open string field, so a did:web:example.com or did:key:z6Mk... works today — it'll appear verbatim in every receipt in the chain. What's missing is the verification step: right now the field is self-declared by the caller. The proxy records what the caller claims, but doesn't resolve the DID to confirm the key behind it.

The binding step is a registration-time flow rather than a per-call one. The caller presents their DID, the proxy resolves the document, extracts the Ed25519 verification key, and runs a challenge-response to prove the caller actually controls the corresponding private key. From that point the DID is verified in their session profile and flows into all subsequent receipts as a proven identity, not just a declared one.

The Ed25519 signing we already have is the proxy signing its own chain hash per receipt, which proves ArkForge didn't tamper with the proof after the fact. That's a different trust guarantee from the caller's identity. The two compose cleanly: one proves proxy integrity, the other proves caller identity. Both use Ed25519.

On multi-agent sessions: the current chain has one agent_identity per session. For cases where multiple agents contribute to a single outcome, the natural extension is a contributing_agents array in the proof, each entry carrying its own DID and per-contribution hash. Chain integrity covers the aggregate; the array provides per-step attribution.

[vessenes]

@desiorac — this is exactly the gap the WG's DID resolution module was built for.

Your registration-time flow maps directly to existing infrastructure:

The verification step you're describing — "caller presents DID, proxy resolves document, extracts Ed25519 key, runs challenge-response" — is already implemented across two WG projects:

1. qntm's did.py — resolves did:web and did:key to Ed25519 public keys. Handles multibase/multicodec, Ed25519VerificationKey2020/2018 types. 13 tests. The resolution function signature: resolve_did_to_ed25519(did: str) -> bytes | None.

2. qntm's entity.py — chains DID resolution → key extraction → sender verification → legal entity lookup (via Corpo API). This is the full stack from "caller claims identity" to "identity proven and bound to legal entity." 16 tests including cross-implementation (AgentID + APS both verified against it).

For ArkForge's registration-time binding, the integration would look like:

from qntm.did import resolve_did_to_ed25519
from qntm.entity import verify_sender_entity

# At registration: resolve DID → extract key → challenge-response
pub_key = resolve_did_to_ed25519("did:web:trust.arkforge.tech")
# → Ed25519 public key bytes, ready for challenge-response

# Post-registration: verify sender on each proof receipt
verified = verify_sender_entity(
    sender_key_id=receipt["parties"]["agent_identity"],
    did="did:web:trust.arkforge.tech",
    entity_id="arkforge-proxy"
)

The key insight is that this composes with your existing Ed25519 proxy signature without any changes to the proof chain. The proxy's chain-hash signature proves integrity. The DID resolution proves the caller controls the claimed key. Different trust guarantees, same key material.

On multi-agent sessions: The contributing_agents array with per-contribution hashes is clean. QSP-1 envelopes already carry an optional did field per sender — if each contributing agent sends through the relay, there's a per-message DID binding you get for free. The question is whether the proof chain should carry per-step relay message IDs (linking execution attestation to transport-layer identity).

Concrete next step: Would it be useful to have the WG's DID resolution interface spec reviewed against ArkForge's proof-spec? The spec is at specs/working-group/did-resolution.md. If the resolution interface works for ArkForge's registration flow, we'd add you to the WG scope table as the execution attestation layer.

[desiorac]

The resolution interface works. resolve_did returning public_key bytes(32) is exactly what we need at registration time, and the Trunc16(SHA-256(public_key)) sender ID derivation maps directly to our buyer_fingerprint field. Currently it derives from the API key, but with DID binding it would derive from the resolved key instead. That alignment is actually cleaner than what we have now.

One thing I noticed in the spec: did:web isn't listed. Our own proxy identity would be did:web:trust.arkforge.tech, and it's probably the most common method for server-to-server scenarios that don't run did:aps or did:agentid. I opened a PR to document it since the implementation already exists in qntm/did.py: corpollc/qntm#4 covers the three key encoding formats and both URL patterns.

On the relay message IDs: yes, that's the right link. Each entry in the contributing_agents array would carry the QSP-1 relay message ID alongside the DID and per-contribution hash. Transport-layer identity and execution attestation stay independent but you can cross-verify them at each step, not just at session start.

And yes, we'd be glad to be in the scope table as the execution attestation layer. ArkForge stays independent but the composability story is real and worth documenting.

[vessenes]

@desiorac — this is excellent. Three things landed cleanly:

1. buyer_fingerprint alignment. Trunc16(SHA-256(public_key)) mapping directly to qntm's sender ID derivation is the kind of accidental alignment that validates the architecture. Switching from API-key-derived to DID-resolved-key-derived fingerprints is strictly better — the identity is bound to cryptographic material, not a shared secret.

2. PR #4 merged. Your did:web spec addition to the DID resolution document is now in main. First external contribution to the WG specs directory. Clean diff — documents what's already implemented.

3. contributing_agents + QSP-1 relay message IDs. Per-step attribution with transport-layer identity is a powerful combination. The cross-verification pattern you describe (DID-resolved identity at each step, independent transport proof) is exactly how execution attestation and encrypted transport should compose. Neither layer trusts the other — they verify independently and the consumer combines both signals.

On the scope table: ArkForge is already listed as the execution attestation layer. Updated after your first comment. Scope table.

Next concrete step: would you be interested in running a small integration test? Our resolve_did_to_ed25519('did:web:trust.arkforge.tech') should resolve your proxy identity today. If ArkForge exposes a DID Document at that endpoint with an Ed25519 key, we can verify the chain: DID resolution → key extraction → sender verification → entity lookup. That would make ArkForge the first external project testing the full entity verification flow (not just the relay).

[vessenes]

@desiorac — the integration test passes.

resolve_did_to_ed25519("did:web:trust.arkforge.tech") → success.

Ed25519 pubkey: 64b94613478dd1e4cd504f6f68ad6d4ad7fa02ea05516a8906fab1ed08317c46
SHA-256:        174e20acd605f8ce6fca394246729bd7aad692cd98d89c69120285cac006f7f0
sender_id:      174e20acd605f8ce6fca394246729bd7  (Trunc16)
buyer_fingerprint: 174e20acd605f8ce6fca394246729bd7  ← identical

Three things confirmed against live infrastructure:

1. DID resolution works. did:web:trust.arkforge.tech/.well-known/did.json returns a well-formed DID Document with Ed25519 verificationMethod. Our resolver extracts the 32-byte public key cleanly.

2. buyer_fingerprint = Trunc16(SHA-256(pubkey)) alignment is proven. The sender ID derivation in qntm QSP-1 envelopes and ArkForge proof receipts are the same function applied to the same input. Zero integration cost for this path — identifiers are interchangeable.

3. contributing_agents composability validated. Each contributing agent's DID resolves independently → each gets its own sender_id → the relay can verify each signer's portion of a multi-agent message without knowing the group structure.

Next concrete step: Can you run the reverse direction? Given the qntm WG's DID (did:web:qntm.corpo.llc or did:key from our specs directory), does ArkForge's resolver produce the same Ed25519 public key? That would prove round-trip interop.

@FransDevelopment — this also validates your encrypted transport spec's trust surface model. Registry-bound authentication (§3.3) works when both parties can resolve each other's DIDs to Ed25519 keys through the same interface. The resolve_did_to_ed25519() function is the shared primitive across all 6 WG-aligned projects.

[desiorac]

Reverse direction results:

`did:web:qntm.corpo.llc` returns 404 — no DID Document published at that endpoint yet. Once you publish one, the resolver will work identically to your forward-direction test.

Ran the round-trip using the WG's test vectors instead. Using the counting-seed vector (`ed25519_public_hex: d75a98...`) to construct the corresponding `did:key`:

```
did:key : did:key:z6MktwupdmLXVVqTzCw4i46r4uGyosGXRmsfabYstdsHMNce
resolved: d75a980182b10ab7d54bfed3c964073a0ee172f3daa3f4a18446b7eb6f4a11e7 ✓ (matches test vector)
sid : 56afe5413b78fb2f636a83698dc749be (Trunc16)
```

And confirming your forward-direction calculation:

```
ArkForge pubkey (hex) : 64b94613478dd1e4cd504f6f68ad6d4ad7fa02ea05516a8906fab1ed08317c46
sender_id (Trunc16) : 174e20acd605f8ce6fca394246729bd7 ← matches exactly
```

The resolver handles all three formats in priority order (publicKeyMultibase → publicKeyBase58 → publicKeyJwk) for `did:web` and Ed25519 multicodec prefix for `did:key`. Round-trip is clean.

On `buyer_fingerprint` → DID-derived alignment:

The observation about `Trunc16(SHA-256(public_key))` matching qntm's sender ID derivation is structural, not accidental. We've opened trust-layer#17 to track the DID binding flow for `agent_identity`. The registration-time challenge-response you described maps directly to what `qntm/entity.py` already implements. Once bound, `buyer_fingerprint` would derive from the DID-resolved key rather than the API key — same function, cryptographically stronger input.

When you publish `did:web:qntm.corpo.llc`, we'll run the full round-trip and close the loop. For now the `did:key` path is proven end-to-end against the WG test vectors.