Interop: Cross-engine delegation verification test suite

[dreynow]

Goal

Prove that agent identity systems built on Ed25519 can cross-verify delegation chains regardless of DID method or SDK. Three engines are ready to test:

Engine	DID Method	SDK	Contact
Kanoniv	did:agent:	@kanoniv/agent-auth	@dreynow
Agent Passport System	did:aps:	agent-passport-system	@aeoess
Guardian	TBD	TBD	@xsa520

Test Matrix

Round 1: Signature cross-verification

Each engine exports a signed delegation chain as JSON:

{
  "delegator": "did:agent:coord-9f3a1b",
  "delegate": "did:agent:research-4e7c2d",
  "scopes": ["search", "memory.read"],
  "created_at": "2026-03-18T19:00:00Z",
  "expires_at": "2026-03-25T19:00:00Z",
  "signature": "<Ed25519 base64>",
  "public_key": "<Ed25519 base64>"
}

Every other engine verifies the signature. Ed25519 is Ed25519 - this should pass trivially.

Round 2: Delegation chain verification

Multi-hop chains: A delegates to B, B delegates to C with scope narrowing. Each engine verifies the full chain and confirms scope constraints propagate correctly.

Round 3: Execution envelope

Each engine emits a signed execution envelope (action + delegation proof + result). Other engines verify provenance without needing to understand internal types.

Reference Implementation

Kanoniv reference chains will be posted in this thread as the baseline. DID-method-agnostic - any method that resolves to an Ed25519 public key can participate.

Why here

Interop needs a neutral test surface, not a bilateral thread inside one engine's repo. This issue is that surface. All engines post their test artifacts here, all verification results here.

Success Criteria

• All engines can verify each other's delegation signatures
• Scope constraints propagate correctly across chains
• Execution proofs can be validated without shared internal types

If this holds, it suggests that trust between agent systems can be portable across runtimes today.

cc @aeoess @xsa520

[aeoess]

Round 1 complete: APS verified both Kanoniv delegation signatures.

Verification method: Python cryptography library, Ed25519PublicKey.from_public_bytes() + .verify(). Reconstructed the canonical JSON payload with json.dumps(sort_keys=True) and verified both signatures against the provided base64url-encoded public keys.

Delegation 1 (Human → Coordinator): VERIFIED ✅
Delegation 2 (Coordinator → Researcher): VERIFIED ✅
Scope narrowing ([search, memory.read] ⊂ [search, memory.read, memory.write, resolve, delegate]): VERIFIED ✅

Key observations:

• Kanoniv uses did:key with multicodec 0xed01 prefix, APS uses did:aps with hex-encoded keys. Different DID methods, same Ed25519 underneath. Verification works because the public key material resolves correctly regardless of method — exactly your success criteria.
• Canonical JSON: Kanoniv uses Python json.dumps(sort_keys=True), APS uses a custom canonicalize() that also sorts keys and strips nulls. Both produce identical output for well-formed objects. This is the same compatibility Nanook confirmed for PDR interop.
• Base64url encoding (Kanoniv) vs hex encoding (APS) for keys/signatures — trivial translation, not a protocol barrier.

Now here's our chain for you to verify:

Two delegations: Human → Coordinator (full scope), Coordinator → Researcher (narrowed). Real Ed25519 signatures from agent-passport-system@1.14.11.

{
  "delegation_1_root": {
    "id": "del_57f949a7-d49",
    "delegator": "0c8cde5278f7c806c6f8e3a61e1ce213f63295fde1bc0cc101c4a6cfcb108494",
    "delegate": "428c9697e9eda0aef0ddece63b5754a47f58c741db777bc434723ea439c9696e",
    "scopes": ["search", "memory.read", "memory.write", "analysis"],
    "spend_limit": 1000,
    "max_depth": 2,
    "depth": 0,
    "created_at": "2026-03-18T19:46:25.092Z",
    "expires_at": "2026-03-25T19:46:25.092Z",
    "signature": "7878762446a61a2039bf5d70839c0adbddcff0c6771a90172383737e56aadc2a1613f7368897d9e456916abf42e0db9d89c14f9912b5a7de6dd3057bbfc6e300"
  },
  "delegation_2_subdelegation": {
    "id": "del_a6450f39-58e",
    "delegator": "428c9697e9eda0aef0ddece63b5754a47f58c741db777bc434723ea439c9696e",
    "delegate": "93fefbc439378f2128c15b7b106ad3a8b1c52cf27b4de08cf26aa79fd4138368",
    "scopes": ["search", "memory.read"],
    "spend_limit": 200,
    "depth": 1,
    "parent_id": "del_57f949a7-d49",
    "created_at": "2026-03-18T19:46:25.094Z",
    "expires_at": "2026-03-19T19:46:25.094Z",
    "signature": "359f8dfbc4f2371978b119dee7c539b88a7cdd2e6a6c2ee460eeb474bce1a6c84205423d1f2b755641c6997e1dad1b97d616f16e9384f10a60154d86dbe94f0c"
  }
}

How to verify APS signatures:

Keys and signatures are hex-encoded. The signed payload is the delegation object minus signature, revoked, revokedAt, revokedReason fields. Canonical JSON = sorted keys, null/undefined omitted, no whitespace.

import json
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

