AuthZEN and the Blueprint: Reference

This note holds the reference material for the three parts of AuthZEN and the Blueprint. I edit two of the AuthZEN profiles it maps, ARAP and AROP, and write the Mission-Bound Authorization drafts. Mission status and test claims come from the drafts’ own conformance manifest and implementation tracker. A test there is not a conformance, interoperability, or production claim.

In the status columns, Final means a finished specification. A working group draft is adopted and still changing. An individual draft is submitted by its authors but not adopted. An editor’s copy is unsubmitted.

Section numbers cite the Blueprint Alliance whitepaper as retrieved on September 25, 2026, which carries no version identifier.

The Full Gap Map

The table lists every Blueprint component the series touches, what it needs on the wire, and the AuthZEN work that supplies it, as of September 2026.

The access-review and separation-of-duties rows rest on AuthZEN search. Access reviews in section 3.2.2 are “automated, continuous entitlement scanning,” and separation of duties asks whether one agent can both create and approve a payment. Both are search questions. AuthZEN search asks the same PDP that makes runtime decisions which resources an agent can act on, and which subjects can approve a payment, so the review reads the policy the gateways enforce.

What the Blueprint Asks For

The whitepaper marks other limits too. It says treating a literal prompt as the sole trigger “is aspirational” (3.2.1), and that fully automated recovery workflows “remain a target state” (3.4.2). Its kill switch targets the agent. “Every agent, regardless of vendor or platform, needs a targeted kill switch that can suspend, quarantine, or terminate it in real time, with a clear way back.” It also requires an execution boundary “that supports granular session-level control,” so an agent can be paused “without collateral impact to adjacent workflows,” and its narrowest listed lever is session token revocation, “severing the active runtime connection of a single, specific interaction string without necessarily deleting the agent’s broad identity” (3.4.1.1).

The Refund on the AuthZEN Wire

Here is part three’s refund call in full, as the MCP gateway first sends it under the Mission, before the supervisor’s approval.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
X-Request-ID: 7f3c2a1e-9b4d-4e8a-b5c6-2d1f0e9a8b7c

{
  "subject": {
    "type": "user",
    "id": "rep_4471",
    "properties": { "iss": "https://idp.example.com" }
  },
  "action": {
    "name": "issue_refund",
    "properties": {
      "parameters": { "order_id": "ord_58213", "amount_usd": "480.00" },
      "parameter_digest": "sha-256:7gwoJvIbk--f5RieqjNQDpDRgpkE9DmdH52GB2nKU0M"
    }
  },
  "resource": {
    "type": "order",
    "id": "ord_58213",
    "properties": { "audience": "https://mcp.commerce.example.com" }
  },
  "context": {
    "agent": "support-agent",
    "mission": {
      "id": "msn_T7kQ2vR9xL4mN8pB3sW6yC1d",
      "issuer": "https://as.example.com"
    },
    "mission_state_observation": {
      "state": "active",
      "mode": "fresh",
      "freshness_at": "2026-09-25T16:02:11Z"
    },
    "actor": { "client_id": "support-agent" },
    "credential": {
      "issuer": "https://as.example.com",
      "expires_at": "2026-09-25T17:02:11Z"
    }
  }
}

The COAZ mapping from part two produces the subject, the action with its parameters, the resource, and context.agent. The Mission AuthZEN profile adds the rest.

• context.mission names the Mission by id and issuer, taken from the Mission-bound access token, and subject.properties.iss makes the rep’s sub unambiguous across issuers.
• context.mission_state_observation tells the PDP how fresh the PEP’s view of the Mission’s state is (fresh, cached, or event_driven). The PDP’s own view wins wherever it can consult the Mission’s state directly, and the runtime profile fails closed outside a published staleness bound.
• action.properties.parameter_digest binds a permit to these exact arguments. The PDP recomputes it over the supplied parameters, and the executing enforcement point recomputes it immediately before acting, so a permit for a $480 refund on order ord_58213 cannot be moved to a different order or amount. Preventing a duplicate refund with identical parameters is a separate idempotency control.
• resource.properties.audience is the gateway’s protected-resource identifier, the MCP server, which the PDP matches against the Mission’s approved resource. That leaves resource.type and resource.id for the order.
• context.credential carries facts the PEP has already validated about the presented token, and context.actor carries the agent and its delegation chain.

