The handbook’s design rule is that the architecture introduces one primitive, the governed record of the approved task, and composes the rest from existing work. That rule is only checkable against a map. This appendix is that map: the OAuth specifications and drafts, WIMSE documents, and OpenID Foundation work with a concrete relationship to the architecture. Each entry names the relationship, the use case, and, where one exists, the important delta. Where substituting a neighboring object for the approved task would break the architecture’s claim, the hazard is stated plainly.
Statuses follow the public record as of July 15, 2026, the same reconciliation date the Reference tracks. The map is exhaustive for the active OAuth and WIMSE working-group queues on that date. It is intentionally selective for ratified RFCs, individual Internet-Drafts, and OpenID specifications: those sections include documents with a concrete architectural join, a material overlap, or a common substitution hazard. This is a design map, not a registry dump.
Statuses move, so the links are the authority for current publication state. Relationships move more slowly. They describe how the Mission draft family uses or compares with a neighboring document. They do not imply endorsement or adoption by that document’s authors or working group.
How to read this map
The tables use one primary relationship for each entry:
| Relationship | Meaning |
|---|---|
| Required substrate | At least one family profile depends on it normatively |
| Defined composition | A family profile or this handbook defines a concrete join to it |
| Optional composition | It can supply a layer or rail, but the architecture does not require it |
| Peer binding | It is an alternate substrate for which the family defines a Mission binding |
| Adjacent | It works in overlapping territory, but no concrete join is defined |
| Not a substitute | It remains useful for its own object, but cannot stand in for the governed task |
Two conventions carry the honesty. A delta states what the neighboring document does differently or leaves to deployment policy, so composition claims stay falsifiable. A conflict if substituted flag marks the places where asking that neighboring object to stand in for the governed task would fail the litmus test. The comparison table collects the highest-impact cases.
OAuth: the ratified substrate
OAuth is the flagship binding because it supplies the most complete deployed substrate. The required dependencies of the reference security architecture are ratified RFCs or finalized OpenID specifications. Experimental and advanced companions may additionally depend on Internet-Drafts, and those dependencies are identified below.
| Spec | Relationship | How it composes, and the deltas |
|---|---|---|
| RFC 6749 / RFC 6750 OAuth 2.0 core and bearer usage | Required substrate | The deployment base and the reason OAuth is the first binding. Delta: OAuth defines credential and grant lifecycles, not a cross-audience lifecycle for the approved work |
| RFC 9126 Pushed Authorization Requests | Required substrate | The submission channel. The mission_intent parameter rides PAR, keeping the proposal off the browser-visible front channel and binding the resulting request_uri to the client before approval |
| RFC 9396 Rich Authorization Requests | Required substrate | The Authority Set serialization. Derived entries are authorization_details, never free text. Delta: RAR defines extensible authorization-detail types but not who owns their ontology. The RAR-type metadata draft and AAuth’s R3 explore resource-declared semantics |
| RFC 7519 / RFC 7515 JWT and JWS, with RFC 9068 JWT access tokens | Required substrate | The carrier. The mission claim, integrity-anchor envelopes, Mandate, and Consent Evidence use JWT or JWS artifacts |
| RFC 8785 JSON Canonicalization | Required substrate | intent_hash, authority_hash, and the permit’s parameter_digest are SHA-256 over JCS-canonical bytes, making the commitments reproducible |
| RFC 8693 Token Exchange | Required substrate | The delegation plumbing. Conflict if substituted: RFC 8693 leaves output-token scope and linkage to authorization-server policy; it does not require a narrow-only subset proof. Child Missions and offline attenuation add that invariant and its evidence |
| RFC 7662 Token Introspection, with RFC 9701 JWT responses | Required substrate | One accepted freshness source. The Mission profile extends the introspection result with current Mission state alongside token validity |
| RFC 7009 Token Revocation | Defined composition | Revokes a token and, where the server supports it, related tokens or the underlying grant. Delta: its subject is still one authorization server’s token or grant, not the approved task projected across issuers and audiences |
| RFC 8414 AS metadata / RFC 9728 protected resource metadata | Required substrate | Discovery. Mission support is advertised in AS metadata, and mission_constraints_supported lives in protected-resource metadata as one ontology-supply mechanism |
| RFC 9449 DPoP / RFC 8705 mTLS, with RFC 7800 confirmation | Required substrate | Sender constraint. Mission-bound tokens are sender-constrained, and the runtime permit binds the same cnf key, so stealing the token alone is insufficient |
| RFC 8707 Resource Indicators | Required substrate | Audience scoping. The family profiles single-audience narrowing when gated and ungated authority must be split across tokens |
| RFC 9470 Step-Up Authentication | Defined composition | The authentication-strength grain of the graduated challenge family, raised for an action inside an approved Mission without widening authority |
| RFC 7523 JWT client assertions | Required substrate | Client authentication and the JWT assertion rail used by the instance-identity substrate |
| RFC 7591 Dynamic Client Registration | Optional composition | Registers clients. Delta: registration identifies and configures a client; the Agent Deployment registry separately governs what may run |
| RFC 7636 PKCE and RFC 9700 Security BCP | Required substrate | The hardening baseline for the applicable OAuth flows |
Beyond the OAuth registry, four wider IETF rails carry family capabilities:
| Rail | Relationship | How it composes |
|---|---|---|
| RFC 8417 Security Event Tokens, RFC 8935/RFC 8936 delivery, RFC 9493 subject identifiers | Required substrate | Lifecycle Signals are SETs with Mission subjects, pushed and polled on the standard delivery rails |
| RFC 9943 SCITT architecture, with the SCRAPI draft | Required substrate | The audit profile registers Mission evidence as Signed Statements in a transparency service, making inclusion independently verifiable |
| RFC 9421 HTTP Message Signatures | Required substrate (AAuth binding) | The request-integrity rail used by the AAuth substrate |
| RFC 9635 GNAP | Adjacent | The clean-slate delegation protocol. Its grant negotiation and grant-management continuation are close analogs to shaping and lifecycle. Delta: GNAP does not define the Mission-specific integrity anchors, narrow-only child-task derivation, or cross-substrate task lifecycle. No GNAP binding has been authored; the substrate contract states what one would have to supply |
OAuth: the working-group drafts
The OAuth working group’s sixteen active or IESG-stage documents as of July 15, 2026, mapped in full, plus the recently published SD-JWT RFC:
| Draft | Status | Relationship | How it composes, and the deltas |
|---|---|---|---|
| OAuth 2.1 | WG document | Optional composition | Consolidates the substrate: PKCE is required for authorization-code clients, while the implicit and password grants are omitted. The family’s PAR-first and sender-constraint requirements remain additional profile rules |
| Identity chaining across domains | RFC Editor queue | Required substrate for an advanced companion | Cross-Domain Projection profiles its single-hop, audience-scoped grant so another trust domain can honor a Mission. That companion should not be treated as stable ahead of this dependency |
| Identity Assertion Authorization Grant (ID-JAG) | WG document | Required substrate for an advanced companion | The IdP-brokered leg of Cross-Domain Projection. The family gates ID-JAG issuance on current Mission state so the cross-domain credential inherits the derivation kill switch |
| Transaction Tokens | In WG last call | Optional composition | Carries seconds-scale identity and authorization context through an intra-domain call chain. A hop may carry both a Txn-Token for transaction context and a Mission-bound grant for the durable approved task. Conflict if substituted: a Txn-Token does not define the approval, integrity anchors, or lifecycle of that task, because those are outside its job |
| Attestation-Based Client Authentication | WG document | Defined composition | The attestation rail beneath Agent Deployment: how a client instance proves platform and posture when authenticating |
| Token Status List | RFC Editor queue | Optional composition | Mission Status defines an optional Mission Status List using the status-list shape. Delta: a token’s referenced status describes that token; a Mission status entry describes whether the work remains authorized |
| SD-JWT selective disclosure (RFC 9901) | Published RFC | Required substrate for an optional feature | The Mandate’s minimization tool: a holder can disclose only the committed Mission facts a verifier needs |
| SD-JWT VC | With the IESG | Adjacent | A credential-shaped use of the same disclosure mechanics. It may carry evidence about a Mission, but presenting it is not by itself a Mission authorization decision |
| Refresh Token and Authorization Expiration | WG document | Optional composition | Defines interoperable expiration semantics for refresh tokens and authorizations. The family separately caps derived lifetimes with expires_at and gates refresh on current Mission state |
| OAuth SPIFFE Client Authentication | WG document | Optional composition | The OAuth-to-workload-identity join: a SPIFFE credential authenticates the client to which a Mission-bound token is issued |
| Client ID Metadata Document | WG document | Optional composition | Provides fetchable client metadata without prior registration. It can be an identity and metadata input to Agent Deployment; the registry still makes the governance decision |
| Cross-device flows BCP | RFC Editor queue | Optional composition | Supplies the threat model for a decoupled approval interaction when the Approver uses another device |
| First-party applications | In WG last call | Adjacent | A first-party application interaction model with no Mission-specific join |
| Browser-based apps BCP, Security BCP updates, JWT BCP update, and the RFC 7523 update | RFC Editor queue or active review | Defined composition | The substrate’s maintenance train. Applicable updates flow through because the family profiles the base mechanisms rather than forks them |
OAuth: the individual drafts in the family’s orbit
The proposals the family answers, profiles, or supplies an object to. This section is selective, not a census of individual submissions. The family’s own twenty-eight documents are cataloged in the Reference’s draft-family table and are not repeated here. McGuinness drafts listed below are separate identity and delegation prerequisites, not members of that Mission document set.
| Draft | Relationship | How it composes, and the deltas |
|---|---|---|
| AI agent authorization best practices (draft-klrc-aiagent-auth) | Adjacent | Its Agent Mission section expects a mission to be translated into authorization requirements but leaves that process out of scope. The Mission family proposes one such process; it is an answer to the gap, not a dependency of this draft |
| AAuth Protocol (Hardt) | Peer binding | This proposed clean-slate agent protocol has a first-class mission layer. The family’s AAuth binding maps the Mission model to the Person Server while preserving issuance gating |
| AAuth Rich Resource Requests (R3) | Defined composition | The resource-declared direction: a resource publishes operation semantics and requests commit to them. The AAuth binding carries that shape. Delta: OAuth RAR does not prescribe the same ontology direction |
| RAR-type metadata (Zehavi) | Defined composition | An OAuth-side discovery mechanism for machine-readable RAR types. The family can use those declarations during derivation, disclosure, and insufficient_authorization_details remediation |
| Transaction-specific challenges (Rosomakho) | Defined composition | The single-transaction grain of the graduated challenge family, beside scope, authorization-detail, and authentication-strength challenges |
| Deferred token response (Gerber) | Required substrate for an advanced companion | Deferred Approval profiles its pending response and deferral code so approval can complete asynchronously |
| Attenuating agent tokens (Niyikiza) | Required substrate for an experimental companion | Supplies self-proving offline delegation chains; the Mission attenuation profile additionally binds each chain to approved authority and the narrow-only invariant |
| Transaction token chaining (Fletcher) | Optional composition | Carries context across transaction-token hops, including Mission context within one trust domain |
| RAR evaluation with Cedar (Cecchetti) | Optional composition | Defines Cedar evaluation of authorization_details, a policy-engine-specific companion to the engine-neutral AuthZEN binding |
| Credential brokers for agents (CB4A) (Hartman) | Optional composition | Supplies the custody pattern: the broker holds credentials and the agent does not. A Mission-aware deployment additionally gates broker issuance and action requests on current Mission authority |
| Actor Profile, with Actor-Signed Hop Proofs and Actor Receipts | Required substrate for optional delegation | Defines act-chain discipline and optional per-hop proof and provenance. The issuance core’s only Internet-Draft dependency is confined to its optional delegation capability |
| Identity Assertion Trust Framework | Required substrate for an advanced companion | Defines which assertions an issuer accepts, from whom, and under what proof for assertion-based cross-domain legs |
| Client Instance Assertion and AI Agent Instance Profile | Required substrate for optional instance identity | Identifies which instance runs, on what attested platform, and under which Agent Deployment. The authority part consumes that identity instead of redefining it |
| UMA 2.0 (Kantara Initiative) | Peer binding | The family’s experimental UMA binding carries Mission Intent through claims pushing, records the resource owner’s decision in the authorization assessment, and gates RPT issuance on Mission state. Delta: UMA’s permission ticket and persisted claims provide protocol continuity, not the Mission’s approved-task lifecycle |
OAuth: the emerging agent wave
A wave of individual drafts arrived through 2026, most still at revision 00 or 01, all addressing aspects of agent authorization. Early drafts move too fast for per-document verdicts to stay useful, so this selected table maps the wave by territory. Omission means only that no distinct architectural delta was identified in this snapshot. The evaluation frame never changes: the four substrate properties admit a design to the category, and all six back a defense claim.
| Territory | The drafts | The family’s read |
|---|---|---|
| Use cases and gaps | Agent authorization use cases and gap analysis (Chen) | The catalog Part 5 answers line by line: ten answered, one partial, one delegated |
| Delegation chains | Delegated authorization (Li), delegation chains (Liu), verifiable actor chains, DAAP (Mishra), async delegation handles (Zhu) | The territory of the Actor Profile, Child Missions, and offline attenuation. The evaluation is the narrow-only law: a chain must prove its narrowing, not just its custody |
| Agent revocation | Agent authorization explicit revocation (Chen) | The kill-switch territory. The family’s answer is possession-independent: revoke the task, and every future derivation dies with it |
| Intent, consent, and approval | Intent admission assertions (Jiang), native authorization via structured elicitation (Embesozzi), PACT (Valverde), user-mediated credential delivery (Emerson) | The shaping and approval territory: proposals as untrusted input, committed disclosures, an accountable Approver. Intent admission is the shaping profile’s exact question |
| Evidence and audit | Authorization evidence and audit trail (Liu), per-transaction posture consistency (Vicente) | The evidence territory: Decision and Execution Evidence joined on the Mission and registered into SCITT. The join key is the difference between an audit trail and a pile of logs |
| Scopes for AI workloads | AI model access scopes (Hemanth), scope aggregation for agent workflows (Jia) | The scope-explosion diagnosis, answered at task grain: consent to one Mission’s derived authority, not a thousand scopes |
| Transaction context for agents | Transaction tokens for agents (Araut), cross-domain transaction tokens (Liu) | The transaction-token row applies unchanged: context objects compose, and none of them is the approved task |
| Multi-agent collaboration | Multi-agent collaboration extension (Song) | The fan-out territory: Child Missions with lineage, explicit breadth and depth bounds, and cascade termination backed by lineage checks |
| Attestation for agents | ACAP (Yakung), attestation-based native-app authorization (Kahraman) | The Agent Deployment territory: attestation strengthens instance identity and deployment admission, but attestation alone authorizes no task |
None of these is dismissed by its placement here. Collectively, the drafts show pressure at the same seams: intent, delegation, lifecycle, runtime context, and evidence. That is evidence of shared problem pressure, not proof that the authors agree on one object or solution. The convergence argument makes the narrower claim.
WIMSE and the workload identity substrate
The three objects divide the estate: agent identity answers who, Agent Deployment answers what runs, and the Mission answers why. WIMSE and SPIFFE supply workload identity and authentication beneath the first two answers. The Mission family consumes that identity. It does not treat identity as task authority.
The WIMSE working group’s six active documents and one IESG-stage document are mapped first. The final three rows group all eleven related individual drafts listed by the working group on the snapshot date.
| Document | Status | Relationship | How it composes, and the deltas |
|---|---|---|---|
| WIMSE architecture | WG document | Optional composition | The workload identity model beneath the agent: how workloads obtain and use identities across systems |
| Workload Identifier, Workload Proof Token, and Workload Credentials | WG documents | Optional composition | The identity artifacts: how a workload is named, how it proves possession, and what carries the identity. They can supply client identity and proof beneath Mission-bound calls |
| Workload-to-workload authentication with HTTP signatures or mutual TLS | WG documents | Optional composition | Call-level authentication rails between services, beneath the policy enforcement point |
| Workload Identity Practices | With the IESG (Informational) | Adjacent | A survey of deployed workload-identity patterns that informs the layer beneath the architecture |
| SPIFFE (CNCF) | Deployed external specification | Optional composition | A deployed workload-identity system. A SPIFFE ID can identify an agent workload, and the OAuth SPIFFE client authentication draft joins that identity to OAuth client authentication |
| Agent applicability | Early individual draft | Adjacent | WIMSE applicability for AI agents maps workload-identity concepts into agent deployments. The Mission supplies task authority above that identity layer |
| Context, delegation, evidence, and bounded credentials | Early individual drafts | Adjacent | Execution Context Tokens, authorization-evidence records, cross-organizational delegation requirements, and condition-bounded credentials overlap the runtime, projection, and evidence layers. A Mission reference can provide a common approved-task join key, but no join is defined yet |
| Attestation, credential verification, and trust discovery | Early individual drafts | Adjacent | Trustworthy workload-identity extensions, heterogeneous credential verification, attestation in workload identity tokens, transitive attestation, workload attestation, and trust-domain discovery can strengthen who or what is running. They do not by themselves say which approved task authorizes an action |
The delta is the whole point: workload identity answers who or what is calling, not which approved task authorizes the call. Conflict if substituted: an estate that treats successful workload authentication as sufficient authorization has rebuilt a credential perimeter with stronger credentials. The Mission makes authority derive from approved work, and the AIdentity crosswalk carries the long form.
The OpenID Foundation
| Specification | Status | Relationship | How it composes, and the deltas |
|---|---|---|---|
| OpenID Connect Core and Discovery | Final | Optional composition | Common sources of Approver and Subject identity. The Mission records principals as issuer-scoped subject identifiers; OIDC is one way to establish them |
| AuthZEN Authorization API 1.0 | Final, January 2026 | Required substrate for the AuthZEN binding | The interoperable PEP-to-PDP decision wire. The family profile maps Mission state, capability identity, parameters, and evidence obligations into that wire while the runtime contract remains protocol-neutral |
| ARAP, Access Request and Approval Profile | AuthZEN WG draft | Optional composition | Turns a requestable denial into a governed request: the discovery loop’s ask leg. Delta: ARAP deliberately allows multiple completion modes; a Mission is one possible form of durable authorization state, not a requirement of ARAP |
| COAZ, the MCP authorization profile | AuthZEN WG draft | Optional composition | Maps MCP tools/call inputs into the AuthZEN decision shape so tool-boundary PEPs can construct the same policy request |
| AROP, the proposed OAuth binding of ARAP | Proposal, not a WG draft | Adjacent | Proposes to bind ARAP completion to OAuth issuance for token-resident authorization state. It is a pull request, not an adopted AuthZEN profile |
| Shared Signals Framework 1.0 with CAEP | Final | Required substrate for Lifecycle Signals | The push framework. Lifecycle Signals profiles an SSF transmitter and defines Mission lifecycle events. Conflict if substituted: identity, session, or credential-risk events do not by themselves terminate an approved task across every projection |
| CIBA Core 1.0 | Final | Optional composition | A decoupled interaction rail for reaching a person on another device. Conflict if substituted: CIBA completes an authentication and token-grant flow; it does not define the durable approved-task record, committed disclosure, or revision semantics. A Mission approval can use a CIBA-style interaction without confusing the two objects |
| FAPI 2.0 Security Profile | Final | Optional composition | A hardened OAuth profile with PAR and sender-constrained access tokens. A FAPI 2.0 estate already supplies much of the OAuth binding’s security baseline |
| OpenID Federation 1.0 | Final, February 2026 | Optional composition | Establishes multilateral trust and resolves trust chains to anchors. It can authenticate issuers and resolve keys for Mandate and evidence verification across domains |
| IPSIE | Working group, drafting | Adjacent | Develops enterprise identity interoperability for SSO, lifecycle, sessions, and signals. The Mission authority layer can ride above that fabric; IPSIE does not define task authorization |
| OpenID for Verifiable Credentials (OpenID4VCI and OpenID4VP) | Specification family | Adjacent | Defines credential issuance and presentation flows. The family shares SD-JWT disclosure mechanics but currently defines no OpenID4VC binding. If a deployment carries Mission facts on these rails, presentation alone must not authorize consequential action; current Mission state still gates authority, and the Mandate remains evidence rather than an access credential |
| OIDC Session Management, Front-Channel Logout, and Back-Channel Logout | Final | Not a substitute | Manage or end login sessions. Delta: sessions are not Missions. Logout does not require every projected credential to be revoked or the approved work to end |
Key deltas and substitution hazards
The high-impact comparisons in one table. The pattern is consistent: the neighboring document is useful for its own object. A conflict appears only when a deployment asks that object to stand in for the approved task.
| Question | The neighboring answer | The family’s answer | The delta |
|---|---|---|---|
| Asynchronous approval | CIBA authenticates a person out-of-band and completes a grant | Deferred Approval defers the Mission approval event, with the disclosure committed and interrogation recorded | CIBA has no durable task object and no revision channel. The two compose when CIBA is the interaction rail and the Mission is the record |
| Call-chain context | Transaction Tokens carry intra-domain, seconds-scale transaction context | Mission-bound tokens carry the durable approved task | A Txn-Token does not aim to satisfy the four Mission substrate properties. The two can compose on one hop as facts about different objects |
| Delegation | Token Exchange (RFC 8693) re-issues tokens and can represent actor relationships | Child Missions and offline attenuation enforce narrow-only delegation with lineage | RFC 8693 leaves output scope and token linkage to AS policy; the Mission profiles add a subset invariant and proof |
| Revocation events | SSF and CAEP carry identity, session, and security-condition events | Lifecycle Signals define Mission lifecycle events that gate every future derivation | Same event framework, different event subject and semantics. Session or credential events do not necessarily end the approved task |
| Status | Token Status List answers whether a credential is good | Mission Status answers whether the work is still authorized | The family profiles the same wire shape with the Mission as subject |
| Ending things | Logout ends the session | Termination ends the task within a published freshness bound | Sessions are not Missions, and logout does not require every projected credential to stop |
| Portable proof | A deployment may treat presentation of a verifiable credential as sufficient authorization | The Mandate proves committed facts and authorizes nothing by presentation | The restriction belongs to the Mission profile, not OpenID4VC: authority remains gated on current Mission state |
| Task lifecycle in-protocol | GNAP grant management can continue or update a grant | The Mission lifecycle governs an approved task with anchors and derivation | GNAP does not define the Mission’s integrity anchors, narrow-only child-task rule, or cross-substrate lifecycle; a future binding could add them |
| Workload authentication | WIMSE or SPIFFE proves which workload is calling | The Mission says which approved work authorizes the call | Authentication can be a policy input, but successful possession proof is not task authority |
| Who supplies the ontology | RAR lets a client request typed authorization details but leaves type definition and discovery outside the core | R3-shaped resource declaration, with RAR-type metadata as an OAuth discovery mechanism | The direction is substrate-specific. The invariant is that meaning is bound at approval and enforced at use |
What has no row, and why
Three absences are deliberate. XACML and policy languages such as
Cedar and Rego have no language-level row because the family binds to
the decision wire, AuthZEN, and stays agnostic about the PDP engine.
The Cedar RAR draft appears only because it defines a concrete join at
the authorization_details layer. SAML has no direct Mission
binding. A SAML assertion can still supply principal or client
identity, including through the OAuth assertion framework and
RFC 7522, without becoming
the approved task. DIDs likewise can supply identifiers and key
resolution. Whether those identifiers are useful is deployment
specific. Neither a DID nor its control proof grants Mission
authority.
The family’s own Mission documents are deliberately absent too. This map is the outside-in view. The separate prerequisite identity and delegation drafts are included only where the Mission documents depend on them. The inside-out view, which document supplies which capability at which assurance level, is the Reference’s draft-family table and the adoption part’s build order.
If a row here drifts from the public record, the fastest correction path is an issue on the draft repository, where the family’s references are reconciled first.