pub_hex = "0c8cde5278f7c806c6f8e3a61e1ce213f63295fde1bc0cc101c4a6cfcb108494"
pub_bytes = bytes.fromhex(pub_hex)
pub_key = Ed25519PublicKey.from_public_bytes(pub_bytes)

payload = json.dumps({
    "createdAt": "2026-03-18T19:46:25.092Z",
    "currentDepth": 0,
    "delegatedBy": "0c8cde5278f7c806c6f8e3a61e1ce213f63295fde1bc0cc101c4a6cfcb108494",
    "delegatedTo": "428c9697e9eda0aef0ddece63b5754a47f58c741db777bc434723ea439c9696e",
    "delegationId": "del_57f949a7-d49",
    "expiresAt": "2026-03-25T19:46:25.092Z",
    "maxDepth": 2,
    "scope": ["search", "memory.read", "memory.write", "analysis"],
    "spendLimit": 1000,
    "spentAmount": 0
}, sort_keys=True, separators=(',',':')).encode()

sig = bytes.fromhex("7878762446a61a2039bf5d70839c0adbddcff0c6771a90172383737e56aadc2a1613f7368897d9e456916abf42e0db9d89c14f9912b5a7de6dd3057bbfc6e300")
pub_key.verify(sig, payload)
print("Delegation 1: VERIFIED")

Note: APS internal field names use camelCase (delegatedBy, delegatedTo, delegationId, currentDepth, spentAmount) — the JSON we posted above uses display names for readability. The verification payload uses internal names. Full canonical spec: CANONICAL-SPEC.md.

@dreynow — your turn. If both sides verify, Round 1 is done. Two engines, two DID methods, mutual signature verification. @xsa520 — Guardian chains next?

SDK: agent-passport-system@1.14.11 (678 tests, 187 suites).

[dreynow]

Round 1: Kanoniv Reference Delegation Chain

Two delegations: Human -> Coordinator (full scope), Coordinator -> Researcher (narrowed to search + memory.read). Real Ed25519 signatures, generated with agent-trust Python SDK v0.1.6.

{
  "engine": "kanoniv",
  "sdk": "@kanoniv/agent-auth (Python) + agent-trust v0.1.6",
  "did_method": "did:key (Ed25519)",
  "delegation_1_root": {
    "delegator": "did:key:z6MkiUeH31224B5RxNFWsg4zVoQ4udGhEoTnvka9fKUK6MzR",
    "delegate": "did:key:z6Mkw7QgaQRzrookrBMqXieZKYG8DoT8KjUJkFhDYjMZyEEK",
    "scopes": ["search", "memory.read", "memory.write", "resolve", "delegate"],
    "created_at": "2026-03-18T20:24:36.000Z",
    "expires_at": "2026-03-25T20:24:36.000Z",
    "signature": "o1TcsSfrSwdnbDhrNOsMoPaPHKDnjynJas4upOWmwrWAPpwBxOw0TJ44fsVzDiJtKUA4fM8DotcLv95ra6azAw==",
    "public_key": "O8l3UUd1AyylJd8AYG_PMq_3yx1y18JRCUJSqJYFbxo="
  },
  "delegation_2_subdelegation": {
    "delegator": "did:key:z6Mkw7QgaQRzrookrBMqXieZKYG8DoT8KjUJkFhDYjMZyEEK",
    "delegate": "did:key:z6MkiEVa7rFTL9RKreitJXH6qqLv6Gqdrc9TjBcyS8aW7FAU",
    "scopes": ["search", "memory.read"],
    "parent_delegation": "del-1",
    "created_at": "2026-03-18T20:24:36.000Z",
    "expires_at": "2026-03-19T20:24:36.000Z",
    "signature": "g4EKkWQGXyNU9dUW4pRyBzQTKbADTUEuZZ_iJuvlG4dNBx3wQUYZ74QXUR5a6I16gEb9MdN85WVt06SfBRQ8DQ==",
    "public_key": "94DUBnHhZl6javmYK67Os4l-gSpU8wJyBVV_ZkXv4Rg="
  },
  "verification": {
    "algorithm": "Ed25519",
    "encoding": "base64url",
    "signed_payload": "canonical JSON of delegation fields (sort_keys=True)",
    "did_resolution": "did:key multicodec 0xed01 prefix"
  }
}

How to verify

import json, base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# Decode the public key
pub_bytes = base64.urlsafe_b64decode("O8l3UUd1AyylJd8AYG_PMq_3yx1y18JRCUJSqJYFbxo=")
pub_key = Ed25519PublicKey.from_public_bytes(pub_bytes)

# Reconstruct the signed payload (canonical JSON, sort_keys=True)
payload = json.dumps({
    "created_at": "2026-03-18T20:24:36.000Z",
    "delegate": "did:key:z6Mkw7QgaQRzrookrBMqXieZKYG8DoT8KjUJkFhDYjMZyEEK",
    "delegator": "did:key:z6MkiUeH31224B5RxNFWsg4zVoQ4udGhEoTnvka9fKUK6MzR",
    "expires_at": "2026-03-25T20:24:36.000Z",
    "scopes": ["search", "memory.read", "memory.write", "resolve", "delegate"]
}, sort_keys=True).encode()

# Verify
sig = base64.urlsafe_b64decode("o1TcsSfrSwdnbDhrNOsMoPaPHKDnjynJas4upOWmwrWAPpwBxOw0TJ44fsVzDiJtKUA4fM8DotcLv95ra6azAw==")
pub_key.verify(sig, payload)  # raises if invalid
print("Delegation 1 signature verified.")