After the supervisor approves, the MCP gateway asks again. This is the part of that second request the Mission and the approval add to COAZ’s mapping:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "action": {
    "name": "issue_refund",
    "properties": {
      "parameters": { "order_id": "ord_58213", "amount_usd": "480.00" },
      "parameter_digest": "sha-256:7gwoJvIbk--f5RieqjNQDpDRgpkE9DmdH52GB2nKU0M"
    }
  },
  "context": {
    "mission": {
      "id": "msn_T7kQ2vR9xL4mN8pB3sW6yC1d",
      "issuer": "https://as.example.com"
    },
    "mission_state_observation": {
      "state": "active",
      "mode": "fresh",
      "freshness_at": "2026-09-25T16:06:40Z"
    },
    "approval": { "id": "apr_9Hc3Lw7Qx2Nf5Tb8" }
  }
}

The PDP checks the order and amount against the Mission’s constraints, which ties the refund to the approved task, and checks that the supervisor’s approval applies and has not been revoked. Its permit states the conditions for relying on it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "decision": true,
  "context": {
    "evaluation_id": "dec_4Rn8Kq2Wv6Ls1Yp9Tf3Hb7Xm",
    "conditions": {
      "parameter_digest": "sha-256:7gwoJvIbk--f5RieqjNQDpDRgpkE9DmdH52GB2nKU0M",
      "valid_until": "2026-09-25T16:11:40Z",
      "use_limit": 1
    }
  }
}

The permit covers these exact arguments, expires at valid_until, and can be used once.

The profile defines the denial reasons a PDP returns (out_of_authority, approval_required, stale_state, mission_inactive, parameter_violation, and others), which companion profiles may extend. Only out_of_authority and approval_required may be marked requestable through ARAP. Every other reason the profile itself defines is non-requestable, though some, such as stale_state, invite a retry. The $480 refund is the approval_required case. A refund on another order is out_of_authority. A missing role or relationship can be repaired without changing the Mission, but an operation outside the Mission’s approved boundary needs newly approved authority, through a Mission expansion or an in-ceiling expansion where the progressive companion is deployed, not merely a broader ambient entitlement.

The profiles need a shared identity model, not just a shared field. The subject, the immediate OAuth client, the current actor, the delegation chain, and the agent a person originally approved are different identities, and the profiles project them differently today. The agent alone appears in three places. COAZ-MCP puts it in context.agent, the Mission profile in context.actor, and AROP in subject.properties.act and context.client_id. Some of that may reflect different enforcement positions, since context.actor carries a delegation chain that a single context.agent value cannot hold. The profiles should still converge, and the Mission profile, as an editor’s copy, is the easiest to change. Until they do, policy authors should map them into one internal model.

Open-World Discovery and Client Bookkeeping

This is the client’s side of the discovery loop that part two summarizes.

In a fixed integration, a developer configures the resource, authorization server, scopes, and approval path ahead of time. An open-world agent discovers some of them while working. The support agent may learn which payment processor handled the order only after reading it, then discover that processor’s charge-lookup tool, and later find that its token for the commerce platform covers order lookup but not a refund. The destination and the required authority become known at different steps.

Discovering a tool does not tell the client how to obtain authority to call it. A tool schema describes how to call issue_refund. It does not necessarily tell the client which grant will authorize these arguments. Protected Resource Metadata identifies authorization servers and can advertise scopes. An insufficient_scope challenge can identify missing scope, and MCP’s draft authorization specification allows operation-specific requirements that differ from the advertised list. Knowing the issuer and a scope name still does not supply the domain-specific fields needed to request authority for one order and amount. There is no universal scope-to-tool mapping. On the token side, the client has to run the resulting loop:

1. Discover the issuer and required authority through metadata or a rejected call’s challenge.
2. Request scopes or structured authorization details, handling consent, stronger authentication, or asynchronous approval where required.
3. Obtain a suitable token and retry only after establishing that the earlier attempt was rejected before execution.
4. Track which tokens cover which resources and operations, their expiry, and the additional grants needed as the task discovers another tool.

Finer grants need more precise bookkeeping. A token for one order does not cover another, and a token accepted by one payment service need not work at the next. Requesting broad access up front cuts the interruptions by giving the agent more standing authority, which gives up part of what the fine-grained design was for.

Each of those steps can also prompt the user. Consent to application access, stronger sign-in, and approval of a refund answer different questions, yet interrupt the same piece of work, and repeated prompts make the user reconstruct the task at each step or approve reflexively. Moving approval out of band changes where the wait happens but does not remove it.

Resource-side evaluation can reduce token churn and keep the tool’s meaning at the resource. Within an existing token’s bounds, the PEP can evaluate calls and broker exceptions through ARAP without making the client acquire a new credential for each action. It still needs OAuth access to a newly encountered resource. Checking every call does not require asking a person about every call. Where separate policy owners are involved, telling a request already covered by approved work from one that needs new authority takes a shared record of the task, which part three takes up.

Prompts in Three Deployments of the Ticket

This comparison supports part three’s discussion of a new call versus a new request for authority.

Three deployments of the same ticket show what each lever contributes. All three permit the same operations under the same constraints, authentication requirements, and exception thresholds, so the counts are results of this deployment, not protocol guarantees. The last column assumes both services recognize the task issuer and its authority vocabulary.

Policy and reusable approvals can already remove many prompts without unrestricted standing access. An enterprise PDP that permits order-specific operations from the requester, the customer relationship, the order state, an amount ceiling, and a time limit settles the refund expansion without asking anyone. What remains is carrying the boundary and lifecycle of approved work across independently implemented systems, here a commerce platform and a support service under separate policy authorities. A task record makes that relationship explicit, so both services evaluate the same approved-work boundary instead of each reconstructing it, while each still decides under its own policy whether to accept the record as evidence. Where every service can establish the relationship on its own, the middle column needs only the supervisor, and the task record’s value is the shared lifecycle, not a lower count. The record also tells ARAP’s shared Access Request Service which requests are already covered by approved work.

The Blueprint’s Requirements, Mapped

Authority-versus-action enforcement is only as precise as the authority set’s vocabulary, so a deployment can correctly enforce an authority set that was written too broadly or too narrowly. Behavioral drift inside an approved envelope remains a job for the Blueprint’s monitoring pillar.

What a Mission Trial Needs

Part three’s revocation test needs five drafts: the Mission OAuth binding, the Mission Resource Access Profile, Mission-Bound Runtime Enforcement, Mission Status and Lifecycle, and the Mission AuthZEN profile. The containment tests add the Containment companion. The downgrade step relies on the Mission AuthZEN profile’s rule that a PDP refuses an in-scope request lacking Mission context, recording it as mission_context_missing, rather than evaluating it against non-Mission policy alone. Composing part two’s Token Issuance profile with the Mission OAuth binding at the same token endpoint is not yet specified by either document.

Vendor Commitments for the Two-Vendor Refund Test

These are the written commitments an enterprise can ask each gateway vendor for alongside part three’s test.

Telemetry and Rollout

OCSF 1.9.0 defines a delegation object for “a durable authorization context that a principal issues to a delegate,” with an issuer-generated uid, an issuer_uid, and a parent_uid. Any task record with an issuer fits it, a Mission included, and I have proposed an informative mapping. Lifecycle state and expiry have no standard members yet.

In the whitepaper’s rollout order, a task record enters at step four, “Layer authorization,” as the task layer over the fine-grained and relationship-based controls the whitepaper wants “in place before intent-based authorization can correctly scope down agent permissions.” It does not replace them. Its identifier also serves the first step, unified logging, through the OCSF object above.