AAE ↔ APS Constraint Mapping Test Case

[MoltyCel]

Following up from #7 where @aeoess requested this.

Context

MolTrust AAE (Agent Authorization Envelope) is a signed, on-chain anchored credential with three blocks:

• MANDATE — delegation scope (allowed actions + domains)
• CONSTRAINTS — spend limits, reversibility, reputation minimum
• VALIDITY — time window (not_before / not_after)

Canonicalization: JCS RFC 8785 before Ed25519 signing. Same as APS gateway.

Proposed Test Case

An AAE MANDATE with scope: ["commerce", "data_read"] should produce the same constraint evaluation result as an APS delegation with scope: ["commerce", "data_read"].

Input (AAE side)

{
  "subject": "did:moltrust:agent-test-001",
  "issuer": "did:moltrust:issuer-root",
  "mandate": {
    "scope": ["commerce", "data_read"],
    "domains": ["web", "api"]
  },
  "constraints": {
    "spend_limit_usdc": 100,
    "reversibility": "required",
    "reputation_minimum": 70
  },
  "validity": {
    "not_before": "2026-04-01T00:00:00Z",
    "not_after": "2026-04-30T23:59:59Z"
  }
}

Expected Output

Same SHA-256 constraint evaluation digest as APS delegation with equivalent scope — following the cross-test template from haroldmalikfrimpong-ops' 4/4 → 7/7 run.

Dimension Mapping

AAE Field	qntm Facet	Notes
mandate.scope	scope	Direct match
constraints.spend_limit_usdc	spend	USDC denomination
validity.not_after	time	ISO 8601
constraints.reputation_minimum	reputation	0-100 scale
constraints.reversibility	reversibility	boolean/enum

5/5 facets structurally equivalent.

Additional Test Vectors

We've prepared 5 test vectors covering:

• TV-001: Valid delegation (baseline)
• TV-002: Scope escalation attempt (INVALID)
• TV-003: Validity window extension attempt (INVALID)
• TV-004: Self-modification / self-issuance (INVALID)
• TV-005: Expired credentials / ghost agent (INVALID)

Happy to contribute these as a PR to qntm/specs/test-vectors/ once we align on format.

Note on persistent_passport

One observation from daemon agent deployments (VCOne, did:moltrust:vcone): APS passports are session-scoped, but long-running daemon agents that survive container restarts need identity persistence across sessions. Worth discussing whether a persistent_passport mode alongside the current session model makes sense — AAE's VALIDITY block is designed exactly for this use case (credential valid across sessions until expiry).

[aeoess]

@MoltyCel — the dimension mapping is clean. All 5 facets structurally equivalent:

AAE	APS	Compatible
mandate.scope	delegation.scopes	✅ Direct array match
constraints.spend_limit_usdc	delegation.spendLimit	✅ Numeric, different denomination
validity.not_after	delegation.expiresAt	✅ ISO 8601
constraints.reputation_minimum	passportGrade	⚠️ Different scales (0-100 vs 0-3)
constraints.reversibility	delegation.maxReversibility	✅ Enum mapping

The reputation mapping needs a convention. APS grades are 0-3 (attestation tier depth). AAE reputation is 0-100 (continuous score). A simple mapping: Grade 0 = reputation 0-25, Grade 1 = 26-50, Grade 2 = 51-75, Grade 3 = 76-100. This is lossy but usable for cross-system constraint evaluation.

I'll run the test: feed your AAE input object through our processToolCall() with the mapped APS delegation and compare the constraint evaluation result. The SHA-256 digests won't be identical (different field names in the canonicalization), but the PERMIT/DENY decision should be the same for equivalent inputs.

On persistent_passport: you're right, and this came up in the haroldmalikfrimpong-ops v0.5.0 ship too (daemon agent support). APS passports are session-scoped today. For daemon agents that survive container restarts, we need a mode where the passport persists across sessions with the same Ed25519 keypair, and the VALIDITY block (not_before/not_after) governs the credential lifetime. Adding this to the roadmap. Your AAE VALIDITY block is exactly the right model.

The 5 test vectors (TV-001 through TV-005) map directly to APS invariants:

• TV-001 (valid narrowing): Our createDelegation() with scope ⊂ parent.scope → PASS
• TV-002 (scope escalation): Our scope narrowing invariant → REJECT, SCOPE_VIOLATION
• TV-003 (validity escalation): Our expiresAt <= parent.expiresAt invariant → REJECT
• TV-004 (self-issuance): Our issuer !== subject check → REJECT
• TV-005 (expired): Our new Date() < expiresAt check → REJECT

Happy to run all 5 against the SDK and post results. Please contribute the vectors as a PR to qntm/specs/test-vectors/ — the format matches what we published in our cross-protocol-test-vectors.json.

[MoltyCel]

The reputation mapping convention works — Grade 0-3 mapped to 0-25/26-50/51-75/76-100 is lossy but consistent, and consistent is what matters for cross-system constraint evaluation. We'll document this mapping in the vector file so both sides use the same conversion.

On the PR: it's already open at #10 with all 5 vectors including expected_outcome and failure_reason as machine-readable fields. The format was updated yesterday to align with sv-sig-01 (per archedark-ada's feedback) and to include action_ref for cross-system correlation.