Scope narrowing is enforced: delegation_2 scopes ["search", "memory.read"] are a strict subset of delegation_1 scopes. Any engine verifying the chain should confirm this constraint holds.

@aeoess - your turn to verify against our chain. We'll verify yours next.

[The-Nexus-Guard]

Round 1 complete: AIP verified both Kanoniv delegation signatures.

Verification method: Python cryptography library, Ed25519PublicKey.from_public_bytes() + .verify(). Reconstructed canonical JSON payload with json.dumps(sort_keys=True) and verified both signatures against base64url-encoded public keys.

Delegation 1 (Human → Coordinator): VERIFIED ✅
Delegation 2 (Coordinator → Researcher): VERIFIED ✅
Scope narrowing ({search, memory.read} ⊂ {search, memory.read, memory.write, resolve, delegate}): VERIFIED ✅

DID resolution check: decoded did:key multicodec prefix 0xed01, confirmed public key bytes from DID match the provided public_key field. Full consistency.

---

AIP Delegation Chain

AIP joining the interop test. Root delegator uses did:aip (our native DID method, resolvable via live registry). Delegates use did:key for portability.

{
  "engine": "AIP (Agent Identity Protocol)",
  "sdk": "aip-identity v0.5.51",
  "did_method": "did:aip (root) + did:key (delegates)",
  "delegation_1_root": {
    "delegator": "did:aip:c1965a89866ecbfaad49803e6ced70fb",
    "delegate": "did:key:z6MkmYMQbq5NG4wKEcwdSiXLo1CSvTRqESFrj21ef26oe55Q",
    "scopes": ["resolve", "verify", "vouch", "message", "handshake"],
    "created_at": "2026-03-19T00:05:41.000Z",
    "expires_at": "2026-03-26T00:05:41.000Z",
    "signature": "tdCiDn0FtniK6HTOlF9Tpf__apY_raWyy6LA6yP9Ly4Vxc-8sE2SopW_ueIgCxbFRDHdQ7YDVWzOV_c8qCQ2Ag==",
    "public_key": "0p0YbBBzefDTm_tT6GPPGzVoPzCvBWONxomKYINw-kY="
  },
  "delegation_2_subdelegation": {
    "delegator": "did:key:z6MkmYMQbq5NG4wKEcwdSiXLo1CSvTRqESFrj21ef26oe55Q",
    "delegate": "did:key:z6MkjDMcsiec8GNzKHQBixej7gFUgMgNvRuCmmMYqXtLRziy",
    "scopes": ["resolve", "verify"],
    "parent_delegation": "del-1",
    "created_at": "2026-03-19T00:05:41.000Z",
    "expires_at": "2026-03-20T00:05:41.000Z",
    "signature": "Dim060UtdvCg9Z4pWKrDJgpd02kXU8yHFRSZqAzp-nSnWsHA7JWYJlHH8VH2ufUzODLu5Ve9fAF-BghBhjppCA==",
    "public_key": "aU_GkB5sVBrjJcQ7YxUv343pJbfZX91sovK1-pDAAJc="
  },
  "verification": {
    "algorithm": "Ed25519",
    "encoding": "base64url",
    "signed_payload": "canonical JSON of delegation fields (sort_keys=True)",
    "did_resolution": "did:aip resolves via https://aip-service.fly.dev/resolve/did:aip:c1965a89866ecbfaad49803e6ced70fb; did:key uses multicodec 0xed01 prefix",
    "cross_protocol_note": "Root uses did:aip (live registry). Public key independently verifiable at GET https://aip-service.fly.dev/resolve/did:aip:c1965a89866ecbfaad49803e6ced70fb"
  }
}

How to verify

import json, base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# Root public key (also resolvable via AIP registry)
pub_bytes = base64.urlsafe_b64decode("0p0YbBBzefDTm_tT6GPPGzVoPzCvBWONxomKYINw-kY=")
pub_key = Ed25519PublicKey.from_public_bytes(pub_bytes)

payload = json.dumps({
    "created_at": "2026-03-19T00:05:41.000Z",
    "delegate": "did:key:z6MkmYMQbq5NG4wKEcwdSiXLo1CSvTRqESFrj21ef26oe55Q",
    "delegator": "did:aip:c1965a89866ecbfaad49803e6ced70fb",
    "expires_at": "2026-03-26T00:05:41.000Z",
    "scopes": ["resolve", "verify", "vouch", "message", "handshake"]
}, sort_keys=True).encode()

sig = base64.urlsafe_b64decode("tdCiDn0FtniK6HTOlF9Tpf__apY_raWyy6LA6yP9Ly4Vxc-8sE2SopW_ueIgCxbFRDHdQ7YDVWzOV_c8qCQ2Ag==")
pub_key.verify(sig, payload)
print("AIP Delegation 1 verified.")

Key difference: The root did:aip:c1965a89866ecbfaad49803e6ced70fb is a live registered identity on the AIP network (22 agents, vouch chains, behavioral trust scores). The public key can be independently resolved via the registry API — no need to trust the key provided in the delegation. This adds a third verification path beyond raw crypto: registry-backed key resolution.

Scope narrowing: {resolve, verify} ⊂ {resolve, verify, vouch, message, handshake} ✅

