Add MCP authorization conformance suite v2

README.md

@@ -1,10 +1,18 @@
 # AgentPass
 
-**Runtime control, durable assurance, and observability for AI agent actions.**
+**Open interoperability and conformance for action-bound AI agent authorization.**
 
-AgentPass is an action-control boundary and evidence layer that sits outside
-the agent loop. It checks tool calls before execution and preserves durable
-records of what was proposed, authorized, executed, observed, and assessed.
+AgentPass is an open reference implementation, action-control boundary, and
+conformance project that sits outside the agent loop. It checks tool calls
+before execution and preserves durable records of what was proposed,
+authorized, executed, observed, and assessed.
+
+Its standards role is deliberately narrow: compose existing identity,
+delegation, workload, policy, and signing standards into independently
+verifiable evidence for a specific agent action. AgentPass does not define a
+general agent identity or replace IAM, OAuth, MCP authorization, AuthZEN,
+SPIFFE, WIMSE, OPA, Cedar, or provider business authorization. See
+[Interoperability Positioning](docs/interoperability-positioning.md).
 
 ```text
 Agent proposes tool call -> AgentPass checks policy + state -> allow / deny / challenge
@@ -244,6 +252,10 @@ contracts, receipts, or standards alignment:
 - Receipt profiles: [`docs/receipt-profiles.md`](docs/receipt-profiles.md)
 - Agentic identity standards crosswalk and executable MCP vector:
   [`docs/agentic-identity-standards-crosswalk.md`](docs/agentic-identity-standards-crosswalk.md)
+- MCP authorization conformance suite v2:
+  [`fixtures/mcp-authorization-conformance-v2/`](fixtures/mcp-authorization-conformance-v2/)
+- Interoperability positioning and contribution boundary:
+  [`docs/interoperability-positioning.md`](docs/interoperability-positioning.md)
 - Community RFCs: [`docs/proposals/`](docs/proposals/)
 - Intent observability execution plan:
   [Intent Observability & Assurance](https://github.com/users/dinpd/projects/2)
@@ -378,16 +390,19 @@ AgentPass currently includes:
 
 ## Roadmap Focus
 
-Near-term work has three public tracks:
+Near-term work has four public tracks:
 
-1. Production-grade intent observability and assurance: canonical evidence
+1. Action-bound authorization interoperability: executable MCP conformance
+   cases, provider-verifier behavior, negative fixtures, implementation
+   profiles, and demonstrations with independent implementations.
+2. Production-grade intent observability and assurance: canonical evidence
    contracts, action-boundary lifecycle hardening, OpenTelemetry causal
    tracing, correlation, measurement profiles, independent control assessment,
    complete population accounting, immutable assessment revisions, privacy,
    migration, and conformance.
-2. Provider trust enforcement with production receipts and contract drift
+3. Provider trust enforcement with production receipts and contract drift
    detection.
-3. Framework and workflow wrappers selected from adopter demand.
+4. Framework and workflow wrappers selected from adopter demand.
 
 The [Action Gate Roadmap](docs/action-gate-roadmap.md) tracks adopter-facing
 product demonstrations. The public

docs/agentic-identity-standards-crosswalk.md

@@ -117,6 +117,12 @@ particular, the AgentPass evidence model should be compared with both active
 individual IETF drafts that already address authorization evidence and
 high-risk action receipts.
 
+The project's positioning and testable success criteria are defined in
+[Interoperability Positioning](interoperability-positioning.md). The
+[MCP Authorization Conformance Suite v2](../fixtures/mcp-authorization-conformance-v2/)
+turns this boundary into executable positive, trust-failure, lifecycle, and
+closure cases.
+
 The desired implementation seam is:
 
 ```text

docs/interoperability-positioning.md

