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 October 8, 2026, checked against the IETF datatracker and the OpenID Foundation’s specification pages. The Reference tracks the family’s own reconciliation date separately. 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 keep the map checkable. 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 first binding, on the most deployed infrastructure. The issuance-only floor, Baseline Issuance, needs the OAuth binding and published RFCs, with Client Instance Identification only for the optional instance-context composition, and it runs on Resource Servers that need not be Mission-aware. The reference security architecture, the Runtime-Enforced bundle, adds drafts: two OpenID AuthZEN working-group drafts (the Access Request and Approval Profile, ARAP, and the Profile for Obligations), the OAuth working group’s RAR metadata remediation draft, and Client Instance Identification, a proposed individual draft. The AuthZEN Authorization API 1.0 itself is Final. The remaining dependency risk sits in those drafts, and none of it blocks the floor. Other bindings and companions may depend on further 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 metadata remediation 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 OAuth binding adds a mission member carrying the current Mission state to the introspection result, beside token validity. Mission Status lets a deployment return that projection as an RFC 9701 signed response; its dedicated Mission Status operation uses its own signed media type instead |
| RFC 7009 Token Revocation | Required substrate | Revokes a token and, where the server supports it, related tokens or the underlying grant. Mission Status cites it normatively to keep its lifecycle endpoint distinct: RFC 7009 revocation alone does not revoke a Mission. 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 the Resource Access Profile’s mission_constraints_supported protected-resource metadata lists the constraint keys a resource enforces, one ontology-supply mechanism |
| RFC 9449 DPoP / RFC 8705 mTLS, with RFC 7800 confirmation | Required substrate | Sender constraint. A sender-constrained Mission-bound token cannot be replayed by another party, and the runtime permit binds its cnf key. The OAuth binding requires it for delegated tokens, the cross-domain companion for credentials that cross a trust domain, and the runtime for high-consequence actions. A primary token may stay bearer for bearer-only Resource Servers, at the cost of stolen-token exposure |
| 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 | Required substrate | The authentication-strength grain of the graduated challenge family, raised for an action inside an approved Mission without widening authority: the OAuth binding’s Resource Server answers weak or stale Subject authentication with insufficient_user_authentication and acr_values or max_age |
| RFC 7523 JWT grants and client assertions | Required substrate | The JWT-bearer rail. The Issuance Grant, the child-bound grant, and the cross-domain grant are redeemed as RFC 7523 JWT authorization grants, and Mission Status accepts private-key-JWT client authentication. The OAuth binding itself does not cite it |
| 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, five wider IETF rails and one protocol outside the IETF 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. The audit profile cites SCRAPI informatively, as one concrete interface for registration and Receipt resolution |
| RFC 9995 COSE hash envelope | Required substrate | The audit profile’s Signed Statements carry the evidence hash as the COSE_Sign1 payload, with the protected header signaling how it was produced, so sensitive task data stays out of the log. The audit profile still cites the draft, which has since been published as RFC 9995 |
| RFC 9421 HTTP Message Signatures | Required substrate (MAS binding and AAuth Mission Management) | The request-integrity rail. Where a MAS deployment signs requests, the signature must cover the Mission-Reference field, and AAuth Mission Management requests use AAuth’s HTTP Message Signatures profile |
| Model Context Protocol, revision 2026-07-28 | Required substrate (MAS binding) | In a MAS deployment, the requesting side carries the Mission reference on each tools/call in params._meta, under a reverse-DNS key outside MCP’s reserved prefixes, never in tool arguments or session state, and the reference selects a Mission without conveying authority. The Resource Access Profile models a tool as an entry whose resource is the MCP server and whose actions are tool names, which lines up with MCP filtering its tool list by the caller’s authority |
| RFC 9635 GNAP | Peer binding | 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, and it deliberately leaves the approved grant unspecified as a governed artifact. The family’s GNAP binding, a sketch, supplies that interior: the fifth binding, and the second authored against the substrate contract |
OAuth: the working-group drafts
The OAuth working group’s sixteen active or IESG-stage documents as of October 8, 2026, mapped in full, with the RFCs the working group has published from that queue since July and the 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 cannot settle 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 | WG consensus, waiting for write-up (IESG milestone December 2026) | 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 | In WG last call | Defined composition | The attestation rail beneath instance identity and Agent Deployment: how a client instance proves platform and posture when authenticating. Client Instance Identification and Client Attester Endorsement build on it |
| Token Status List | RFC Editor queue | Required substrate for an advanced companion | Mission Status List for OAuth 2.0 publishes Mission state as an OAuth Status List: each participating Mission holds an index, VALID reports active, and only VALID permits reliance. Delta: a token’s referenced status describes that token; a Mission status entry describes whether the work remains authorized |
| RAR metadata and error remediation | WG document (-00, August 2026), replacing draft-zehavi-oauth-rar-metadata | Required substrate for the AuthZEN profile | Machine-readable RAR type metadata and a remediation challenge: insufficient_authorization with authorization_remediation names the authority a denied request needs. The OAuth binding cites it informatively. An AS that implements its type-metadata endpoint should advertise it; the response then becomes the source of truth for supported types and can declare each type’s mission_transformation_capabilities for derivation. Conformance does not depend on it, and RFC 9396’s authorization_details_types_supported stays the baseline. The AuthZEN profile treats the remediation as payload that confers nothing by itself |
| Deferred Token Response | WG document (-00, September 2026), replacing draft-gerber-oauth-deferred-token-response and draft-parecki-oauth-jwt-grant-interaction-response | Required substrate for an advanced companion | Deferred Approval profiles its pending response and deferral code so approval can complete asynchronously. The family’s drafts still cite the individual version |
| 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 (waiting for AD go-ahead) | 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 10027) | Published RFC | Optional composition | Supplies the threat model for a decoupled approval interaction when the Approver uses another device |
| First-party applications | WG consensus, waiting for write-up | Adjacent | A first-party application interaction model with no Mission-specific join |
| Browser-based apps BCP (RFC 10017), Security BCP updates, JWT BCP update, and the RFC 7523 update | Published (browser-based apps), RFC Editor queue (the RFC 7523 update, and the JWT BCP update, held there for a JOSE draft it depends on), or WG document (Security BCP updates) | 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 fifty-one 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 |
|---|---|---|
| AAuth Protocol (Hardt) | Peer binding | This proposed clean-slate agent protocol (revision -11, September 25, 2026) has a first-class mission layer at the Person Server, and it uses the word for a different object: an AAuth mission is a Markdown description of what the agent intends, approved by the person at the Person Server, identified by mission_s256, and governed by the Person Server’s context rather than committed as an Authority Set. The family’s AAuth binding carries the kernel there (approval, the Mission Reference that pairs the approving Person Server with mission_s256, the active-state gate, and the ordered mission log) and adds no AAuth wire members. Authority stays in AAuth’s own scopes, resource tokens, and optional R3, and the lifecycle is active or terminated. Delta: the Person Server gates person-token issuance, and its issuance gating is structural for PS authorization and federated authorization; the binding says deployments MUST NOT claim PS issuance gating for agent-identity or resource-managed access, where the agent calls the resource directly |
| AAuth Rich Resource Requests (R3) | Defined composition | The resource-declared direction: a resource publishes operation semantics and requests commit to them. Revision -00 (September 28, 2026) is labeled an Exploratory Draft. Mission Discovery treats an R3 document as one form of resource self-declaration and, in an AAuth deployment, pins its r3_s256; the AAuth binding treats R3 as optional and maps no approved tool to an R3 operation. Delta: OAuth RAR does not prescribe the same ontology direction |
| Transaction-specific challenges (Rosomakho) | Required substrate for an evaluate-only companion | The single-transaction grain of the graduated challenge family, beside scope, authorization-detail, and authentication-strength challenges. The Mission Transaction Authorization profile keeps its wire contract whole and adds the Mission layer for an action authorized fresh, with its concrete parameters, across an organizational boundary |
| Attenuating agent tokens (Niyikiza) | Required substrate for an evaluate-only 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, renamed in September 2026) | Optional composition | Carries an in-flight transaction’s context across a trust-domain boundary, a sibling of Cross-Domain Projection on the same identity-chaining framework. A hop may run both: the Mission reference may ride the transaction chain as evidence, never as authority, and Mission-scoped authority crosses only through the Cross-Domain Projection grant |
| RAR evaluation with Cedar (Cecchetti, expired) | Optional composition | Defines Cedar evaluation of authorization_details, a policy-engine-specific companion to the engine-neutral AuthZEN profile |
| Credential brokers for agents (CB4A) (Hartman, expired) | 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 an evaluate-only companion | Defines act-chain discipline and optional per-hop proof and provenance. The OAuth binding cites the Actor Profile informatively, for its optional Delegation capability; Cross-Organizational Delegation depends on it normatively, and the runtime and Cross-Domain Projection cite the proof and receipt drafts informatively |
| Identity Assertion Trust Framework | Optional composition | Defines which assertions an issuer accepts, from whom, and under what proof for assertion-based cross-domain legs. Cross-Domain Projection names it, with its domain-authorized-issuer method, as a concrete way to publish and evaluate which Mission Issuers a Resource AS accepts instead of hand-maintaining a list |
| Client Instance Identification for Attestation-Based Client Authentication and OAuth 2.0 Client Attester Endorsement | Required substrate for optional instance context | Identifies which instance runs and on what attested platform, and lets a client endorse its attesters in client metadata. Client Instance Identification, a proposed individual draft, is the OAuth binding’s one normative Internet-Draft, confined to the optional instance-context composition; the MAS, the AuthZEN profile, and the runtime’s OAuth profile also cite it normatively, and Client Attester Endorsement is informative. Instance evidence identifies no actor, so attribution needs an instance-unique key. The authority part consumes that identity instead of redefining it |
| UMA 2.0 (Kantara Initiative) | Peer binding | The family’s UMA binding sketch 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 category properties admit a design, 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 maps row by row at revision 03, with the remainders stated |
| 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, expired), 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, expired), 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, expired), 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 eight documents as of October 8, 2026 (seven active, including AIMS, a working-group document since September, and one in AD evaluation) are mapped first. The final three rows group the eleven related individual drafts the working group listed on July 15; four of them have since expired.
| 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 |
| AI Identity Management System (AIMS) | WG document (-00, September 2026), replacing draft-klrc-aiagent-auth | Adjacent | Its Agent Mission section (Section 10.1) says “The Mission is the task or objective the Agent will pursue” and leaves the process that translates a mission into authorization requirements out of scope. The OAuth binding specifies that translation and reuses AIMS’s agent-as-client and delegating-principal-as-sub assignments unchanged; AIMS does not depend on the Mission family |
| Workload Identity Practices | AD evaluation (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 (expired), 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 (expired), heterogeneous credential verification, attestation in workload identity tokens (expired), transitive attestation (expired), 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 profile | 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 (adopted June 2026) | Required substrate for the AuthZEN profile | Turns a requestable denial into a governed request: the discovery loop’s ask leg. The Mission AuthZEN profile carries ARAP’s approval object and evaluation_id unchanged and returns its denial reasons in ARAP’s reason member. Delta: ARAP deliberately allows multiple completion modes; a Mission is one possible form of durable authorization state, not a requirement of ARAP |
| AuthZEN Profile for Obligations 1.0 | AuthZEN WG draft | Required substrate for the AuthZEN profile | The obligation objects a decision carries. The Mission AuthZEN profile requires a PEP to fulfill every obligation on a permit before releasing the action’s effect and to treat an unrecognized or unfulfillable one as a deny. The Mission profile’s one obligation type, step-up, is registered by the Obligations Profile itself |
| COAZ Framework 1.0 and COAZ-MCP Binding 1.0 | AuthZEN WG drafts (adopted June 2026) | Optional composition | Maps MCP tools/call inputs into the AuthZEN decision shape so tool-boundary PEPs can construct the same policy request. Capability Binding cites it informatively; the Mission-specific context, freshness, permit binding, and evidence requirements still apply |
| AROP, the OAuth binding of ARAP | Working group draft, adopted August 27, 2026 and merged September 2, 2026 | Adjacent | Binds ARAP completion to OAuth issuance for token-resident authorization state. No Mission draft cites it |
| Shared Signals Framework 1.0 with CAEP | Final, August 2025 | 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 |
| Grant Management for OAuth 2.0 | FAPI Implementer’s Draft 1 | Not a substitute | A durable, queryable, revocable container of consented authorization data. Conflict if substituted: a grant records consent to authority but carries no task, no integrity commitment, and no derivation gating. A deployment can surface Mission revocation through a grant-management-style API |
| Open-banking consent objects: UK Open Banking consents and Australia’s CDR arrangements | Deployed national ecosystem standards | Not a substitute | The closest deployed precedent: an approved intent with an identifier and a status, bound to tokens and revocable apart from them. Conflict if substituted: each lives at one data holder with a domain-fixed schema and governs that holder’s resources, so it carries no derivation across resource servers, no delegation narrowing, and no state for boundaries the holder never sees |
| 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) | Final (OpenID4VP July 2025, OpenID4VCI September 2025) | 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 category 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 Mission Status List draft 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. The family’s GNAP binding sketch adds the anchors, the subset rule, and Mission-gated issuance and rotation, and defers GNAP-native Child Missions |
| 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 issuance profile | R3-shaped resource declaration, with the RAR metadata remediation draft’s 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 cite them. The inside-out view, which document supplies which capability in which adoption bundle, 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.