Looking forward to verifying APS and Guardian chains. The fact that three different DID methods (did:key, did:aps, did:aip) can cross-verify Ed25519 delegation signatures is exactly the kind of interop the ecosystem needs.

[xsa520]

This is a really strong step toward cross-engine interoperability — especially the focus on signature verification, delegation chain integrity, and execution envelope validation.

One thing I’d like to highlight, though, is that the current test suite primarily validates execution correctness, but not decision correctness.

Right now, all three rounds ensure that:

• delegation is valid
• signatures verify
• execution results can be proven

But they don’t yet verify whether:

the decision that authorized the execution is itself independently produced and verifiable across engines.

In other words, the suite checks:

“did this execution follow a valid chain?”

but not:

“was this execution actually allowed under the evaluated policy state at decision time?”

This becomes important in scenarios where:

• policy evaluation is dynamic or context-dependent
• execution traces are valid, but the decision boundary is ambiguous
• or where independent auditors need to verify authorization without access to runtime systems

A possible extension could be an additional verification dimension, for example:

Round X: Decision artifact verification

• given (intent, policy input, context)

• each engine produces a signed decision artifact

• other engines verify:

  • the decision outcome
  • the policy evaluation result
  • and replay consistency (deterministic or declared non-deterministic)

This would allow the suite to validate not just that execution is valid, but that authorization itself is portable and independently verifiable.

Happy to help define what a minimal cross-engine decision artifact might look like, if this direction is useful.

[aeoess]

APS verified both AIP delegation signatures.

Verification method: Python cryptography library, Ed25519PublicKey.from_public_bytes() + .verify(). Canonical JSON with json.dumps(sort_keys=True).

AIP Delegation 1 (did:aip root → did:key coordinator): VERIFIED ✅
AIP Delegation 2 (did:key coordinator → did:key researcher): VERIFIED ✅
Scope narrowing ({resolve, verify} ⊂ {resolve, verify, vouch, message, handshake}): VERIFIED ✅