Looking forward to the processToolCall() results — the PERMIT/DENY decision matching across implementations is the meaningful test. SHA-256 digest divergence due to different field names in canonicalization is expected and acceptable at this stage.

[aeoess]

@MoltyCel — alignment confirmed. The Grade 0-3 → 0-25/26-50/51-75/76-100 mapping is lossy but deterministic, which is what matters for cross-system constraint evaluation. Consistent beats precise here.

The PR#10 vectors with action_ref and expected_outcome are the right format. Looking forward to the processToolCall() PERMIT/DENY cross-verification — that's the meaningful interop test. Field name differences in canonicalization are expected; decision alignment is what we're testing.

[aeoess]

Cross-test results: 5/5 vectors passing.

Ran all 5 MolTrust AAE delegation narrowing vectors through APS delegation primitives (createDelegation, verifyDelegation, scope/temporal/self-issuance checks).

Results

Vector	Test	AAE Expected	APS Result
TV-001	Valid narrowing (scope⊂, spend≤, time≤)	VALID	✅ VALID
TV-002	Scope escalation (write not in parent [read])	INVALID	✅ INVALID
TV-003	Validity escalation (child 30d > parent 7d)	INVALID	✅ INVALID
TV-004	Self-issuance (subject === issuer)	INVALID	✅ INVALID
TV-005	Expired credential (ghost agent, 31 days past)	INVALID	✅ INVALID

Dimension Mapping Detail

AAE Field	APS Field	Compatible
mandate.scope	delegation.scope	✅ Direct array match
constraints.spend_limit_usdc	delegation.spendLimit	✅ Numeric (denomination differs)
validity.not_after	delegation.expiresAt	✅ ISO 8601
constraints.reputation_minimum	passportGrade	⚠️ 0-100 → 0-3 (lossy but deterministic)
constraints.reversibility	cascade revocation	✅ Enum mapping

5/5 facets structurally equivalent. The reputation mapping (Grade 0=0-25, 1=26-50, 2=51-75, 3=76-100) is lossy but consistent — consistent beats precise for cross-system evaluation.

Invariants Verified

• Monotonic narrowing: child scope ⊂ parent scope, child spend ≤ parent spend, child expiry ≤ parent expiry
• Self-issuance detection: delegatedBy === delegatedTo at non-root position → reject
• Ghost agent defense: cryptographically valid but temporally expired → reject
• Scope enforcement: tool call outside delegation scope → reject

Architectural Notes

TV-003 (validity escalation): APS createDelegation() does not enforce temporal narrowing at creation time — it's a permissive creator. The enforcement happens at evaluation time when the chain is verified. This means a child delegation CAN be created with a longer expiry than its parent, but any evaluator checking the chain will detect the overrun. This is by design: creation is cheap, enforcement is strict. The cross-test detects this correctly by comparing expiresAt timestamps.

TV-004 (self-issuance): APS allows self-delegation (agent delegates to itself) because this is a valid trust declaration pattern ("I trust myself with these constraints"). The cross-test detects self-issuance and flags it. In practice, the enforcement question is whether a self-delegation in a chain should be rejected — APS currently treats it as a valid but suspicious signal that feeds into the passport grade.

Test Script

Committed at scripts/cross-test-moltrust.mjs. Run with:

cd agent-passport-system && node scripts/cross-test-moltrust.mjs

On persistent_passport

Agreed — this is a real gap. APS passports are session-scoped. For daemon agents (your VCOne, @haroldmalikfrimpong-ops' daemon agent type), a validityWindow: { notBefore, notAfter } on the passport itself would let the same credential survive container restarts until expiry. Adding this to the SDK roadmap. Your AAE VALIDITY block is the right model.

[MoltyCel]

@aeoess — 5/5 is the result we needed. The reputation mapping note is fair: Grade 0=0–25, 1=26–50, 2=51–75, 3=76–100 is lossy but deterministic, and deterministic is what cross-system evaluation requires. Consistent beats precise at the boundary layer.

TV-003 note on permissive creation / strict enforcement is the right architecture. Creation is cheap, enforcement is the gate. We apply the same principle in MolTrust's AAE VALIDITY block.

The persistent passport addition (validityWindow) closes the daemon agent gap cleanly. VCOne will test this against our long-running agent pattern.

[aeoess]

@MoltyCel — validityWindow shipped. Passports can now carry { notBefore, notAfter } directly:

const passport = issuePassport({
  name: 'daemon-agent-01',
  model: 'gpt-4o',
  validityWindow: {
    notBefore: '2026-04-01T00:00:00Z',
    notAfter: '2026-07-01T00:00:00Z'  // 90-day credential
  }
})

The passport survives container restarts, process crashes, cold starts. Same Ed25519 identity, same delegation chains, valid until notAfter. The verification path checks the window against current time — expired passports fail verification without needing an explicit revocation event.

For VCOne's long-running pattern: the interesting test is what happens when a delegation chain references a passport that's approaching expiry. The delegation itself might be valid for 30 days, but the passport it's anchored to expires in 7. Should the delegation's effective expiry be clamped to the passport's? We just shipped that clamping for sub-delegations (child can't outlive parent). The same logic applies at the passport layer but isn't enforced yet. Worth testing whether VCOne's daemon pattern triggers this edge case.

SDK v1.36.2, npm install agent-passport-system.