@@ -0,0 +1,71 @@
+# AgentPass Interoperability Positioning
+
+AgentPass is an open reference implementation and conformance project for
+action-bound authorization of AI agent operations.
+
+Its focus is the provider trust boundary:
+
+> Can a provider independently verify that this exact action, with these
+> arguments, was authorized for this principal, agent, runtime, delegation,
+> policy, approval, audience, and time window—and handle it without unsafe
+> replay?
+
+## What AgentPass Composes
+
+AgentPass reuses existing work rather than defining a general agent identity:
+
+- OpenID Connect and OAuth establish principals, clients, delegation,
+  resources, and audiences.
+- SPIFFE and WIMSE address executing workload identity and workload-to-workload
+  security.
+- AuthZEN separates policy enforcement from policy decision and is developing
+  approval and MCP authorization mappings.
+- MCP authorization secures access to MCP servers.
+- JOSE/JWKS, COSE, and HTTP Message Signatures provide established signing and
+  request-integrity building blocks.
+- Shared Signals can communicate lifecycle, risk, and revocation changes.
+- Provenance and receipt formats can describe what happened after dispatch.
+
+AgentPass experiments at the seam between those layers: canonical action
+binding, signed authorization evidence, independent provider verification,
+single-use or retry-safe consumption, and linked execution closure.
+
+## Contribution Boundary
+
+AgentPass should contribute, in this order:
+
+1. field mappings and explicit assumptions;
+2. positive and negative interoperability vectors;
+3. reference verifiers and provider middleware;
+4. conformance tests and implementation reports;
+5. narrowly scoped profiles where existing standards leave choices open; and
+6. proposed new vocabulary only when multiple implementations demonstrate a
+   gap that cannot be addressed by profiling existing standards.
+
+AgentPass should not present itself as an agent identity provider, universal
+agent registry, new DID method, OAuth replacement, or complete authorization
+standard.
+
+## Evidence of Progress
+
+Documentation alone is not the success criterion. The useful milestones are:
+
+- independent implementations canonicalize the same action identically;
+- providers accept the same valid evidence and reject the same invalid cases;
+- replay, retry, revocation, and partial execution have explicit outcomes;
+- execution closure remains linked to the authorized action; and
+- implementation feedback is contributed to the relevant standards groups.
+
+The strongest milestone is two independent providers passing the same public
+suite without AgentPass-specific coordination at runtime.
+
+## Current Public Artifacts
+
+- [Agentic Identity Standards Crosswalk](agentic-identity-standards-crosswalk.md)
+- [MCP Authorization Interoperability Vector v1](../fixtures/mcp-authorization-interoperability-v1/)
+- [MCP Authorization Conformance Suite v2](../fixtures/mcp-authorization-conformance-v2/)
+- [Provider receipt profiles](receipt-profiles.md)
+
+These artifacts are experimental unless explicitly identified as an adopted
+external standard. Passing an AgentPass suite is not certification by IETF,
+OpenID, W3C, SPIFFE, NIST, ISO, or the MCP project.

docs/standards-alignment.md

@@ -1,14 +1,21 @@
 # Standards Alignment
 
-AgentPass should align with distributed identity standards without becoming a
-replacement for them.
+AgentPass aligns with distributed identity and authorization standards as an
+open reference implementation and conformance project for action-bound
+authorization. It does not create a general agent identity or replace those
+standards. The detailed project boundary is in
+[Interoperability Positioning](interoperability-positioning.md).
 
 For the current field-level mapping across AuthZEN, OAuth, WIMSE, SPIFFE, MCP,
 authorization-evidence proposals, and execution provenance, see the
 [Agentic Identity Standards Crosswalk](agentic-identity-standards-crosswalk.md).
 Its companion
 [MCP authorization interoperability vector](../fixtures/mcp-authorization-interoperability-v1/)
 provides deterministic positive, mutation, audience, and replay cases.
+The broader
+[MCP Authorization Conformance Suite v2](../fixtures/mcp-authorization-conformance-v2/)
+adds JWS/JWKS trust, delegation, runtime, policy, approval, revocation, retry,
+and partial-execution cases.
 
 The core distinction is:
 

fixtures/mcp-authorization-conformance-v2/README.md

@@ -0,0 +1,37 @@
+# MCP Authorization Conformance Suite v2
+
+This directory contains an experimental, non-normative conformance suite for
+action-bound authorization of a state-changing MCP `tools/call`.
+
+Run it from the repository root:
+
+```bash
+python scripts/run_mcp_authorization_conformance_v2.py \
+  fixtures/mcp-authorization-conformance-v2/vector.json
+```
+
+The runner exits with status `0` only when every case matches its expected
+portable failure codes and execution-closure behavior. It covers:
+
+- RS256 JWS verification against an in-memory JWKS;
+- trusted issuer, provider audience, algorithm, and key selection;
+- exact MCP action and provider-owned field bindings;
+- runtime identity, delegation attenuation, policy, approval, and risk state;
+- unknown signing-key rejection;
+- idempotent replay of a prior completed result; and
+- partial-then-complete execution closure correlation.
+
+The runner generates fresh RSA keys in memory. It never writes or prints a
+private key, JWS, or operational credential. All fixture identifiers use
+reserved `.test` domains or visibly synthetic values.
+
+## Interpretation
+
+Passing this suite means an implementation agrees with these AgentPass
+experimental cases. It is not certification against an IETF, OpenID, W3C, or
+MCP standard and does not make the AgentPass evidence fields standardized.
+
+The partial-execution case demonstrates correlation semantics only. A real
+provider must define whether a partial operation is retryable, compensatable,
+or terminal and must enforce that decision atomically with its own idempotency
+state.