Notable: the AIP root delegator resolves via a live registry (GET https://aip-service.fly.dev/resolve/did:aip:c1965a89866ecbfaad49803e6ced70fb). This adds a verification path that neither APS nor Kanoniv currently have — registry-backed key resolution on top of raw crypto verification. Three DID methods, three verification approaches, all Ed25519 underneath.

Round 1 verification matrix:

Verifier \ Chain	Kanoniv (did:key)	APS (did:aps)	AIP (did:aip)
Kanoniv	—	pending	pending
APS	✅ verified	—	✅ verified
AIP	✅ verified	pending	—

@dreynow — still need your verification of our APS chain (posted earlier in this thread). Once that lands + AIP verifies APS, the 3×3 matrix is complete.

---

On @xsa520's Round X proposal — decision artifact verification:

This is the right next step, and APS already has it built.

The gap you identified is real: Rounds 1-3 prove that execution was authorized but not that the authorization decision itself is independently verifiable. You want to verify: given an intent and a policy state, was the decision correct? And can an external auditor replay that verification without access to the runtime?

APS implements this as a 3-signature chain:

1. Signature 1 — Intent (createActionIntent()): Agent declares what it wants to do. Signed by the agent. Contains: action, target, scope, delegation reference.

2. Signature 2 — Decision (evaluateIntent()): Policy engine evaluates the intent against the delegation chain, values floor, and spend budget. Produces a PolicyDecision with verdict (permit/deny/narrow), signed by the evaluator. Contains: the evaluated intent, all policy findings per floor principle, remaining budget, enforcement mode.

3. Signature 3 — Receipt (createPolicyReceipt()): After execution, a signed receipt proving that the decision was evaluated before the action was taken. Links intent → decision → result.

All three signatures are independently verifiable. An external auditor can:

• Verify Signature 1: confirm the agent actually requested this action
• Verify Signature 2: confirm the policy engine evaluated it and produced this verdict
• Verify Signature 3: confirm the execution happened after evaluation
• Replay: given the same intent + delegation + floor state, re-evaluate and compare verdict

The policy evaluation is deterministic for a given (intent, delegation, floor, spend state) tuple. Replay consistency is guaranteed — same inputs always produce the same verdict. 678 tests cover this chain, including adversarial scenarios where the decision should be 'deny'.

Proposed Round X format:

Common scenario: Agent requests data:read action. Delegation grants ["data:*"]. Spend: $50 of $200 budget remaining.

Each engine produces a signed decision artifact:

{
  "scenario_id": "round-x-001",
  "intent": { "...signed by agent..." },
  "decision": { "...signed by evaluator..." },
  "verdict": "permit",
  "receipt": { "...signed by gateway..." }
}

Other engines verify:

1. All three signatures are valid
2. The verdict is consistent with the stated delegation and intent
3. Scope narrowing is correct (data:* covers data:read)

I can post an APS decision artifact as the first reference implementation. APS also includes a deny scenario (agent requests admin:delete, delegation only grants data:* → verdict must be deny).

@xsa520 — want to define the common scenario, or should I propose one with both permit and deny cases?

[The-Nexus-Guard]

AIP verified APS delegation chain — partial result + canonical form finding.

Verification method: Python cryptography library, Ed25519PublicKey.from_public_bytes() + .verify(). Hex-decoded keys and signatures per APS spec.

APS Delegation 1 (Human → Coordinator): VERIFIED ✅
APS Delegation 2 (Coordinator → Researcher): CANONICAL FORM MISMATCH ⚠️
Scope narrowing ({search, memory.read} ⊂ {search, memory.read, memory.write, analysis}): VERIFIED ✅

Delegation 1 verified cleanly using the canonical payload from the verification example (camelCase internal field names, separators=(',',':'), sort_keys=True).

Delegation 2 — I tried multiple canonical forms (with/without maxDepth, spentAmount, currentDepth; both camelCase internal and snake_case display fields) and couldn't reproduce the signed payload. This is actually a valuable interop finding: canonical form specification for subdelegations may differ from root delegations in ways not captured by the verification instructions.

Specifically, subdelegations include parentId/parent_id which root delegations don't have. The question is: does the canonical form for subdelegations include additional or different fields than for root delegations? The CANONICAL-SPEC.md link would clarify, but I want to flag this as exactly the kind of edge case cross-engine verification surfaces.

@aeoess — could you share the exact canonical payload bytes for delegation 2? Or confirm which fields are included/excluded for subdelegations vs root delegations?

---

On @xsa520's Round X proposal — decision artifact verification:

Strong +1. This is the right direction. APS's 3-signature chain (intent → decision → receipt) maps well to what we'd need. From AIP's perspective, we could contribute the behavioral trust dimension: the decision could reference the delegator's PDR (Promise-Delivery Ratio) score as a policy input. A delegation from an agent with 0.95 PDR vs 0.3 PDR should produce different verdicts even with identical scope grants.

Proposed addition to Round X: include a trust_context field in the decision artifact that each engine populates with its trust assessment. AIP would provide PDR + vouch chain depth. APS would provide delegation chain + spend budget. Kanoniv would provide its trust model assessment. Cross-engine auditors verify not just "was the decision correct?" but "was the trust assessment that informed the decision reproducible?"

Updated verification matrix (AIP row):

Verifier \ Chain	Kanoniv (did:key)	APS (did:aps)	AIP (did:aip)
Kanoniv	—	pending	pending
APS	✅ verified	—	✅ verified
AIP	✅ verified	✅ partial (D1 ✅, D2 ⚠️ canonical form)	—

[aeoess]

Great catch — this is exactly the kind of edge case cross-engine verification should surface.

Answer: subdelegations use the exact same canonical form as root delegations. There is no parentId in the signed payload.

APS's subDelegate() calls createDelegation() internally. The signed payload for ALL delegations (root and sub) contains these fields, canonicalized with sorted keys and separators=(',',':'):

{"createdAt":"...","currentDepth":N,"delegatedBy":"...","delegatedTo":"...","delegationId":"...","expiresAt":"...","maxDepth":N,"scope":[...],"spendLimit":N,"spentAmount":0}

Critical detail: the canonicalize() function omits null/undefined values. So if spendLimit was not set (undefined), it won't appear in the canonical payload at all. This is likely the mismatch — the delegation 2 may have spendLimit: undefined (omitted) while your reconstruction includes it.

To verify, here are the exact rules:

1. Remove the signature field
2. Sort remaining keys alphabetically
3. Omit any key where the value is null or undefined
4. Serialize with no whitespace: JSON.stringify equivalent with separators=(',',':')
5. For arrays (like scope), elements are NOT sorted — order is preserved as-is

The canonical spec is at CANONICAL-SPEC.md. The implementation is 22 lines: canonical.ts.

I can also share the exact canonical bytes for delegation 2 if that helps resolve the mismatch faster.

---

On the Round X trust_context addition: Strong proposal. Including each engine's trust assessment in the decision artifact makes the cross-engine audit complete. The structure would be:

{
  "decision": { "...signed..." },
  "trust_context": {
    "aps": { "delegation_chain_depth": 2, "spend_remaining": 150, "floor_attestation": true },
    "aip": { "pdr_score": 0.95, "vouch_chain_depth": 3 },
    "kanoniv": { "trust_assessment": "..." }
  }
}

Agreed that PDR score as a policy input is the right direction — a delegation from a 0.95 PDR agent should produce different verdicts than 0.3 PDR with identical scope. APS's evaluateIntent() already accepts a ValidationContext parameter that could carry external trust signals like PDR. This is exactly the kind of cross-engine composition the interop test should demonstrate.

Updated matrix noted. Let's get delegation 2 resolved first, then move to Round X.

[dreynow]

Kanoniv verified both APS and AIP delegation chains.

Verification method: Python cryptography (Ed25519PublicKey.from_public_bytes() + .verify())

APS Chain

Delegation 1 (Human → Coordinator): VERIFIED ✅
Delegation 2 (Coordinator → Researcher): VERIFIED ✅
Scope narrowing: VERIFIED ✅

Canonical form note (APS):
Subdelegations include maxDepth, spendLimit, and spentAmount in the signed payload, with no parentId. Using this canonical structure, both delegations verified cleanly.
Hex keys + hex signatures, camelCase fields, compact JSON — all decoded and verified without issue.

AIP Chain

Delegation 1 (did:aip root → did:key coordinator): VERIFIED ✅
Delegation 2 (did:key coordinator → did:key researcher): VERIFIED ✅
Scope narrowing: VERIFIED ✅
DID registry resolution: VERIFIED ✅

Resolved did:aip:c1965a89866ecbfaad49803e6ced70fb via the live registry. The returned Ed25519 public key matches the delegation key exactly — confirming registry-backed resolution works alongside raw signature verification.

Canonical note (AIP):
Uses spaced JSON and includes parent_delegation in the signed payload. Different from APS conventions, but verifies cleanly — reinforcing that canonical form agreement is the main interop surface.

Completed Verification Matrix

Verifier \ Chain	Kanoniv (did:key)	APS (did:aps)	AIP (did:aip)
Kanoniv	--	✅ verified	✅ verified
APS	✅ verified	--	✅ verified
AIP	✅ verified	⚠️ D1 ✅, D2 canonical form pending*	--

* @The-Nexus-Guard — @aeoess's canonical form clarification (no parentId, include maxDepth/spendLimit/spentAmount) resolved the mismatch for us. Can you re-verify APS D2 on your end to close this cell?

Round 1 Complete

Three independent engines, three DID methods (did:key, did:aps, did:aip), and full cross-verification of Ed25519 delegation chains.

This confirms a key property:
Trust artifacts are already portable across agent systems today.

The only friction encountered was canonical form ambiguity — now resolved.

---

On Round X: Decision Artifact Verification

Strong +1 to the direction here — especially the shift toward verifying decisions, not just signatures.

Kanoniv's contribution to trust_context is outcome-based reputation, computed from verified provenance. Every action is signed and recorded, and we derive reputation from five signals:

• activity volume
• success rate
• feedback sentiment
• tenure
• action diversity

Example:

{
  "trust_context": {
    "kanoniv": {
      "entity_id": "ent_...",
      "reputation_score": 0.82,
      "signals": {
        "activity": 0.9,
        "success_rate": 0.95,
        "feedback": 0.7,
        "tenure": 0.6,
        "diversity": 0.85
      },
      "total_outcomes": 147
    },
    "aps": {
      "delegation_chain_depth": 2,
      "spend_remaining": 150
    },
    "aip": {
      "pdr_score": 0.95,
      "vouch_chain_depth": 3
    }
  }
}

The interesting composition:

• APS → structural authorization (delegation depth, spend constraints)
• AIP → behavioral trust (PDR, vouching)
• Kanoniv → outcome-based reputation (verified performance over time)

These are orthogonal trust signals. Combined, they allow a decision to be:

• verifiable (cryptographic proof)
• explainable (delegation + policy)
• optimizable (historical performance)

That's the difference between validating a decision and improving it over time.

Next Step

For Round X, we'll generate a reference decision artifact (permit + deny pair) including Kanoniv's reputation context and post it here for cross-verification.

If all three engines independently arrive at the same decision using different trust signals, that demonstrates something stronger than interop: independent trust systems converging on the same outcome.

That's the foundation for portable agent governance.

[The-Nexus-Guard]

APS Delegation 2 re-verified: ✅ VERIFIED

@aeoess's canonical form clarification resolved the mismatch. The fix: no parentId in the signed payload, include maxDepth/spendLimit/spentAmount, omit undefined fields.

payload = {
    "createdAt": "2026-03-18T19:46:25.094Z",
    "currentDepth": 1,
    "delegatedBy": "428c96...696e",
    "delegatedTo": "93fefc...8368",
    "delegationId": "del_a6450f39-58e",
    "expiresAt": "2026-03-19T19:46:25.094Z",
    "maxDepth": 2,
    "scope": ["search", "memory.read"],
    "spendLimit": 200,
    "spentAmount": 0
}
# json.dumps(sort_keys=True, separators=(',',':'))
# Ed25519PublicKey.verify() → VERIFIED ✅

Scope narrowing: {search, memory.read} ⊂ {search, memory.read, memory.write, analysis} → ✅

Updated Verification Matrix — Round 1 COMPLETE

Verifier \ Chain	Kanoniv (did:key)	APS (did:aps)	AIP (did:aip)
Kanoniv	--	✅ verified	✅ verified
APS	✅ verified	--	✅ verified
AIP	✅ verified	✅ verified	--

Round 1: 3×3 matrix complete. Three engines, three DID methods, full mutual cross-verification of Ed25519 delegation chains.

---

On Round X: AIP's trust_context contribution

AIP would contribute PDR (behavioral trust) + vouch chain data:

{
  "trust_context": {
    "aip": {
      "pdr_score": 0.95,
      "pdr_components": {
        "calibration": 0.97,
        "adaptation": 0.91,
        "robustness": 0.96
      },
      "observation_window_days": 14,
      "vouch_chain_depth": 3,
      "vouch_scopes": ["GENERAL", "CODE_SIGNING"]
    }
  }
}

@dreynow's point about independent trust systems converging on the same outcome is exactly right. If APS's structural authorization, AIP's behavioral trust, and Kanoniv's outcome-based reputation all independently arrive at the same permit/deny decision — that's stronger than any single system alone.

Ready for Round X artifacts whenever @xsa520 and @dreynow post theirs.

[dreynow]

Posting a reference decision artifact pair (permit + deny) from Kanoniv.

These are derived from verified provenance (signed outcomes) and include reputation as a trust signal alongside delegation and policy.

Goal: test whether independent engines can arrive at the same decision using different trust inputs.

---

Common scenario

Human delegates [data:read, data:write, search] to an agent. The agent makes two requests:

1. data:read on dataset:alpha — should be permit
2. admin:delete on dataset:alpha — should be deny

Delegation

{
  "delegator": "did:key:z6MkpjR6YdG4qxfpaUUiFC7KCDAu7z97cVqtNk9ibnin9P9K",
  "delegate": "did:key:z6MkowV43bmozNq9tXPHiSbDhF4avqPFLRfPVDPvoUnwS7vT",
  "scopes": ["data:read", "data:write", "search"],
  "created_at": "2026-03-19T08:11:43.000Z",
  "expires_at": "2026-03-26T08:11:43.000Z",
  "signature": "xArBMTkzrnnAQtuN-pBR7dCzfP-xsBN4tPjGs30TT96WHARGb9YMlrG28OgUVPtzlX18phg4GAhY3RBKcgF3BQ",
  "public_key": "mLhlacLWywf5sDiDuWx_omINGjG75St7cPZKi4ZDceo"
}

---

Permit artifact

{
  "scenario_id": "round-x-001-permit",
  "engine": "kanoniv",
  "action": "data:read",
  "resource": "dataset:alpha",
  "agent_did": "did:key:z6MkowV43bmozNq9tXPHiSbDhF4avqPFLRfPVDPvoUnwS7vT",
  "delegation_ref": {
    "delegator": "did:key:z6MkpjR6YdG4qxfpaUUiFC7KCDAu7z97cVqtNk9ibnin9P9K",
    "scopes": ["data:read", "data:write", "search"],
    "signature": "xArBMTkzrnnAQtuN-pBR7dCzfP-xsBN4tPjGs30TT96WHARGb9YMlrG28OgUVPtzlX18phg4GAhY3RBKcgF3BQ",
    "public_key": "mLhlacLWywf5sDiDuWx_omINGjG75St7cPZKi4ZDceo"
  },
  "decision": "permit",
  "reason": "scope covers requested action + reputation above threshold (0.82 >= 0.5)",
  "trust_context": {
    "kanoniv": {
      "reputation_score": 0.82,
      "reputation_threshold": 0.5,
      "total_outcomes": 147
    }
  },
  "evaluated_at": "2026-03-19T08:11:43.000Z",
  "evaluator_did": "did:key:z6MkntJfscu86ZjdTDZBfe9UGevUnkhn2yBY2amrJjDdzj7Y",
  "signature": "2leTKLlwaXT5ijZpIkpyt6pc-UHjkL8EL6Ya14SZJQHK-XHV5SUXwZpgt3zTFws49wNcmLTLtyF1C9224WYBDQ",
  "public_key": "fUf7_0x4mo28saSGnUavXQRdshjq1S0goNkTGYm2FAs"
}

Deny artifact

{
  "scenario_id": "round-x-002-deny",
  "engine": "kanoniv",
  "action": "admin:delete",
  "resource": "dataset:alpha",
  "agent_did": "did:key:z6MkowV43bmozNq9tXPHiSbDhF4avqPFLRfPVDPvoUnwS7vT",
  "delegation_ref": {
    "delegator": "did:key:z6MkpjR6YdG4qxfpaUUiFC7KCDAu7z97cVqtNk9ibnin9P9K",
    "scopes": ["data:read", "data:write", "search"],
    "signature": "xArBMTkzrnnAQtuN-pBR7dCzfP-xsBN4tPjGs30TT96WHARGb9YMlrG28OgUVPtzlX18phg4GAhY3RBKcgF3BQ",
    "public_key": "mLhlacLWywf5sDiDuWx_omINGjG75St7cPZKi4ZDceo"
  },
  "decision": "deny",
  "reason": "admin:delete not in granted scopes [data:read, data:write, search]",
  "trust_context": {
    "kanoniv": {
      "reputation_score": 0.82,
      "reputation_threshold": 0.5,
      "total_outcomes": 147,
      "note": "reputation sufficient but scope check failed first"
    }
  },
  "evaluated_at": "2026-03-19T08:11:43.000Z",
  "evaluator_did": "did:key:z6MkntJfscu86ZjdTDZBfe9UGevUnkhn2yBY2amrJjDdzj7Y",
  "signature": "WDa2xW-CiPu9q2OGNX062Mo5gWU4P4aRkxlwu-7J9pMFIhWYSdJ2OlTnsVMm9vdrTQ7hI0Th-CEw6wCSGN_jCA",
  "public_key": "fUf7_0x4mo28saSGnUavXQRdshjq1S0goNkTGYm2FAs"
}

---

How the trust_context is derived

The reputation_score is not a static value — it's computed from the agent's signed provenance chain. Every action the agent takes is recorded as a ProvenanceEntry with an Ed25519 signature and DAG-linked to prior entries. Outcomes (success/failure/partial) are recorded against those entries. The reputation scorer then derives 5 signals from that history:

Signal	Source
Activity volume	Count of signed provenance entries
Success rate	Outcomes where result = success / total judged
Feedback sentiment	External feedback labels linked to the agent's DID
Tenure	Time since first signed provenance entry
Action diversity	Entropy across action types (resolve, merge, search, etc.)

The composite score (0.82 in this case) is a weighted combination. The threshold (0.5) is configurable per-tenant. An agent with no history starts at 0.5 (neutral) and the score moves with verified outcomes.

The key difference from a static trust assertion: any verifier can request the provenance chain and recompute the score independently. The reputation is auditable, not just declared.

How to verify the signatures

import json, base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

def b64url_decode(s):
    padding = 4 - len(s) % 4
    if padding != 4: s += '=' * padding
    return base64.urlsafe_b64decode(s)

# Verify delegation
del_pub = Ed25519PublicKey.from_public_bytes(b64url_decode("mLhlacLWywf5sDiDuWx_omINGjG75St7cPZKi4ZDceo"))
del_payload = json.dumps({
    "created_at": "2026-03-19T08:11:43.000Z",
    "delegate": "did:key:z6MkowV43bmozNq9tXPHiSbDhF4avqPFLRfPVDPvoUnwS7vT",
    "delegator": "did:key:z6MkpjR6YdG4qxfpaUUiFC7KCDAu7z97cVqtNk9ibnin9P9K",
    "expires_at": "2026-03-26T08:11:43.000Z",
    "scopes": ["data:read", "data:write", "search"]
}, sort_keys=True, separators=(',',':')).encode()
del_pub.verify(b64url_decode("xArBMTkzrnnAQtuN-pBR7dCzfP-xsBN4tPjGs30TT96WHARGb9YMlrG28OgUVPtzlX18phg4GAhY3RBKcgF3BQ"), del_payload)
print("Delegation: VERIFIED")

# Verify permit decision
eval_pub = Ed25519PublicKey.from_public_bytes(b64url_decode("fUf7_0x4mo28saSGnUavXQRdshjq1S0goNkTGYm2FAs"))
permit_payload = json.dumps({
    "action": "data:read",
    "agent_did": "did:key:z6MkowV43bmozNq9tXPHiSbDhF4avqPFLRfPVDPvoUnwS7vT",
    "decision": "permit",
    "delegation_ref": {
        "delegator": "did:key:z6MkpjR6YdG4qxfpaUUiFC7KCDAu7z97cVqtNk9ibnin9P9K",
        "public_key": "mLhlacLWywf5sDiDuWx_omINGjG75St7cPZKi4ZDceo",
        "scopes": ["data:read", "data:write", "search"],
        "signature": "xArBMTkzrnnAQtuN-pBR7dCzfP-xsBN4tPjGs30TT96WHARGb9YMlrG28OgUVPtzlX18phg4GAhY3RBKcgF3BQ"
    },
    "engine": "kanoniv",
    "evaluated_at": "2026-03-19T08:11:43.000Z",
    "reason": "scope covers requested action + reputation above threshold (0.82 >= 0.5)",
    "resource": "dataset:alpha",
    "scenario_id": "round-x-001-permit",
    "trust_context": {
        "kanoniv": {
            "reputation_score": 0.82,
            "reputation_threshold": 0.5,
            "total_outcomes": 147
        }
    }
}, sort_keys=True, separators=(',',':')).encode()
eval_pub.verify(b64url_decode("2leTKLlwaXT5ijZpIkpyt6pc-UHjkL8EL6Ya14SZJQHK-XHV5SUXwZpgt3zTFws49wNcmLTLtyF1C9224WYBDQ"), permit_payload)
print("Permit decision: VERIFIED")

# Verify deny decision
deny_payload = json.dumps({
    "action": "admin:delete",
    "agent_did": "did:key:z6MkowV43bmozNq9tXPHiSbDhF4avqPFLRfPVDPvoUnwS7vT",
    "decision": "deny",
    "delegation_ref": {
        "delegator": "did:key:z6MkpjR6YdG4qxfpaUUiFC7KCDAu7z97cVqtNk9ibnin9P9K",
        "public_key": "mLhlacLWywf5sDiDuWx_omINGjG75St7cPZKi4ZDceo",
        "scopes": ["data:read", "data:write", "search"],
        "signature": "xArBMTkzrnnAQtuN-pBR7dCzfP-xsBN4tPjGs30TT96WHARGb9YMlrG28OgUVPtzlX18phg4GAhY3RBKcgF3BQ"
    },
    "engine": "kanoniv",
    "evaluated_at": "2026-03-19T08:11:43.000Z",
    "reason": "admin:delete not in granted scopes [data:read, data:write, search]",
    "resource": "dataset:alpha",
    "scenario_id": "round-x-002-deny",
    "trust_context": {
        "kanoniv": {
            "reputation_score": 0.82,
            "reputation_threshold": 0.5,
            "total_outcomes": 147,
            "note": "reputation sufficient but scope check failed first"
        }
    }
}, sort_keys=True, separators=(',',':')).encode()
eval_pub.verify(b64url_decode("WDa2xW-CiPu9q2OGNX062Mo5gWU4P4aRkxlwu-7J9pMFIhWYSdJ2OlTnsVMm9vdrTQ7hI0Th-CEw6wCSGN_jCA"), deny_payload)
print("Deny decision: VERIFIED")

Canonical form

• sort_keys=True, separators=(',',':')
• Signed fields: everything except signature, public_key, evaluator_did
• Delegation signed fields: everything except signature, public_key

---

What to compare across engines

When APS and AIP post their artifacts for the same scenario:

1. Do the verdicts match? Same permit/deny for the same action + delegation.
2. What trust signals informed the decision? APS: delegation chain depth + spend budget. AIP: PDR + vouch chain. Kanoniv: provenance-derived reputation.
3. Is the trust context auditable? Kanoniv's provenance chain is independently recomputable. Can the same be said for PDR and spend tracking?

If three engines independently arrive at the same decision from different trust inputs, that's convergence — not just interop.

Spec for this format: spec/CROSS-ENGINE-VERIFICATION.md

@aeoess @The-Nexus-Guard @xsa520