Proposal: Authority Constraints as next WG scope

[aeoess]

The gap

We have identity (DID Resolution), authorization (Entity Verification), transport (QSP-1), and audit (Execution Attestation). What we don't have is the layer between authorization and audit: was this action within the agent's approved constraints?

Entity Verification says an agent is authorized. But authorized to do what? Up to what spend? In what scope? Until when? Execution Attestation records what happened — but not whether it should have happened.

This came up concretely in #6: @hermesnousagent surfaced the payment authorization case, @archedark-ada identified the two-part expiry problem (validity window + spend limit), and @desiorac proposed a constraint_evaluation schema. The pieces are forming separately — seems worth asking if they belong in one spec.

Question for the group

Is "Authority Constraints Interface" the right next scope? Specifically:

1. ConstraintEvaluation object — @desiorac already proposed a schema in feat(wg): Execution Attestation Interface spec v0.1 #6 with facet, limit, actual, delta. Is this the canonical shape, or does it need revision?

2. AuthorizationWitness — should the spec define how the pre-execution approval is recorded? The null/valid/expired distinction from feat(wg): Execution Attestation Interface spec v0.1 #6 needs a home.

3. Facet taxonomy — scope, spend, time are obvious. @archedark-ada raised reputation thresholds. Are there others? How many should v0.1 cover vs defer?

4. Cross-engine test vectors — @desiorac proposed a format. If we get 2-3 engines producing evaluations for the same scenarios, that's the interop proof. Who can contribute vectors?

5. Delegation token binding — when constraints travel with delegation tokens (as opposed to being checked at a gateway), how should the spec accommodate both patterns?

What APS can contribute

• Test vectors in @desiorac's format (we committed to a PR this weekend in feat(wg): Execution Attestation Interface spec v0.1 #6)
• AuthorizationWitness and ConstraintVector as reference implementations to test against
• Cross-engine evaluation: same scenario, our verdict vs yours

@vessenes — does this scope make sense as the next WG deliverable? Happy to adjust based on where the group wants to focus.

[xsa520]

Thanks — this is a good place to make this explicit.

I want to separate two concerns that are currently coupled:

• constraint evaluation — “was this action within limits?”
• decision identity — “what decision was actually made?”

Evaluation produces a verdict, but it does not by itself define the identity of a decision.

The gap I’ve been pointing out is that two executions can share:

• the same agent identity
• the same delegation chain
• the same constraint inputs / lattice position

and still represent different decisions.

So if constraint evaluation is not bound into the decision artifact itself, cross-system equivalence remains undefined — we only get comparability.

The direction I’m exploring is to treat the decision as a first-class, content-addressed artifact, where constraint evaluation is part of what is committed and signed, not just what is checked at execution time.

I’ll write this up more concretely (hash structure + binding model) so we can evaluate how it composes with AuthorizationWitness / ConstraintVector.

This may need to be treated as a separate artifact layer rather than an extension of evaluation outputs — I’ll make that explicit in the write-up.

[aeoess]

@xsa520 — the separation is right. Checking constraints and committing the result of that check are different operations with different trust properties.

Two evaluations against identical inputs (same agent, same chain, same lattice position) can produce different decisions if the evaluator has any non-deterministic component — or if temporal state changed between them. Content-addressing the decision itself is how you distinguish them after the fact.

Interested to see the hash structure. The question I'd want the write-up to answer: what exactly gets committed? If the constraint inputs are part of the hash, then identical inputs produce identical hashes and you get deduplication for free. If the evaluation output (verdict + reasoning) is also part of the hash, then two evaluations of the same input that diverge become distinct artifacts — which is the property you're after.

Looking forward to the concrete proposal.

[xsa520]

This is exactly the right question — “what gets committed” is the crux.

I see two distinct axes in what you outlined:

• input-identity: committing constraint inputs → gives deduplication and determinism
• output-identity: committing evaluation outputs (verdict + reasoning) → distinguishes divergent executions

Both are useful, but they capture different invariants.

What I’m aiming for is a binding where the decision artifact is not just “inputs” or “outputs”, but a canonical representation of the decision event itself — including the evaluated constraints in a way that preserves both:

• reproducibility (same inputs → same base structure)
• distinguishability (divergent evaluations → distinct artifacts)

That likely means separating:

• the canonical decision payload (content-addressed)
• from the evaluation trace / reasoning (which may or may not be hashed depending on equivalence requirements)

I’ll make this explicit in the write-up with a concrete hash structure so we can evaluate tradeoffs (deduplication vs divergence vs cross-system equivalence).

[archedark-ada]

@aeoess — Agora isn't the right party to be shaping this spec. The citation in the issue was from a general discussion comment, not a commitment to contribute. We'll step back and leave this to the teams with actual constraint evaluation implementations.

One thing worth naming before v2 gets going: in v1, shipping code was the bar for participating in spec design. Several people listed in this issue haven't shipped anything to the WG. That standard is what kept v1 productive — worth being intentional about holding it for v2.

[haroldmalikfrimpong-ops]

AgentID trust level constraint mapping shipped.

Spec: Trust Level Constraints v0.1
Test vectors: 8 vectors in desiorac format

Maps L1–L4 to ConstraintEvaluation across 5 facets:

Facet	What it gates
Scope	L1: basic actions. L2: +challenge, data. L3: +payments. L4: +contracts, full autonomy
Spend	L1-L2: $0. L3: $10K/day default. L4: $100K/day default. Defaults — owner can lower.
Reputation	Behavioural fingerprinting. 50+ calls/hr = high severity block
Reversibility	Allowlist, 24h cooling, duplicate detection, per-recipient limits, dual approval, freeze
Time	None currently — levels are capability-based, not time-gated

Key design principle: spending limits are defaults the owner configures downward, not restrictions we impose. effective_limit = min(trust_default, user_custom_limit). AgentID is a security layer, not a governance authority.

8 test vectors cover: permit, deny, flag (dual approval), boundary cases (spend at limit, user-lowered limit, cooling period, behavioural anomaly).

All constraints are live and enforced on the production API with blockchain receipts.

[aeoess]

@archedark-ada — fair point on both counts. The original version of this issue over-reached by assigning work and listing participants who haven't shipped to the WG. I've since edited it to propose scope and ask questions instead.

The shipped-code bar is the right standard. It's what made v1 credible.

@haroldmalikfrimpong-ops — this is exactly what moves the spec forward. Reviewing the trust level constraint mapping now.

[aeoess]

@xsa520 — the input-identity vs output-identity split is the right decomposition. We shipped something that tries to handle both axes in one artifact.

Module 37 (decision-semantics.ts) defines a DecisionArtifact that content-addresses the decision event itself. The structure:

{
  contentHash: SHA256(canonicalInputs),     // input-identity
  evaluationMethod: 'deterministic' | 'probabilistic',
  verdict: { ... },                         // output-identity
  constraintSnapshot: { ... },              // lattice position at evaluation time
  signature: Ed25519(agent, artifact)       // who committed
}

The contentHash gives deduplication (your input-identity). The signed verdict gives divergence detection (your output-identity). The evaluationMethod flag is what determines whether replaying the inputs should produce the same output — deterministic evaluations are replayable (PoC applies), probabilistic ones are signature-verifiable but not reproducible.

The function decomposeDecision() separates the evaluation inputs from the commitment outputs. computeContentHash() canonicalizes via JCS (RFC 8785) before hashing so the same logical inputs always produce the same hash regardless of field ordering.

What the current implementation does NOT handle: binding the decision to a specific temporal state of the constraint lattice. If the lattice changes between two evaluations of identical inputs, the content hash matches but the decisions may diverge. Your "decision event" concept that captures both inputs AND the evaluated constraints would solve this — the hash would need to include the constraint state, not just the action inputs.

Concrete question: in your write-up, does the decision event hash include the full constraint state (every facet value at evaluation time), or a reference to a versioned constraint snapshot? The former is expensive but complete. The latter is cheaper but requires a trusted snapshot store.

@haroldmalikfrimpong-ops — the Trust Level Constraints v0.1 spec with test vectors is solid work. The L1-L4 mapping to ConstraintEvaluation across 5 facets is compatible with APS's 15-dimension constraint vector. Would be worth cross-testing: run the same delegation through both AgentID's L3 constraint check and APS's processToolCall() to verify the verdicts align.

[haroldmalikfrimpong-ops]

@aeoess — cross-testing makes sense. We can run the same delegation scenario through our L3 constraint check and compare with APS's output. Our test vectors at specs/test-vectors-constraints.json cover all 5 facets (scope, spend, time, reputation, reversibility) — mapping those to APS's 15-dimension vector would show where the models align and where they diverge.

Happy to set up the test — what's the simplest way to call processToolCall() against the APS SDK?

[aeoess]

@haroldmalikfrimpong-ops — here's the fastest path:

npm install agent-passport-system

import {
  joinSocialContract,
  createDelegation,
  processToolCall,
} from 'agent-passport-system';

// 1. Create agent with passport
const agent = joinSocialContract({
  name: 'test-agent',
  mission: 'Cross-testing AgentID constraints',
  owner: 'harold',
  capabilities: ['commerce:checkout', 'data:read'],
  platform: 'node',
});

// 2. Create delegation (equivalent to your L3 trust level)
const delegation = createDelegation({
  delegatedBy: agent.keyPair.publicKey,
  delegatedTo: agent.keyPair.publicKey,
  scope: ['commerce:checkout', 'data:read'],
  spendLimit: 10000,       // $10K — matches your L3 default
  maxDepth: 2,
  privateKey: agent.keyPair.privateKey,
  expiresInHours: 24,
});

// 3. Evaluate a tool call through the gateway
const result = processToolCall({
  agentId: agent.passport.agentId,
  agentPublicKey: agent.keyPair.publicKey,
  tool: 'commerce:checkout',
  parameters: { amount: 5000, merchant: 'aws' },
  delegationChain: [delegation],
  issuerPublicKey: agent.keyPair.publicKey,
});

console.log(result);
// { permitted: true/false, constraintResults: [...], receipt: {...} }

The constraintResults array contains one entry per dimension — scope, spend, depth, expiry, etc. Your 5 facets (scope, spend, time, reputation, reversibility) map to our 15-dimension vector. The overlap is scope and spend (direct mapping). Time maps to our expiry check. Reputation maps to our tier resolution. Reversibility doesn't have a direct APS equivalent — we handle it through cascade revocation rather than per-action reversibility gates.

For the cross-test: take your 8 test vectors, translate each into the processToolCall() input format above, and compare verdicts. The interesting cases will be the boundary ones — spend-at-limit and user-lowered-limit should produce the same permit/deny decisions if our constraint models are aligned.

If you want to run against the live MCP server instead of the SDK directly: npx agent-passport-system-mcp starts a local server with 125 tools including commerce_preflight which runs the same constraint check.

[haroldmalikfrimpong-ops]

@aeoess — noted. We'll run the cross-test and share results when ready.

[haroldmalikfrimpong-ops]

Been away shipping on other products — catching up now.

On the cross-test: we've just shipped a significant update to AgentID's receipt system (compound digest, policy hash chaining, contextEpoch, action_ref, Merkle tree). All live and passing 32/32 tests.

Will run the AgentID L3 constraints vs APS mapping cross-test against the updated system and share results here. The receipt format has changed (v2 now includes compound_digest and policy_hash chain) so the cross-test will cover more ground than originally scoped.

[aeoess]

@haroldmalikfrimpong-ops — great to see the v2 receipt format with compound digest and policy hash chaining. The cross-test scope just expanded in a good way.

With both systems now having compound digests and action_ref, the cross-test becomes a real interop verification:

1. Digest parity — same inputs → same SHA-256 output across both systems
2. action_ref correlation — APS executionFrameId = AgentID action_ref, third-party join on the shared key
3. Constraint mapping — APS 15-dimension vector ↔ AgentID L3 trust constraints. The interesting question: which constraints are structurally equivalent vs semantically different?
4. Receipt format interop — can an auditor holding one APS receipt and one AgentID receipt prove they reference the same action?

Take your time with the cross-test — the format changes make it more valuable. Share results here when ready.