A Layered Strategy for ID-JAG, WAG, and Cross-Domain Delegation

wag-id-jag-layering-strategy.md

A Layered Strategy for ID-JAG, WAG, and Cross-Domain Delegation

Executive Summary

Service providers increasingly need to authorize human users, services, and workloads across customer-controlled identity domains, and to distinguish a principal acting for itself from one acting on behalf of another, including multi-hop actor chains. The standards response should not be a separate end-to-end protocol for every combination of principal, issuer, delegation model, and topology. The recommended architecture:

1. Use OAuth Identity and Authorization Chaining Across Domains as the optional cross-domain choreography around the grant profiles.
2. Align the Identity Assertion JWT Authorization Grant (ID-JAG) and the Workload Authorization Grant (WAG) on the RFC 7523 redemption invariants they genuinely share; a common JWT Authorization Grant core is a candidate extraction from that demonstrated overlap, not a foundation designed up front.
3. Keep ID-JAG the human-subject profile for Cross-App Access (XAA), including its client-bound OAuth delegation model: the registered client holds delegated access with no explicit actor claim.
4. Develop WAG, or an equivalent, as the candidate profile for non-human authorization subjects, beginning with workload principals; whether durable services share it depends on demonstrated lifecycle and evidence alignment (Sections 5.3, 11 item 14). An entity acting only as the OAuth client stays on client authentication, in any topology.
5. Define actor delegation as a separate, composable profile, required when a principal beyond the subject and the ordinary presenting-client role exercises the subject's authority, or when explicit chain semantics are needed (Section 5.4). Agents need no new principal type: an agent is a service or workload principal composed from the existing roles, with agent available as a policy classification (Section 2.3).
6. Support direct platform issuers and enterprise brokers as trust paths into the same target Authorization Server; a brokered path declares its assurance mode up front and establishes issuance-time key binding under an explicitly declared assurance mode (Section 7.2).
7. Type every issuer trust relationship: each issuer is scoped to what it may assert (subjects, attributes, delegation, targets, keys), per customer tenant (Section 6).

The central principle:

Cross-domain authorization has three independent questions: who holds the authority, who is exercising it, and how the authority crosses a trust boundary. ID-JAG, WAG, actor delegation, and Identity Chaining answer them separately rather than encoding every combination in one grant profile. Standardize only the redemption invariants the profiles demonstrably share, and never let an added actor or a boundary crossing implicitly expand effective authority.

This document is the PR #119 author's own change of direction. It proposes an alternative to that PR (workload principals native to ID-JAG); if adopted, the author will withdraw PR #119. The asks: dispose of PR #119 and the Section 10 items as separately weighted ID-JAG issues, and charter the Appendix F design questions as three separable tracks (venue plan in Section 13). One item is urgent independent of everything else: adopted ID-JAG's key-bound redemption depends on an expired individual draft (Section 10.11, Required Decision 14). History: Appendix A. Evidence: Appendix B. Worked example: Appendix C.

Decision map. The five memo points, where each is argued, and what gates it:

Memo point	Argued in	Gating questions (Appendix F)
ID-JAG stays human-specific	Section 10	Section 10 items (10.1 consensus call); 10.11 is urgent and independent, gating nothing
WAG (or equivalent) for non-human self-subjects	Sections 5.3, 11	Decisions 1, 2, 3, 8, 9, 11, 15; plus the outcome of Decision 14 (ID-JAG track)
Actor delegation composed separately	Section 5.4	Decisions 5, 10, 12, 13
Core document only if the overlap justifies one	Section 5.2, Appendix D	The matrix outcome; no document is an acceptable answer
Where service-self belongs	Section 5.3	Section 11, item 14

Part I: The Architecture

Part I presents the architecture independently of Part II's working-group disposition; it draws on Appendix F's tracked decisions and Appendix G's definitions.

1. Problem Statement and Invariants

A service provider may need to support all of: human, service, and workload principals; principals acting for themselves; clients or workloads acting for another principal; multi-hop actor chains; direct trust in platform issuers; trust brokered through a customer enterprise IdP; single-domain, cross-domain, and multi-hop access; customer-provided issuers per principal and delegation type; and pre-provisioned, manually created, or just-in-time local principals.

Without a common layer, every provider independently maps every issuer, principal type, attribute model, authorization model, and account system: an N × M integration problem. The reduction available from shared machinery is bounded, and Section 7 states the bound: layering and brokerage can reduce pairwise trust and subject-mapping integrations, while authorization-policy mappings may remain service-specific. What the layer buys is one credential format, validation discipline, delegation representation, and issuer-authority vocabulary in place of per-pair inventions of each; what it does not buy, and does not claim to, is portable entitlement semantics. Platforms prefer simple direct trust; enterprises operating workloads across many platforms may prefer a broker that centralizes issuer validation, subject mapping, attribute normalization, policy, and lifecycle. Both models must coexist.

Five invariants hold across every profile and path:

• A grant is redeemed only at the Authorization Server identified by its audience and never reused at a subsequent trust-domain boundary; each crossing requires a newly issued grant.
• Adding an actor or crossing a boundary never implicitly expands effective authority; any addition is an explicit decision by an issuer trusted to make it (Section 9).
• Issuer trust is typed and tenant-scoped, never a bare allowlist.
• Subject, actor, client, and presenter are distinct roles that one entity may hold but that implementations must never conflate.
• Write authority for act is assigned, not ambient: only the issuer of a newly issued grant records an actor, under profile-defined evidence.

2. Principals and Protocol Roles

2.1 Principal Types and Principal Granularity

Principal type	Description	Governance surface
Human	A natural person	Person directory
Service	An application, service, automation, or durable agent registered as an application	Application registry
Workload	A deployment, job, process, or agent in a platform workload-identity system, logical or runtime	Workload platform

The type names the identity family and governance surface, never lifecycle: a service is registered and governed in an application directory; a workload belongs to a platform workload-identity system and may itself be logical or a runtime instance. Lifecycle lives on the granularity axis below, which is why a durable agent with platform-issued identity is coherently principal type workload at granularity logical (Appendix C.1). Where labels blur, granularity, never the type label, carries the normative weight.

Granularity is a property of a principal, orthogonal to type: a principal appears either as the logical entity (durable, governable) or as a runtime instance (an execution proving possession now). Which granularity occupies which functional role (Section 2.2) is a separate placement choice, and both can appear in one grant (sub naming the durable agent, cnf carrying the instance key, attestation describing the instance). Three recurring compositions earn names:

Pattern	sub names	The runtime instance appears as
Instance-as-subject	The runtime instance	The subject itself
Instance-as-presenter	The logical principal	The presenter (cnf key), optionally with attestation claims
Instance-as-actor	The logical principal	An explicit actor under the delegation profile

The patterns are compositions of granularity and role, applied per role: a grant's subject and its actor each have a granularity (Appendix C.2 composes granularity and role: a logical actor presented by a runtime instance). Every issuer-authority rule and every sub definition states its granularity: principal_types: [workload] alone is unsafe, because implementations that disagree on whether sub names the durable agent or its current process silently diverge on trust policy and account lifecycle.

2.2 Functional Roles

Concept	Meaning
Subject	The principal whose identity and authority form the basis of the request
Actor	A principal currently exercising authority on behalf of the subject
OAuth client	The protocol participant making a request to an authorization server
Presenter	The party or key proving possession of a grant or token
Issuer	The authority making claims about a subject, actor, or authorization grant

The same entity can occupy several roles; implementations must not assume it does.

2.3 Agents

An agent is not an identity type: it is a policy-relevant characteristic of a principal. Agents are compositions of ordinary roles, never a new kind of protocol principal: an agent is a principal (a service or workload) carrying the characteristic. What a target actually needs is independently testable: whether explicit actor representation is required (Required Decision 13), what authority and behavioral constraints apply (task scoping and spend caps are authorization content, never identity type), whether the presenter is key-bound, and what delegation evidence exists. Where policy needs the characteristic itself, it is expressed as an optional subject class alongside type and granularity (Required Decision 15), issuer-asserted or locally governed, never derived from behavior or autonomy: an agent can be principal type workload, subject class agent, granularity logical, presented by a runtime-instance key. When present, the classification is authorization-semantic and mandatory to understand (Section 5.2); its consequences come from profiles and local policy, never from the label alone. Absence is not evidence: a target requiring agent-specific controls must not infer not-an-agent from a missing class, and relies instead on a profile that always carries the classification, a trust record fixing the class per issuer (the Required Decision 15 interim, which is also the only enforcement until a wire discriminator exists), or local registration.

What is new about an agent is not the identity primitive but the accountability boundary: an agent runs code on someone's behalf, toward a purpose someone approved. The common first move is right as far as it goes: treat the agent as a workload and give it workload identity (SPIFFE, a service account, a signed runtime credential, a cloud IAM role, mTLS). That names which runtime is making the call, which is exactly what audit and breach forensics have been missing, and it is the input evidence this architecture consumes (Section 5.3). But it does not say on whose authority the agent acts, what task it was approved to do, or whether that task is still in bounds right now. The rule deserves the document's blockquote convention:

Workload identity names the runner; it does not describe the job.

The rest of this document is the rest of the sentence: whose authority is the subject and, in delegated flows, the actor profile (Section 5.4); the approved task is authorization content (scopes, authorization_details, behavioral constraints); still-in-bounds is grant lifetime, freshness, and the derived-token rules (Section 9). Identifying the thing that is acting is necessary, and it is not the same as authorizing what it is trying to do. The boundary is answered by these existing primitives, never by a new one.

An agent does not "act as" a human: it acts as itself (the agent is the subject) or on behalf of a human (the human stays the subject; the agent is an actor). One composition anchors the whole model, a human using an agent:

subject    = the human
actor      = the logical agent
client     = the registered application
presenter  = the running agent instance (its key)
issuer     = the platform or broker asserting each fact

The product surface (directory membership, mentions, assignment, presence) attaches to the same model, the logical principal over the Section 8 key; Appendix I carries that non-normative note.

3. Independent Architectural Axes

Axis	Values
Principal type	Human, service, workload
Principal granularity × role	Logical or runtime instance, placed per role (the instance-as-subject, instance-as-presenter, instance-as-actor compositions)
Authority path	Direct issuer, enterprise broker
Authorization mode	Self, on-behalf-of
Topology	Single-domain, cross-domain, multi-hop

Examples: WAG (workload, direct, self, cross-domain); brokered WAG (workload, broker, self, cross-domain); XAA with ID-JAG (human, enterprise IdP, client acting for the human, cross-domain); agent delegation (human or service subject, workload actor, direct or brokered, cross-domain or multi-hop). These combinations are expressed through composable profiles, not independent end-to-end protocols.

4. Existing Capabilities and Gaps

4.1 What exists

• RFC 7521/7523: the assertion framework and JWT authorization grant (assertion parameter, grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer), deliberately leaving audience values and the claim contract to profiles.
• RFC 8693 (Token Exchange): the exchange choreography and the delegation claims act and may_act; their exact semantics are load-bearing and treated in Section 5.4.
• Identity and Authorization Chaining Across Domains: the cross-domain choreography (Section 5.1). It requires the grant's aud to identify the target Authorization Server, permits resource or audience to select that server at acquisition, permits claims to change during transcription, allows grant acquisition outside Token Exchange, and intentionally defines no reusable claim contract.
• ID-JAG (draft-ietf-oauth-identity-assertion-authz-grant-04): the adopted human-subject XAA profile, with urn:ietf:params:oauth:grant-profile:id-jag and discovery metadata (authorization_grant_profiles_supported, identity_chaining_requested_token_types_supported).
• WAG (draft-carleton-workload-authz-grant-00): a workload-self profile, by its own description "an early, exploratory individual draft" in which "most sections are placeholders": plain RFC 7523 grant, no explicit JWT type, no requested token type, proof-of-possession an open item, and a recommendation in WAG-00's own Section 5.1 that aud include both the AS issuer identifier and its token endpoint URL, accepting either.
• draft-klrc-aiagent-auth-03: reaches the conclusion this strategy builds on: agent authentication and authorization should reuse existing OAuth and Workload Identity in Multi System Environments (WIMSE) building blocks.

4.2 What is missing

• Explicit grant typing, per-grant profile dispatch, and a cross-JWT confusion rule.
• A common temporal contract and a defined replay contract (iat, exp, jti scope and retention).
• One set of audience and resource slot definitions (Identity Chaining and WAG-00 currently differ).
• Extension points for presenter binding and profile-specific claims (Section 5.2).
• Profile enforcement at the target Authorization Server, so grants cannot be duck-typed.
• A typed issuer-authority vocabulary, including tenant binding, plus the operational surface that authors and audits it.
• Verifiable delegation evidence beyond act attribution, when chains must be enforced rather than recorded.

5. Candidate Protocol Layering

          Identity Chaining
   cross-domain choreography (optional)
                  |
            JWT grant rail
              RFC 7523
  (Token Exchange is one issuance path)
                  |
       +----------+----------+
       |                     |
  Subject profile      Delegation profile
  +------+------+            |
  ID-JAG      WAG          Actor
  human    non-human     (optional)
       |                     |
       +------ compose ------+

The grant profiles exist independently of Identity Chaining: single-domain RFC 7523 redemption does not require it. Chaining is the choreography wrapped around the profiles whenever a trust-domain boundary is crossed. A separate durable-service-self profile remains a live possibility alongside ID-JAG and WAG (Sections 5.3, 11 item 14).

5.1 Identity Chaining

1. A client obtains a JWT authorization grant in one trust domain.
2. The client presents it to an Authorization Server in another domain via RFC 7523.
3. The target Authorization Server issues its own access token.
4. A new grant is issued whenever another boundary is crossed; authority not derived by transitive attenuation requires an explicit reauthorization decision (Section 9).

Chaining permits the grant to be obtained through Token Exchange or another interface, so a platform can issue a WAG directly while using the chaining presentation model. Chaining intentionally defines no reusable claim contract; a companion core should supply it rather than ID-JAG and WAG recreating it independently.

5.2 A Candidate Core, Extracted, Not Designed

Core scope

The core is a candidate extraction: identify the normative statements ID-JAG and WAG would otherwise duplicate, demonstrate the overlap, extract only that. The credible minimum:

• Explicit grant typing, profile identification, and per-grant dispatch.
• Common temporal claims (iat, exp), required collision-resistant issuer-scoped jti, and a shared vocabulary of replay classes (Required Decision 9); redemption-state behavior stays profile-specific.
• RFC 7523 redemption mechanics at the target Authorization Server.
• The audience and resource slot definitions below.
• Extension points for presenter binding (cnf) and profile-specific claims.

Explicitly outside the core: issuer administration, principal semantics, actor delegation, provisioning and lifecycle, and multi-hop policy; those remain in the profiles and deployment policy. If the demonstrated overlap is smaller than this list, the core shrinks: RFC 7523 plus Identity Chaining already carry much of the common machinery, and the core must earn every rule it adds. One element is deliberately pre-agreed rather than extracted: the audience and resource slots, because both profiles must interoperate with chaining's audience rules from the start; the rest waits for the demonstrated overlap of Phase 2 (Section 13).

Whether a core document exists at all is the Phase 3 question; Appendix D's overlap matrix answers it honestly. If little survives beyond its marked rows, the outcome is a short shared-conventions section that ID-JAG and WAG both reference rather than a standalone document; the layering does not depend on which container carries the conventions.

Audience and resource slots

Four protocol slots are routinely collapsed into the words "audience" and "resource"; the core names them separately:

Protocol slot	Artifact	Purpose
audience / resource request parameters	Token Exchange request	Select the target Authorization Server during acquisition (chaining permits either)
aud claim	Issued grant	Bind the grant to the target Authorization Server
resource claim	Issued grant	Profile-defined protected-resource restriction, where a profile defines one
resource parameter	RFC 7523 redemption request	Request an access token for a specific API

Fixing the issued grant's aud to the target Authorization Server narrows an RFC 7523 permission (the token endpoint URL is also a valid audience by agreement; WAG-00 carries both, accepting either), so servers accepting both forms today need a transition rule. Two exact names for one server is operationally undesirable rather than inherently unsafe; the real risk is ambiguous, loose, or cross-tenant alias mapping, and new profiles should recommend one canonical form. WAG's adoption of these slots is a normative change (Section 11, item 13).

Dispatch and enforcement

"One validation pipeline" means shared envelope validation followed by deterministic profile dispatch, never uniform interpretation of whatever claims are present. Validation is two-stage, per the JWT BCP's rule that different kinds of JWTs get mutually exclusive validation rules (RFC 8725, Section 3.12): first, parse untrusted routing fields (iss, header typ) only to select a preconfigured candidate validation policy; second, validate the JWT under that profile's mutually exclusive rules (permitted algorithms, key class, audience, claim requirements). iss, typ, and claims become trusted only when validation succeeds; a grant matching no configured policy is rejected, and so is one whose routing fields match more than one candidate policy for the same issuer: ambiguity fails closed. Distinct JOSE typ values are the only pre-verification per-grant routing mechanism (discovery metadata labels servers, not incoming JWTs); Required Decision 1's payload-discriminator option dispatches only after envelope validation under a shared policy.

After dispatch, the target Authorization Server MUST reject a grant whose profile does not match the request's policy context: the profile, issuer set, and audience its configuration associates with the request's inputs (authenticated client registration when present or required; presenter identity or key; issuer and profile; tenant and resource; and the explicit absence of client authentication where a profile permits it). Client registration is an input where it exists, not a core invariant: WAG avoids per-agent registration, but where clients are registered, omitting the input reopens confusion between sibling clients sharing a tenant and API (Required Decision 8). Two gates apply conjunctively: policy context and the trust record's accepted_profiles (Section 6); any conflict rejects, unrecognized profiles reject, and composed grants reject until Required Decisions 5 and 12 resolve. The other interim rules fail closed the same way (Required Decisions 2 and 3, and bearer-class replay under 9).

The profile, not the individual claim, is the unit of compatibility. A verifier MUST understand every claim the selected profile defines as authorization-semantic (restrictions, composition markers, subject classification, assurance mode) and rejects a grant it cannot fully process, or restrictions are silently dropped, which is duck-typing again; signing prevents modification, not being ignored, and JWT has no general critical-claim mechanism. Extension discipline is issuer-side and advertised, because a verifier cannot classify a claim it does not understand: issuers MUST NOT place authorization-semantic content in unnegotiated private claims; every authorization-semantic extension MUST be identified through a recognized profile version, composition identifier, or an explicit on-wire required-extension list; and a recipient MUST reject when any advertised required extension is unsupported. Informational extensions stay ignorable per RFC 7519. The extension list's location and processing are decided with composition negotiation (Required Decision 12). Registration (Required Decision 6) aids interoperability without making a claim mandatory to process.

Redemption uses urn:ietf:params:oauth:grant-type:jwt-bearer for bearer grants (key-bound redemption is Required Decision 14's subject). For cnf-bound grants, adopted ID-JAG currently depends on the expired individual JWT DPoP grant draft (urn:ietf:params:oauth:grant-type:jwt-dpop, draft-parecki-oauth-jwt-dpop-grant-01, expired 2026-08) for key-bound redemption, so the core must choose explicitly rather than silently. Required Decision 14 first decides that dependency's fate, and only then which redemption shapes the core supports.

Typing

One generic JWT typ plus a required profile identifier, or profile-specific explicit types, is Required Decision 1; distinct explicit types provide stronger cross-JWT confusion resistance and are the recommended default. Existing ID-JAG wire identifiers do not change merely to create a core.

5.3 Principal Profiles

Concern	ID-JAG	WAG
Subject	Human End-User	Non-human self-subject, workload first; durable services per Section 11 item 14 (granularity per Section 2.1)
Input evidence	OIDC ID Token, SAML assertion, or related IdP state	Platform or WIMSE workload credential
Issuer	Enterprise or application-ecosystem IdP	Platform issuer or enterprise broker
Subject mapping	SSO account resolution, JIT, SCIM, or manual binding	Workload/agent binding, JIT, or no durable local account
Client binding	Required for the XAA client relationship	Deployment- and profile-specific
Proof-of-possession	Sender-constrained when the presenter can hold a key; bearer permitted with client authentication as an independent control	Key-bound by default; bearer only as an explicitly weaker deployment class (Section 11)
Specialized attributes	Human authentication and identity context	Workload and platform properties

Service-self (proposed boundary for working-group consideration). The discriminator is protocol role, not topology: when a service identity is used only as the OAuth client principal, use client authentication, including federated client authentication, in any topology. When the service is an authorization subject distinct from the OAuth client or presenter, use a subject authorization-grant profile; WAG is the candidate home, beginning with workload principals, and durable services share it only if lifecycle and evidence semantics demonstrably align (Section 11, item 14): the same extract-when-demonstrated discipline the core applies to itself. This is the proposed answer to the venue memo's fifth point, not a settled conclusion.

Proof-of-possession posture derives from key capability, not principal type. As the proposed WAG default, a key-capable presenter gets a key-bound grant (cnf) and a sender-constrained access token; key capability is necessary for that posture, not by itself determinative of profile policy. Bearer grants exist only as an explicit opt-in class with defined maximum lifetime, replay detection, audience restriction, and disclosure assumptions; conformance testing assumes key binding. The key-bound default is a deliberate policy bet, not one Appendix B's incident record forces (those incidents are answered by short lifetimes, audience restriction, and immutable subjects); the explicit bearer class exists so the trade is visible rather than implicit. For ID-JAG this posture is forward-looking, not a change to the adopted draft, which leaves DPoP optional (strengthening that default would be a further Section 10 change with migration implications). Client authentication binds the token request to a client, not the grant to a key holder: an independent control, never a substitute for key binding. Attestation-based client authentication (References) is one candidate for that control at instance level, giving an authenticated presenter without per-instance registration; its attestation subject is the client identifier, so binding the instance to an asserted workload subject is a separate required step (Section 7.2). A candidate, not the only mechanism (Required Decision 2).

5.4 Actor Delegation Profile

On-behalf-of behavior is a separate profile composing with a human, service, or workload subject profile.

• sub identifies the principal whose authority is being exercised.
• act identifies the actor exercising it and can carry a nested prior-actor chain.
• client_id identifies the client registration bound to presentation of the grant.
• cnf identifies the key authorized to present the grant.

Boundary with base ID-JAG. Base ID-JAG is client-bound OAuth delegation without an explicit actor claim: the human subject supplies the authority, the authenticated registered client obtains delegated access in the ordinary OAuth sense, and no act appears; the client is not thereby an RFC 8693 actor. The delegation profile is required when the authorization model recognizes an exercising principal distinct from the subject and the ordinary presenting-client role, or when explicit chain semantics are needed; two implementations must not model the same relationship differently. Whether an agent represented by a client registration must also appear as an actor is not derivable from protocol topology: it is registration policy and must be unambiguous, so a registration classified as requiring explicit actor identity (explicit_actor_required, Required Decision 13) rejects grants presented without the delegation profile, and the protocol never infers autonomy.

RFC 8693 Section 4.1 states the act rule directly: for access control, the consumer MUST consider only the token's top-level claims and the current actor; prior actors in nested act claims are informational only. may_act expresses eligibility only, with no scope, resource, lifetime, purpose, or attenuation constraints. A chain recorded in act is therefore audit history unless the delegation profile supplies verifiable delegation evidence. The profile consequently owns:

• The evaluation hooks and representation for authorizing the current actor; the authorization decision itself stays in target policy and the trust records (Sections 6, 9).
• Actor-token and presenter binding.
• Chain construction and preservation, with enforceable depth carried by a profile-defined construct: authenticated delegation evidence or a top-level delegation-depth claim with normative construction and validation. Nested act stays the audit representation: rejecting on chain length is an access-control decision, and RFC 8693 Section 4.1 excludes nested act from those regardless of who signed the token. Depth is transitively enforceable only under transitive delegation provenance (Required Decision 4): under authoritative transformation, a re-originating issuer reports whatever depth it asserts, the same over-assertion blindness as Section 7.2's identity case.
• Attenuation rules and maximum chain depth.
• Whether separate verifiable delegation evidence (proofs or receipts) is required when chains must be enforced rather than attributed.

Write authority for act is assigned, not ambient: only the issuer of a newly issued grant writes act, under evidence the profile defines; neither a client nor a downstream server promotes a may_act entry unilaterally. Base WAG remains self-only: the workload is sub and act is absent. When an agent acts for a user, the human is sub and the workload appears in act.

The slot's minimum interface: actor identity and authority representation, actor_token validation, act construction, chain preservation, composition negotiation (Required Decision 12), and target enforcement metadata. draft-mcguinness-oauth-actor-profile-00 (by this document's author) is one candidate implementation, broader than the slot: canonical (act.iss, act.sub) actor identifiers, sub_profile classification, chain validation and construction, presenter transitions, and discovery metadata across assertion grants (ID-JAG named explicitly), JWT access tokens, and Transaction Tokens. Adopting the composition does not require adopting that framework; two known deltas: depth enforcement must move off act nesting, and its metadata does not yet solve composition selection. Other conforming profiles may be defined.

6. Issuer Trust and Subject Authority

A raw issuer allowlist is insufficient; trust is scoped by what the issuer may assert. Conceptually, issuer authority is a tuple: subject × attributes × delegation × actor identity × authorization × credential, keyed by tenant. An illustrative, non-normative record schema is Appendix G.

The record distinguishes six authorities:

• Subject authority: which principal types, subject classes, principal granularities, and identifier namespaces the issuer may identify.
• Attribute authority: which attributes it may assert authoritatively.
• Delegation authority: whether it may assert that one principal acts for another.
• Authorization authority: which audiences, resources, or permission constraints it may request or convey.
• Credential authority: which keys, attestations, or workload credentials it may bind.
• Actor identity authority: which actor identifier namespaces the issuer may assert in act, whether the asserted actor identity is broker-canonical or transcribed from upstream, and when act needs its own iss (RFC 8693 notes iss plus sub may be necessary to identify an actor). Delegation authority (may this issuer assert that delegation occurred) and actor identity authority (may it name actors in that namespace) are different permissions (Required Decision 10).

Tenant binding. The tenant keying these records has three sound sources, all registration-based (registration precedes token evaluation, avoiding the circularity of deriving tenant from a namespace whose authority is itself tenant-scoped): a per-tenant issuer (WAG-00's shape); a signed tenant claim plus an exact registered issuer/tenant relationship; or exact-match registration of a structural component of the subject identifier, such as a WIMSE Workload Identifier Origin (scheme plus trust domain, path excluded, draft-ietf-wimse-identifier Section 4.6) or an organization or namespace component of a structured subject. Freeform path-prefix and longest-match selection are excluded: URI-prefix authorization founders on parsing, normalization, and overlapping registrations, and the WIMSE draft says consumers SHOULD NOT prefix-match unless policy explicitly defines it (Section 7.6). Required Decision 3 covers the rest: a direct tenant claim, and validating registrations against issuer-published metadata.

Trusting an issuer for human SSO must not make it authoritative for workloads, and trusting a platform for workloads must not make it authoritative for enterprise users, groups, or delegation. Likewise, authority for a principal type does not imply authority for a subject class: an issuer may be authoritative for workloads but not for the agent class (Section 2.3, Required Decision 15), and the record expresses that separately. A broker is an issuer: the same record discipline applies to it, and what the target can verify about the broker depends on the Section 7.2 assurance mode.

Authentication is not authorization. Platform properties are authorization inputs, not a grant by themselves, and each path must make visible who authorizes what:

Authorization question	Direct path	Brokered path
Issuer may represent the subject	Admin configures the platform issuer at the target Authorization Server	Enterprise admin configures the platform at the broker; the target trusts the broker
Subject is valid for the target tenant	Target trust record: per-tenant issuer, signed tenant claim, or exactly registered subject origin	Broker canonical mapping plus the target trust record
Requested resources, scopes, authorization details	Target policy	Broker policy narrowing plus target policy
Actor may exercise the subject's authority	Delegation-profile evidence evaluated at the target	Broker may pre-validate; the target still evaluates
External attributes map to local entitlements	Target, service-specific	Target, service-specific; the broker may normalize

Operationally, each trusted issuer implies key-lifecycle work (JWKS fetch and caching, rotation, unknown-kid handling, per-issuer failure isolation), and at multi-tenant scale the trust store is an operated system with an authoring model, safe defaults, audit, and blast-radius controls: a real deliverable in any implementation estimate. The trust-record vocabulary is itself a standardization candidate, though not a near-term one (Section 13); Appendix B shows what happens when each deployment improvises it.

7. Direct and Brokered Issuance

7.1 Direct Platform Issuer

Platform workload issuer → WAG → Target Authorization Server

Simple trust establishment, low latency, no intermediary, direct use of platform-native identity. Its costs: distributed trust configuration and provider-specific attribute-to-permission mappings; each provider must understand the platform issuer and its authoritative workload properties.

7.2 Enterprise Broker

Platform workload assertion
        ↓
Enterprise IdP or identity broker
        ↓ Token Exchange
Broker-issued WAG
        ↓
Target Authorization Server

The broker validates the platform issuer and workload credential, establishes which subjects the platform may assert, maps the workload to a canonical enterprise principal, filters or normalizes attributes, applies enterprise policy, issues a short-lived audience- and resource-restricted WAG, and preserves source identity for audit.

The two paths do not automatically produce equivalent identities:

direct:   (platform issuer, platform workload sub)
brokered: (enterprise issuer, enterprise canonical sub)

The target cannot know these identify the same principal without account linking or canonicalization, and brokerage can erase platform, tenant, attestation, and runtime provenance.

Prerequisite: choose the assurance mode.

• Authoritative transformation: the broker becomes the authoritative issuer and accepts responsibility for the transformed identity. Upstream evidence may exist only in the broker's audit records; the target has no independent detection of broker over-assertion, and anything the broker adds is bounded only by the broker's own trust record (Section 6).
• Transitive provenance: the broker preserves verifiable upstream evidence the target can validate or reconcile. Provenance is not one thing: identity provenance (where the subject and attributes originated), authorization provenance (the upstream authorization basis and restrictions), and delegation provenance (the subject-actor relationship) are distinct evidence classes, and preserving an upstream identity token proves nothing about whether the broker was entitled to add a downstream permission. Their representations are Required Decision 4.

Prerequisite: issuance-time key continuity. Redemption-time proof of possession is insufficient alone: a stolen bearer platform assertion must not buy a broker-issued grant bound to the attacker's key. Proof of a key never establishes who the caller is (DPoP proves possession, not authentication, RFC 9449), so the governing rule is: the issuer MUST validate an authenticated binding among the asserted subject or actor identifier, the token-request caller identity, and the proof key. The issuer establishes key binding under an explicitly declared assurance mode.

The assurance modes (inherited_key_binding, authenticated_subject_key_binding, attested_subject_key_binding, authorized_key_designation) satisfy or explicitly decline that rule in different ways; their definitions are Appendix G, their per-grant signaling is Required Decision 16, and authorized_key_designation is not a proof-of-possession mode.

Subject evidence. The subject side has three separable requirements, never one invariant: validity and maximum age; a replay policy fit to the token type (an ID token rarely supports global single-use enforcement and a refresh token is deliberately reusable, so a profile may instead prohibit refresh-token subject evidence or define a one-time delegation artifact, Required Decision 9); and, distinct from both, authorization to combine this subject with this actor, which no amount of freshness supplies (Section 5.4, Appendix C.2).

Which mode applies to a particular grant must be knowable to the target (Required Decision 16); a static trust record suffices only when it fixes one mode for everything the issuer issues. Until that decision resolves, the fixed-mode record is the interim, and brokering is safe under this section's prerequisites only with it in force: the wire mechanism is later work, the requirement is not. The same modes and rule apply to a direct platform issuer; brokered issuance is one application.

Attestation-based client authentication (References) is one concrete rail for authenticated_subject_key_binding and attested_subject_key_binding: the attestation binds the instance key, the proof carries a challenge, and the attester is an issuer with credential authority (Section 6) whose trust record needs broker-grade blast-radius treatment. Its subject is the client identifier, so it establishes workload key continuity only when validated evidence or registered policy binds that client instance to the asserted subject or actor identifier.

State the brokerage claim narrowly: for each enterprise customer it can reduce pairwise trust and subject-mapping integrations toward N + M; authorization-policy mappings may remain service-specific. The broker cannot eliminate local entitlement mapping, because SaaS permissions have local meaning; it can centralize issuer trust, subject mapping, attribute normalization, and enterprise policy.

8. Local Principal Projection and Lifecycle

Authentication, federation, provisioning, and authorization are separate operations. The canonical external principal key includes at least:

(local customer tenant, validated issuer, issuer tenant, subject)

Implementations should require that:

• sub is stable, immutable, and non-reassigned, with its principal granularity (Section 2.1) declared; consumers treat it as opaque unless the selected profile explicitly defines its structure and comparison rules (as the structured subject origins of Section 6 do).
• The issuer is authoritative for the subject per the Section 6 trust record.
• Mutable names and display attributes are not identity keys.
• Upstream and broker-canonical identities remain distinguishable.
• JIT, SCIM, manual creation, and existing-account linking produce the same local federated binding.
• Runtime instances are not confused with durable agent or service identities.

A valid grant does not require creating a local account; local policy decides whether the subject must exist, is created just in time, is projected from SCIM, or operates without a durable local object.

Linking the direct and brokered identities of one principal is a security operation, not a convenience: mutable claims (email, name, namespace, display attributes) are insufficient for automatic linking; linking requires administrative authority or authenticated evidence from both identity domains; collisions, one-to-many mappings, unlinking, issuer migration, and identifier retirement need explicit defined behavior; and JIT creation must never silently claim an existing principal belonging to another trust path. Without these rules, running both paths into one provider becomes an account-takeover vector even though every individual grant validates correctly. When a broker rewrites sub, it assumes responsibility for the canonical subject and re-originates the grant chain: downstream parties observe a chain that starts at the broker. Any retained upstream identifier is provenance for audit and reconciliation, not an actor, and does not independently establish trust.

9. Effective Authority and Attenuation

For self-authorized access the subject acts for itself; for delegated access the subject and the actor context are evaluated independently. (ID-JAG's profile-specific human-plus-client rule is Section 10.4; this section is the general model.)

Effective authority is bounded by all of: subject authority (the target's locally determined subject entitlement); the policy governing this actor; delegation constraints; authenticated-client and presenter constraints; the grant's resource and permission constraints; local resource policy; and runtime risk policy.

"Policy governing this actor" is deliberately not "the actor's standalone permissions": an actor need not hold independent entitlements to the subject's resources (an agent may have no self-authorized access yet be permitted one operation for a user); a profile requiring independent entitlements must say so. Actor context means the current actor; nested act history is attribution, not an access-control input (Section 5.4).

Three operations must not share one word. Local authorization: the target computes authority from its own subject and actor policy. Reauthorization: a trusted issuer creates a new authorization basis, possibly in a different permission vocabulary; it can add authority and is not attenuation relative to the upstream grant. Transitive attenuation: downstream authority is provably no broader than a comparable upstream basis, checkable only where hops share a vocabulary. Subject authority never means permissions appearing in upstream tokens.

Attenuation is semantic, not syntactic: cross-domain issuance translates vocabularies (upstream role to downstream scope, enterprise policy to target-specific authorization_details), and chaining explicitly permits claims to change during transcription. The rule:

A boundary crossing MUST NOT implicitly add authority. Any added authority MUST result from an explicit authorization decision by an issuer trusted to make that decision, within that issuer's configured authorization authority (Section 6). Profiles requiring transitive verification of the upstream basis define the corresponding evidence.

Two models satisfy this and must not be conflated. Reauthorization: the issuer's signature and trust record are the downstream basis; additions are bounded by its authorization authority. Transitive authorization provenance: additional evidence lets the downstream server verify the upstream basis itself; that machinery does not exist yet, so it is a separate profile (Required Decision 4), never a general requirement, and it is the only mode with independent over-assertion detection, and then only for the evidence class actually preserved: identity provenance alone exposes nothing about added permissions (Section 7.2). Claim-subset comparison remains a valid conformance test only where two hops share a claim namespace and comparison algorithm.

These are per-hop obligations: each issuer enforces them for what it consumes and issues, and end-to-end assurance equals the weakest issuer in the chain unless transitive provenance lets the target validate more. A re-originated grant (Section 8) restarts the observable chain, which is why the assurance-mode choice matters. Chain depth is enforced at issuance via the delegation profile's construct (Section 5.4). Per hop, additionally: new iss, aud, jti, expiration, and signature; the subject stays identifiable across approved mappings; actor history follows the delegation profile; depth limits and data minimization apply. Derived-token lifetime is target policy (RFC 7523's exp bounds grant acceptance, not what the grant produces), set from grant freshness, issuer assurance, sender constraint, revocation capability, and resource; transitive lifetime bounds are an explicit profile decision (Required Decision 7).

Part II: Proposed Working-Group Disposition

10. Changes to ID-JAG

ID-JAG remains the human/XAA profile. Within this section, Resource Authorization Server is ID-JAG's own term for the target Authorization Server. These items carry different process weights and should be dispositioned separately: 10.2, 10.3, 10.4, 10.6, 10.7, 10.8, 10.9, and 10.10 are clarifications; 10.5 is a labeled breaking change needing implementer and migration input; 10.1 is a scope decision on an adopted draft requiring explicit working-group consensus; 10.11 is a dependency repair with its own urgency.

10.1 Constrain the Subject

State normatively that the ID-JAG subject is a human End-User; service and workload subjects belong to other profiles of the framework. The ID-JAG explicit type, requested token type, and grant-profile identifier are unchanged. This changes no wire behavior for conforming deployments: shipped XAA is human-scoped (Appendix A), and the non-human-subject texts in issues #73/#98/#115 and PR #119 are proposals, not deployed behavior. The separate actor_token tightening (10.5) is the breaking change.

10.2 Do Not Treat ID-JAG as an ID Token

An ID-JAG is an OAuth authorization grant carrying human identity context, not an OpenID Connect ID Token, and must not be used by the client as evidence of a login or session. Claims derived from an identity assertion are explicitly transcribed under issuer policy, target requirements, semantic agreement, and data minimization; a claim does not acquire ID Token semantics merely because it can also appear in an ID Token.

10.3 Separate Client Binding from Actor Identity

client_id is the client registration at the consuming Resource Authorization Server to which the grant is bound; the authenticated presenting client must match it. It does not identify the subject and is not a substitute for act. Its value comes from the out-of-band registration agreement between IdP and Resource Authorization Server and needs the same discipline as sub: stable and non-reassigned on both sides, because a recycled registration identifier silently mismatches or, worse, matches the wrong registration.

10.4 Define Dual-Principal Evaluation

The Resource Authorization Server authorizes the combination of: human subject; authenticated target client; target tenant and resource; requested scopes and authorization details; and actor context when a delegation profile is used. Accepting a subject does not authorize every client, and accepting a client does not authorize every subject. This human-plus-client evaluation is base ID-JAG's ordinary client-bound OAuth delegation (Section 5.4), involving no act (the client is not an RFC 8693 actor); the general effective-authority model is Section 9.

10.5 Make Actor Processing an Explicit Extension

Base ID-JAG assigns no meaning to actor_token or act:

• A client must not send actor_token outside a supported actor-delegation profile.
• An IdP implementing only base ID-JAG rejects actor_token.
• An issuer must not include act unless a supported profile defines its validation and derivation.
• A Resource Authorization Server rejects an unrecognized act composition.

may_act belongs in a delegation profile. This is a behavioral change from draft -04, which accepts actor_token without defined processing. The migration must never accept-and-ignore security-relevant input, because a caller could believe actor constraints were evaluated when they were discarded. Instead: requests without actor_token continue unchanged; a request carrying actor_token without an explicitly negotiated delegation profile is rejected immediately; discovery advertises support for the composition; and clients begin sending actor_token only after detecting that support. The mechanics of that advertisement and selection are Required Decision 12; until they exist, reject-unnegotiated is correct policy that is not yet mechanically implementable.

10.6 Add Typed Issuer-Authority Rules

For each ID-JAG issuer, establish that it is authoritative for the applicable human subject namespace and tenant, identify the claims accepted, constrain target clients and resources, and decide whether JIT creation or delegation extensions are permitted. Support for ID-JAG does not make an issuer authoritative for services, workloads, or actor relationships.

10.7 Separate Subject Resolution from Provisioning

Define the stable federated human binding independently of whether it was created through SCIM, JIT, an administrative API, or an existing SSO mapping. Grant validation and permission to create a local principal are separate authorization decisions.

10.8 Inherit the Core's Audience and Resource Slots

The core owns the slot definitions (Section 5.2), and ID-JAG's existing convention is the one the core adopts: the grant's aud identifies the consuming Resource Authorization Server and the protected resource is expressed in the resource slots. ID-JAG inherits the core rules unchanged; this section imposes no new behavior. It matters for providers operating one authorization server for multiple APIs, tenants, or resource identifiers; WAG's adoption is the normative change (Section 11, item 13).

10.9 Make Metadata Composition-Safe

Continue using authorization_grant_profiles_supported, clarifying that advertising two profiles independently does not mean they combine. A composed human-subject/workload-actor profile must be explicitly identified or advertised, never inferred.

10.10 Clarify Multi-Hop Behavior

An ID-JAG is issued to one Resource Authorization Server, redeemed only there, and never reused at another; each additional boundary requires a newly issued grant under Section 9's rule. Actor history is preserved only where a delegation profile defines it.

10.11 Resolve the Key-Bound Redemption Dependency

Adopted ID-JAG redeems cnf-bound grants through urn:ietf:params:oauth:grant-type:jwt-dpop, defined by an individual draft that expired in 2026-08. That is a live defect in shipped text, not a future design choice, so it carries ID-JAG-track urgency independent of WAG: revive the draft, incorporate its mechanics, or remove the dependency (Required Decision 14 states the options; WAG then matches the answer).

11. Recommended Changes to WAG

WAG, or an equivalent workload-self profile, remains self-only. These are deltas relative to draft-carleton-workload-authz-grant-00 (early and exploratory by its own description: plain RFC 7523 grant, no explicit type or requested token type, proof-of-possession open). The treatment is deliberately lighter than Section 10's: ID-JAG is adopted with shipped implementations, so its changes carry rationale and migration notes; WAG is early enough for direction-setting deltas. If WAG does not adopt them or stalls, the fallback is a new workload-self profile built directly on the candidate core; the layering does not depend on which document carries the workload profile.

1. Describe WAG as a workload-specific profile of the common framework and the Identity Chaining presentation pattern.
2. Keep on-behalf-of access out of the base profile.
3. Define direct-platform and enterprise-broker issuance modes, with the Section 7.2 assurance-mode and key-continuity prerequisites for the brokered mode.
4. Define WAG's principal granularity (Section 2.1), how the classification is carried as a protected discriminator (Required Decision 15), and prevent accidental account creation per ephemeral process.
5. Distinguish the workload subject, OAuth client, actor, and presenting key.
6. Use explicit JWT typing and grant-profile discovery.
7. Require key-bound grants by default; where bearer operation is permitted, define the weaker class per Section 5.3. An unauthenticated token request carrying a bearer grant otherwise turns assertion theft into workload impersonation.
8. Treat platform groups, roles, namespaces, and properties as authorization inputs, not portable permissions (claim registration is Required Decision 6).
9. Define issuer subject-authority and attribute-authority boundaries.
10. Define a stable JIT workload binding; SCIM and manual lifecycle stay optional.
11. Specify how a WAG or workload identity artifact serves as actor evidence under a separate delegation profile.
12. Reuse the common resource, response-confirmation, replay, and multi-hop rules (Sections 5.2, 9).
13. Adopt the core's audience and resource slots: a normative change from WAG-00 Section 5.1's dual-audience recommendation; the narrowing disclosure and transition rule are in Section 5.2.
14. Justify and scope the proposed broadening of WAG's subject from platform-hosted agents and workloads to all non-human self-subjects, including durable services: the lifecycle and attribute model must be shown to remain valid (Section 5.3), or the durable-service case gets its own profile.

12. Metadata and Capability Discovery

A target Authorization Server advertises the profiles it implements:

{
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag",
    "urn:ietf:params:oauth:grant-profile:wag"
  ]
}

This describes protocol capability only: it discloses no issuer, tenant, subject, client, resource, or attribute-namespace acceptance, and a composed-profile identifier discloses support for that composition (Section 10.9) and nothing more. Advertisement is not enforcement, and metadata labels servers, not incoming grants (Section 5.2). Composition is explicit: independent support for WAG and an actor profile does not mean the server accepts WAG actors for ID-JAG subjects; composed grants are rejected until Required Decisions 5 and 12 resolve, and how an issuing server learns which exact compositions a target accepts is Required Decision 12.

13. Recommended Standards Path

Phase	Goal	Defined in
1. Align the model	Vocabulary: principal types, principal granularity, functional roles, axes; agents are workloads or durable services, not a new category	Sections 2-3
2. Tighten existing profiles	ID-JAG human-only with client-bound delegation stated; WAG self-only; actor behavior only via a delegation profile; typed issuer authority; client and presenter binding	Sections 10-11
3. Extract the candidate core	Only the normative statements the tightened profiles demonstrably duplicate; preserve ID-JAG wire identifiers; WAG defines its own	Section 5.2
4. Define issuance modes	Direct platform issuance; brokered issuance with assurance mode, provenance, and key continuity	Section 7
5. Define delegation composition	act write authority; may_act eligibility; authorization-basis attenuation; composed-profile dispatch	Sections 5.4, 9; Required Decision 5; candidate: draft-mcguinness-oauth-actor-profile-00, or an equivalent conforming profile
6. Test interoperability	The Appendix E cases	Sections 5, 7, 9

Profiles are tightened before the core is extracted because the core is a candidate extraction from demonstrated overlap: the tightened profiles are the evidence of what they share (the pre-agreed audience slots being the stated exception, Section 5.2).

IANA implications. The eventual documents carry registry work: new explicit JWT types (Required Decision 1) in the media-types registry; urn:ietf:params:oauth:grant-profile:wag and any composed-profile identifiers in the OAuth URI registry (ID-JAG-04 already requests registration of the grant-profile sub-space and its own value; nothing is registered yet); any portable workload claims (Required Decision 6) in the JWT claims registry.

Venue and disposition. The pieces have different owners and sizes, and travel separately:

1. Coordinate with the WAG author before working-group circulation: the extraction argument requires the second profile to be real, and Section 11 asks that draft to redirect. This conversation gates item 2: confirm the Section 11 deltas will land, or invoke the fallback profile, before asking the working group to act on the PR #119 disposition; the two-profile pitch is hollow if it fails.
2. File the venue-appropriate asks now: close PR #119 with the Appendix A rationale; open ID-JAG issues per the Section 10 weighting (clarifications as a batch; 10.1 as an explicit scope-consensus call; 10.5 with implementer migration input; 10.11 immediately, as the dependency repair).
3. Lead the working-group discussion with a short decision memo carrying five points: ID-JAG stays human-specific with client-bound OAuth delegation; WAG (or an equivalent) as the candidate for non-human self-subjects; actor delegation composed separately; the Appendix D matrix decides whether a core document is justified at all, and the strategy is content with the answer being no document; and where service-self belongs (Section 5.3). This document is the supporting architecture. Publish it as an individual document, and charter the Appendix F questions as three tracks with named owners (ID-JAG scope and actor disposition; WAG and core mechanics; actor composition), with composition negotiation (Required Decision 12) as the shared dependency. And an explicit sequencing promise: no core document or trust-vocabulary work is chartered before the Appendix D matrix demonstrates actually duplicated normative text.
4. Keep the trust-record vocabulary (Section 6) out of working-group scope until the profile split lands; it is the piece most likely to be ruled operational rather than protocol. State the boundary plainly: the protocol work reduces credential-format and validation integration, it does not initially make issuer-authority configuration portable across providers, and a later operational profile, policy schema, or BCP addresses that portability. Phase 2's typed issuer authority is agreement on the security concept, not standardization of its configuration syntax.

14. Architecture Commitments

Five architectural commitments carry the design; everything else is downstream mechanism. This is deliberately not the Section 13 memo's list: the memo names the five points the working group is asked to decide (including the open service-self question), while these state what the architecture itself commits to; the memo's points map onto commitments 1, 2, and 5 plus the Section 10 disposition and the Section 5.3 service-self proposal.

1. The human/non-human profile split (ID-JAG stays human-subject; WAG or an equivalent is the candidate for non-human self-subjects).
2. The self-subject/delegated-actor split (actor delegation composes; it is never folded into a subject profile).
3. Explicit profile typing and two-stage dispatch (Section 5.2).
4. One newly issued grant per trust-domain boundary, with additions only by explicit reauthorization (Section 9).
5. A shared RFC 7523 conventions document only if ID-JAG/WAG alignment demonstrates the overlap (Appendix D); no document is an acceptable answer.

The sixteen tracked Required Decisions that follow from these, each with owner, interim, and venue track, are Appendix F: an implementation backlog resulting from the architecture, not blockers to the five decisions above. The roads not taken, including the strongest rival (one grant with entity profiles), are Appendix H.

15. Security Considerations Index

Threat-relevant material lives with its mechanism: cross-JWT confusion and profile dispatch (5.2); the bearer class and key-capability rule (5.3); client-vs-actor classification (5.4); broker assurance modes, over-assertion visibility, actor identity authority, and issuance-time key continuity (6, 7.2); reauthorization versus transitive authorization provenance (9, 7.2); derived-token lifetime (9); subject and client-identifier recycling (8, 10.3); replay classes (Required Decision 9); and the incident record behind each control (Appendix B).

16. Conclusion

The model in seven questions: who owns the authority (subject); who exercises it (actor); which application participates (client); which runtime and key present it (presenter); who is trusted to assert each fact (typed issuer authority); how authority crosses a boundary (Identity Chaining plus a newly issued grant); and whether downstream authority can be independently compared with upstream (the attenuation and provenance profiles).

ID-JAG converts a trusted human identity assertion into a cross-domain authorization grant for XAA, with the registered client holding ordinary OAuth delegated access, never an act actor. WAG lets a trusted non-human subject obtain authorization as itself. Actor delegation adds the case where a principal beyond the presenting client exercises another principal's authority. The target Authorization Server needs no distinct engine per case: shared envelope validation, deterministic profile dispatch, and typed profiles carrying the semantics, with trust records carrying the policy. Direct platform trust and enterprise brokering, under the assurance-mode and key-continuity prerequisites, converge on that one grant-processing model. The layering avoids turning ID-JAG into a universal identity token, avoids forcing WAG to solve human delegation, and prevents recreating the same cross-domain machinery per principal type. The author's disposition of the preceding proposals, including the intended withdrawal of PR #119, is Appendix A; the venue plan is Section 13.

References

• The OAuth 2.0 Authorization Framework, RFC 6749.
• JSON Web Token (JWT), RFC 7519.
• Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, RFC 7521.
• JSON Web Token Profile for OAuth 2.0 Client Authentication and Authorization Grants, RFC 7523.
• OAuth 2.0 Token Exchange, RFC 8693.
• Resource Indicators for OAuth 2.0, RFC 8707.
• JSON Web Token Best Current Practices, RFC 8725.
• OAuth 2.0 Demonstrating Proof of Possession (DPoP), RFC 9449.
• OAuth Identity and Authorization Chaining Across Domains, draft-ietf-oauth-identity-chaining-17.
• Identity Assertion JWT Authorization Grant, draft-ietf-oauth-identity-assertion-authz-grant-04.
• Workload Authorization Grant, draft-carleton-workload-authz-grant-00.
• AI Agent Authentication and Authorization, draft-klrc-aiagent-auth-03.
• OAuth Actor Profile for Delegation, draft-mcguinness-oauth-actor-profile-00.
• OAuth 2.0 Attestation-Based Client Authentication, draft-ietf-oauth-attestation-based-client-auth-10.
• OAuth 2.0 JWT Authorization Grant with DPoP Binding, draft-parecki-oauth-jwt-dpop-grant-01 (expired).
• Workload Identifier, draft-ietf-wimse-identifier-03.

Appendix A: Relationship to Issue #73 and PR #119

Issue #73 (2026-01) identified the requirement: a workload or agent authenticating as itself across authorization domains, alongside the human XAA case. PR #119 (2026-08, open with changes requested) proposed adding workload and agent principals natively to ID-JAG. This document is the alternative: the requirement is unchanged, but its home moves. ID-JAG stays human-subject; the workload case goes to WAG (or an equivalent) over the candidate core; delegation is a separate profile. If adopted, the author withdraws PR #119: its subject-token additions and consent-absence security considerations carry into the workload profile and core, and its ID-JAG changes reduce to the Section 10 constraints. Issues #98 and #115 already documented the pressure on ID-JAG's subject model; the core/profile split resolves it without expanding base ID-JAG.

The direction changed for evidence-backed reasons:

1. The landscape changed after #73. In January 2026 there was no workload authorization-grant profile, so ID-JAG was the only candidate home. draft-carleton-workload-authz-grant-00 (2026-08-03) now provides one on the same RFC 7523 rail; it is early and exploratory by its own description, and Section 11 records its gaps, but adding workload principals natively to ID-JAG today would create two competing homes for the same case.
2. Deployed workload federation diverges from human federation on exactly the dimensions a merged profile must unify. Consent becomes administrator-configured trust policy; subject mapping becomes JIT or no durable account; the claim surface becomes platform properties. PR #119 itself had to add an "absence of End-User consent semantics" security section: the two cases differ at the security-model layer, not just in the noun, and the divergence has grown with each design round (key-bound defaults versus optional DPoP, per-type replay classes, subject-evidence rules, issuance-time key continuity). Eight of the sixteen Required Decisions are workload-side; under one document each lands as a revision to adopted text, and Decision 14 already demonstrates what a single shared dependency costs the human profile.
3. Proof-of-possession postures differ by key capability. Workload presenters can hold keys and should present key-bound grants; the human XAA path redeems through an authenticated registered client. The bearer-theft record (Appendix B) and WIMSE's key-bound direction favor mandatory key binding for workload grants; a merged profile would need principal-conditional normative requirements that separate profiles state cleanly.
4. Feedback on #73 previewed the failure mode. The observation that XAA "is very good at duck typing" and "does not care about agents or workloads" describes untyped subject overloading, the pattern that let OIDC ID tokens drift into workload use and produced Appendix B's misconfiguration class. The core's dispatch rule (Section 5.2) is the remedy.
5. Shipped XAA is human-scoped. Okta's Cross App Access documentation excludes autonomous agents and machine-to-machine workflows: deployment evidence of current scope, not by itself a protocol argument (those are items 1-4). Wire-behavior impact is stated in Section 10.1.
6. This is how OAuth already factors. RFC 7521 separates the assertion framework from its profiles; Token Exchange is a principal-agnostic core that others profile. Aligning on demonstrated shared invariants follows the established pattern.

Appendix B: Deployment and Incident Evidence

Each incident class motivates a specific control; no single control covers the set, and none of these incidents is evidence for every remedy at once.

Record	Failure class	Control it motivates
Unit 42, "OH-MY-DC: OIDC Misconfigurations in CI/CD" (https://unit42.paloaltonetworks.com/oidc-misconfigurations-in-ci-cd/)	Missing or permissive claim validation; spoofable audiences; subject-claim manipulation	Typed issuer authority (Section 6); audience and resource slots (Section 5.2)
Datadog Security Labs, "Exploring GitHub-to-AWS keyless authentication flaws" (https://securitylabs.datadoghq.com/articles/exploring-github-to-aws-keyless-authentication-flaws/)	Overly permissive trust policies	Typed issuer authority (Section 6)
GitHub, "Immutable subject claims for GitHub Actions OIDC tokens" (https://github.blog/changelog/2026-04-23-immutable-subject-claims-for-github-actions-oidc-tokens/)	Mutable, reassignable subject identifiers (name recycling)	Immutable, non-reassigned subjects (Section 8)
Codecov, April 2021 post-mortem (https://about.codecov.io/apr-2021-post-mortem/)	Long-lived secret theft from CI	Short-lived federated grants
CircleCI, January 2023 incident report (https://circleci.com/blog/january-4-2023-security-alert/)	Long-lived secret theft; vendor guidance: "Use OIDC tokens wherever possible"	Short-lived federated grants
IETF WIMSE working documents	Bearer assertion theft: possession suffices; audience confusion	Key binding (Section 5.3); audience restriction
Cross-JWT confusion (JWT BCP class)	One JWT accepted as another kind	Explicit typing and dispatch (Section 5.2)

The caveat matters as much as the record: explicit typing would not have prevented a correctly typed token accepted under a permissive subject or audience policy, and key binding does not fix mutable subjects. Each control earns its place from its own row.

Appendix C: Worked Example (Illustrative, Non-Normative)

Values are illustrative. C.1 depends on Required Decisions 1 (typing), 2 (proof mechanism, shown DPoP-style), 3 (tenant binding), 8 (policy context), 9 (replay contract), 11 (resource reconciliation), and 15 (subject classification; here the trust record fixes one combination per issuer under the interim). C.2 additionally depends on 4 (provenance), 5 (composed-profile identification), and 12 (composition negotiation); under the Required Decision 5 and 12 interims a target rejects the C.2 grant today, so C.2 illustrates the target state. Subjects and namespaces follow WAG-00's own example style.

C.1 Direct WAG, workload acting as itself

The platform issues a grant for a durable agent using the instance-as-presenter pattern (Section 2.1): sub names the logical agent; the runtime instance holds the cnf key.

{
  "typ": "<wag profile type, Required Decision 1>",
  "alg": "ES256",
  "kid": "platform-key-2026-08"
}
.
{
  "iss": "https://acme.agents.platform.example",
  "sub": "wimse://acme.agents.platform.example/agent/7f3d9a2e",
  "aud": "https://as.saas.example",
  "iat": 1785271680,
  "exp": 1785271980,
  "jti": "7d0f5a2b-93c8-4f0e-9c33-1b6a0e6d5f10",
  "namespace": "acme/support",
  "cnf": { "jkt": "<thumbprint of the agent instance key>" }
}

The client redeems it, supplying possession evidence for the cnf key:

POST /token HTTP/1.1
Host: as.saas.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof JWT over this token request, signed by the key matching cnf.jkt>

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<grant JWT>
&resource=https://api.saas.example/

Target Authorization Server processing, in order:

1. Use the untrusted iss and header type only to select an already configured trust record, candidate validation policy, and key-resolution rules; an unverified iss never authorizes issuer discovery or JWKS retrieval outside that configuration. Verify the signature under the selected policy; nothing is trusted before verification succeeds.
2. Confirm the dispatched profile matches the request's policy context (Section 5.2; Required Decision 8).
3. Resolve the issuer tenant: here the per-tenancy issuer identifies the customer; at a shared issuer, a signed tenant claim or an exactly registered subject origin resolves it (Section 6).
4. Load the trust record: verify issuer authority for this principal type, subject class, granularity, and namespace (fixed per issuer under the Required Decision 15 interim, since the grant carries no classification claim), and that the dispatched profile is in accepted_profiles (conjunctive with step 2; any conflict rejects).
5. Verify aud, lifetime, and jti per the profile's replay rules (Required Decision 9: bearer grants single-use, failing closed on replay-store unavailability; key-bound grants per profile policy).
6. Verify possession: the proof MUST be signed by the key whose thumbprint equals the grant's cnf.jkt; a valid proof over any other key is rejected.
7. Reconcile the authorization: the resource parameter, any profile-defined resource claim, and the trust record's target_constraints.resources, under the profile's resource-matching rules (Required Decision 11); the issued token is bounded by the reconciled result.
8. Map namespace and other asserted attributes to local entitlements under local policy.
9. Issue a sender-constrained access token bounded per step 7, with a lifetime set by target policy (Section 9):

HTTP/1.1 200 OK
{ "access_token": "<sender-constrained token>", "token_type": "DPoP", "expires_in": 240 }

The example redeems over jwt-bearer with an accompanying proof; whether key-bound grants instead use the dedicated jwt-dpop grant type, as adopted ID-JAG does, is Required Decision 14.

A profile mismatch at step 2 fails closed:

HTTP/1.1 400 Bad Request
{ "error": "invalid_grant",
  "error_description": "grant profile not accepted for this client and resource" }

Every other failure branch (untrusted issuer, signature failure, unknown kid, tenant mismatch, non-authoritative issuer, expired or replayed jti, invalid possession proof) also rejects. Which branches must return an indistinguishable generic error, to avoid giving an attacker a configuration oracle, is error-semantics work the eventual profile documents owe alongside Required Decision 9.

C.2 Delegated variant, agent acting on behalf of a user

Inbound, the broker runs a Token Exchange (subject_token authenticates or resolves the user; the authorization decision is the broker's, never the token's):

POST /token HTTP/1.1
Host: broker.customer.example
Content-Type: application/x-www-form-urlencoded
Authorization: <client authentication for saas-client-registration-42>
DPoP: <proof over this request, signed by the agent instance key>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=<composed token type URI, Required Decisions 5 and 12>
&audience=https://as.saas.example
&resource=https://api.saas.example/
&authorization_details=<requested operation>
&subject_token=<identity evidence for the user>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&actor_token=<platform assertion for the agent, cnf-bound to the instance key>
&actor_token_type=urn:ietf:params:oauth:token-type:jwt

The request now carries every input the authorization decision consumes: audience names the target Authorization Server, resource and authorization_details name the requested rights (RFC 8693 defines these parameters so the server can apply target-specific policy), the Authorization header authenticates the OAuth client and is the basis for the issued grant's client_id, and the DPoP header proves possession of the actor instance key, which is not client authentication (RFC 9449); the two roles stay distinct even when one entity holds both. The caller-to-actor binding is what makes this safe (Section 7.2): the actor_token is already cnf-bound to the same instance key the DPoP proof uses (inherited_key_binding), so the broker has an authenticated binding among the asserted actor identifier, the caller, and the key it will place in the issued grant's cnf. Possession of a key alone would prove nothing about who is calling; an orchestrator presenting a bearer actor assertion would need attested_subject_key_binding or client authentication registered to the agent (authenticated_subject_key_binding) instead. Neither token authorizes their combination. The broker separately authorizes the pair (subject, actor, client, target, requested rights) under delegation-profile policy or validated delegation evidence: user or administrator policy naming this actor for this subject, a delegation receipt or grant binding the pair and its constraints, or a pre-administered relationship. A validated may_act claim establishes subject-actor eligibility only; the broker still authorizes the client, target, resources, and requested rights under local policy (a constrained delegation receipt can cover more of the tuple; may_act alone cannot). Identity plus freshness never substitutes for that decision: a fresh stolen ID token paired once with a legitimate agent is still an unauthorized pairing. Subject evidence is separately validated for maximum age and a replay policy fit to its type (Required Decision 9, Section 7.2). The issued grant carries no upstream provenance claim, so this example operates in authoritative-transformation mode: the target relies on the broker's trust record, not verifiable upstream evidence (a transitive-provenance variant would add the Required Decision 4 evidence).

The broker issues a grant with the human as subject and the agent as current actor. Per Section 2.1's per-role granularity: subject human, actor the logical agent, presenter the agent's runtime instance holding the cnf key.

{
  "typ": "<composed type or subject type plus composition marker, Required Decisions 5 and 12>",
  "alg": "ES256",
  "kid": "broker-key-2026-08"
}
.
{
  "iss": "https://broker.customer.example",
  "sub": "u-3f81c7",
  "act": {
    "iss": "https://acme.agents.platform.example",
    "sub": "wimse://acme.agents.platform.example/agent/7f3d9a2e"
  },
  "delegation_depth": 1,
  "client_id": "saas-client-registration-42",
  "aud": "https://as.saas.example",
  "iat": 1785272100,
  "exp": 1785272400,
  "jti": "0b9c4e61-6a1f-4a35-9d55-2e8c7b1f9a02",
  "cnf": { "jkt": "<thumbprint of the presenting instance key>" }
}

The broker wrote act under evidence the delegation profile defines; act identifies the current actor and is attribution history beyond that (Section 5.4). act.iss makes the actor identifier's namespace context explicit (the candidate profile's canonical pair); transcribing under the platform's namespace still requires actor identity authority (Section 6, Required Decision 10). delegation_depth is the enforceable-depth construct of Section 5.4, a top-level profile-defined claim, because nested act is excluded from access control. client_id names the presenting registered client, a role distinct from the actor. The target evaluates the subject's authority and the policy governing this actor independently, bounded by Section 9.

Appendix D: Core Overlap Matrix

Phase 3's question (Section 5.2): which rules would ID-JAG and WAG otherwise duplicate?

Rule	RFC 7523	Identity Chaining	ID-JAG	WAG-00	New common text needed?
Redemption mechanics	Defines	Uses	Uses	Uses	No
Cross-domain choreography; new grant per boundary	No	Defines	Uses	Absent	No
Audience and resource slots	Permits either aud form	Acquisition parameters	aud = target	Dual aud	Yes, small
Explicit typing and two-stage dispatch	No	No	Own typ	None	Yes: the discipline; values stay profile-specific
Temporal claims; issuer-scoped jti	Partial	No	Own rules	Own rules	Yes, one convention
Profile-vs-policy-context enforcement	No	No	No	No	Yes
Replay behavior, cnf processing, mandatory-to-understand contents, principal semantics, trust administration	Varies	No	Profile-specific	Profile-specific	No: profile-specific by design

Appendix E: Interoperability Test Cases

Phase 6 (Section 13), at minimum:

1. Direct workload acting for itself.
2. Brokered workload acting for itself.
3. Human subject with workload actor.
4. Service subject with workload actor.
5. Multi-hop delegated access, verifying each hop's authorization basis, with claim-subset checks only where hops share a claim namespace.
6. Pre-provisioned and JIT local principal mappings.
7. Issuer rejection for an unauthorized principal type, subject class, granularity, or namespace, including a subject outside any registered subject origin at a shared issuer, and an actor asserted outside the issuer's actor identity authority.
8. Profile rejection: a WAG where policy expects an ID-JAG, and the reverse; a composed grant rejected while Required Decision 5 is open.
9. Replay and key-binding failures, including a bearer-class redemption failing closed on replay-store unavailability.
10. Issuance key-continuity failure: a valid upstream assertion with a mismatched possession proof, or an unauthenticated caller proving its own key, is rejected.

Appendix F: Protocol Design Questions (Required Decisions)

These are decisions the design depends on, not open-ended questions; each needs an owner and a proposal. They are not an all-or-nothing program. By track: ID-JAG disposition happens now through Section 10, not this list; WAG viability needs Decisions 1, 2, 3, 8, 9, 11, and 15; Decision 14 is ID-JAG-track work with its own urgency (Section 10.11) whose outcome WAG inherits as a prerequisite; delegation composition needs 5, 10, 12, and 13; the rest (4, 6, 7, 16) are later work, with 16's requirement already in force through its interim (Section 7.2). The short memo (Section 13) asks consensus only on the architectural split and the WAG-viability minimum.

1. Grant typing and dispatch. One generic typ plus a protected payload profile identifier, or profile-specific explicit types. Distinct explicit types are preferred because they permit mutually exclusive validation-policy selection before any payload claim is trusted (RFC 8725); a protected payload discriminator is viable only where every candidate profile shares a safe common cryptographic validation envelope, and where validation policy must differ per profile, explicit typing is effectively required. ID-JAG identifiers unchanged either way.
2. WAG proof-of-possession minimum. The key-binding and sender-constraining mechanism, and the bearer class terms (Section 5.3). Attestation-based client authentication is a candidate for the presenter-authentication half. Interim: key-bound only; the bearer class is unavailable until defined.
3. Tenant binding. Whether a claim carries the issuer tenant directly, and how origin or tenant registration is validated against issuer-published metadata. Interim mechanisms (Section 6): per-tenant issuers; a signed tenant claim with an exact registered issuer/tenant relationship; or exact-match registration of structurally defined subject origins. Freeform path-prefix and longest-match tenant selection are excluded.
4. Provenance representations for the transitive-provenance broker mode (Section 7.2), kept separate by evidence class: identity provenance (origin of subject and attributes), authorization provenance (upstream authorization basis and restrictions), and delegation provenance (subject-actor relationship). Over-assertion detection (Section 9) is only as strong as the class actually preserved and understood.
5. Composed-profile identification: a named composite identifier whose specification defines the combined behavior; a profile set (a space-separated list on scope's precedent), viable only with a defined composition algebra (conflict resolution, ordering, ownership of overlapping semantics, permitted sets, versioning); or subject-profile typ plus a protected claim for delegation semantics, the candidate actor profile's shape (Section 5.4). Interim: composed grants rejected (Sections 5.2, 12).
6. Portable workload attribute claims: which platform attributes, if any, get registered claim names, and each profile's mandatory-to-understand claim set (Section 5.2).
7. Lifecycle propagation: how workload retirement and attribute changes propagate beyond short credential lifetimes. Offline JWKS validation cannot observe revocation, so a grant remains valid until expiry; short lifetimes bound but do not close the gap. Whether a profile imposes transitive lifetime bounds on derived tokens (Section 9) is part of this decision.
8. Policy-context binding. How a token-endpoint request declares or derives the expected profile from its inputs: client registration when present or required, presenter identity or key, issuer, tenant, resource, endpoint, including the explicit-absence-of-client-authentication case a profile may permit (Section 5.2). Client registration is an input where it exists, not a core invariant. Error-disclosure policy is decided here as one general rule: which rejection branches (profile, issuer, tenant, client, replay, and proof mismatches) return an indistinguishable generic error (Appendix C.1).
9. Replay contract. Two obligations, not one: issuers generate collision-resistant, issuer-unique jti; verifiers retain redemption state only where the profile defines single-use or bounded-use semantics (single-use: through exp plus clock skew). Key-bound reusable grants need no replay store, and RFC 7523 makes replay detection optional. Profiles distinguish bearer-grant replay, key-bound reuse by the legitimate holder, proof replay, idempotent retry, concurrent malicious redemption, and subject-evidence replay in delegated exchanges (Section 7.2). Interim: bearer-class grants are single-use, failing closed on store unavailability; key-bound grants define their own rules. Owning single-use means owning its cost: multi-region active-active implies synchronous deduplication or an accepted replay window.
10. Actor identity authority. Which actor identifier namespaces an issuer may assert in act, whether asserted actor identity is broker-canonical or transcribed from upstream, when act requires its own iss (the candidate actor profile answers this half: the canonical actor identifier is the (act.iss, act.sub) pair), and how an upstream actor identity links to a broker-canonical one (Section 6).
11. Resource reconciliation semantics. Exact matching versus configured mapping; single versus multiple resources; behavior when the grant or request omits a value; invalid_target versus invalid_grant on mismatch; reconciliation with scope and authorization_details; and whether URI structure carries any meaning. RFC 8707 permits local mapping and multiple resources and defines no generic intersection algorithm, so these semantics must be normative in the profile or core, not the worked example.
12. Composition negotiation. Required Decision 5 identifies an issued composed grant; this decision covers the request path: how a Token Exchange request selects a composed profile (requested_token_type alone requests the subject profile, and actor_token presence selects no semantics or version); how a target advertises exact supported compositions rather than independent capabilities; how the issuing server discovers or is configured with that support; what appears in issued_token_type and the composed typ; and confirmation that unsupported or ambiguous composition is always rejected. The same mechanism carries required-extension identification (Section 5.2): its on-wire location and processing are decided here.
13. Explicit-actor classification. The explicit_actor_required property (Section 5.4) is part of the security model: who classifies a client registration, where the classification is registered, how an upstream issuer learns it, how it binds to client, tenant, and resource, and whether the target can enforce it independently of issuer behavior. A resource-wide setting does not necessarily solve per-client classification. Classification is role-specific: subject_class classifies sub; actor classification travels inside the actor representation; client classification lives in the client registration or target policy. explicit_actor_required is a policy about the client-subject relationship, so its trigger is the client's classification, not the subject's, and an agent acting as the WAG subject for itself requires no act merely for being an agent.
14. Redemption grant type for key-bound grants. Adopted ID-JAG redeems cnf-bound grants through urn:ietf:params:oauth:grant-type:jwt-dpop, defined by an individual draft that is currently expired, while bearer grants use jwt-bearer (Section 5.2). First decide that dependency's fate: revive the draft, incorporate its mechanics into the core or a profile, or remove the dependency. Then decide what the core supports: both grant types (matching adopted ID-JAG, if the dependency stands), proof processing over jwt-bearer, or rejection of the dedicated grant type; WAG must give the same answer.
15. Subject classification on the wire. A trust record can authorize principal types, subject classes, and granularities, but a base WAG carries no protected discriminator, so typed issuer authority cannot be applied deterministically. The mechanism carries three independent values, never a mixed flat vocabulary: principal type (human, service, workload), optional subject class (such as agent), and principal granularity (logical principal or runtime instance). Options: one profile per combination; distinct profile identifiers or typ values per variant; protected classification claims (the actor profile's sub_profile is the actor-side parallel); or the issuer trust record fixing one combination for every assertion from that issuer. Interim: the trust record fixes one combination per issuer, and the Appendix G example is consistent with it (one type, one class, one granularity).
16. Grant key-binding assurance signaling. The key-continuity modes (Section 7.2: inherited_key_binding, authenticated_subject_key_binding, attested_subject_key_binding, authorized_key_designation) are security-relevant per grant, and the question is general to any issuer, direct platform or broker: a target must be able to tell which assurance produced a particular grant's cnf, or a designated-key grant can be read as possession-proven. Options: a protected assurance-mode claim, distinct profiles or typ values, separate issuers or signing keys per class, or target policy fixing one mode per issuer. The decision includes downgrade behavior and whether the mode survives subsequent hops. Interim: a target fixes one mode per issuer trust record.

Appendix G: Illustrative Trust Record and Assurance Modes (Non-Normative)

A trust record conceptually equivalent to (Appendix C.1 shows it in use). Field mapping to Section 6's authorities: authoritative_for carries subject authority; attribute_authority and delegation_authority are named directly (actor identity authority extends the latter, illustrated as actor_namespaces); target_constraints carries authorization authority; proof_requirements carries credential authority.

issuer: https://issuer.example
customer_tenant: customer-123

authoritative_for:
  principal_types: [workload]
  subject_classes: [agent]                     # optional class axis (Section 2.1)
  principal_granularity: logical                 # logical | runtime_instance
  presentation_model: instance_as_presenter      # composition of granularity and role (Section 2.1)
  subject_origins:            # exact match; never path-prefix
    - scheme: wimse
      trust_domain: customer.example

accepted_profiles:
  - wag

attribute_authority:
  - namespace
  - workload_class
  - groups

delegation_authority:
  permitted: false
  actor_namespaces: []          # actor identity authority (Required Decision 10)

target_constraints:
  audiences:
    - https://as.service.example
  resources:
    - https://api.service.example/

proof_requirements:
  grant_key_binding: required
  access_token_sender_constraint: required

The issuance-time key-binding assurance modes (Section 7.2):

• inherited_key_binding: the upstream assertion is already bound to the same key (key-bound upstream only; cannot repair a bearer upstream).
• authenticated_subject_key_binding: the caller proves possession during the exchange AND the issuer validates an authenticated binding between caller and asserted subject (client authentication registered to that subject, or an equivalent authenticated session). Possession alone is not this mode: an unauthenticated attacker with a stolen bearer assertion can prove its own key.
• attested_subject_key_binding: attestation binds the asserted subject identifier to the requested key.
• authorized_key_designation: a trusted intermediary is explicitly authorized to select the downstream key. It proves authorization to designate, never possession; not a proof-of-possession mode, and a target accepting it must know it is doing so.

Appendix H: Alternatives Considered

One grant with entity profiles (ID-JAG carrying both use cases, a subject discriminator distinguishing them). The strongest rival, and the original PR #119 shape. Where it wins: fewest documents; no cross-typ composition negotiation; one parser. Why not adopted:

1. Routing and validation-policy selection. Both a header type and a payload discriminator are untrusted routing inputs confirmed only after validation; neither is intrinsically more trustworthy, and a misconfigured issuer can write either. Explicit types are preferred because they follow the JWT BCP's explicit-typing and mutually-exclusive-validation guidance (RFC 8725 Sections 3.11 and 3.12), are conventional library-visible routing metadata, keep per-profile validation policies cleanly separated, and reduce accidental cross-profile acceptance. This architecture deliberately permits pre-verification routing only on tightly controlled fields, iss and the header type, never arbitrary payload parsing; and where candidate profiles do not share one validation envelope (human IdPs, platform issuers, and brokers do not), the routing field must select among per-profile validation policies, which header typing serves operationally. The real boundary in either design is the verifier's configured association among issuer, type or profile, keys, and rules. The load-bearing claim is therefore empirical, never logical: these populations fail the shared-envelope precondition, and that failure, not any intrinsic property of payload claims, is what survives scrutiny.
2. The security models diverge below the noun. PR #119's own consent-absence security section is the receipt: consent versus administrator trust policy, key-bound defaults versus optional DPoP, SSO resolution versus JIT-or-no-account, different replay classes. One document becomes a lattice of principal-conditional MUSTs, and every workload-side change reopens adopted, shipping XAA text.
3. Issuer-authority typing collapses. With one grant type, an issuer trusted for human SSO mints artifacts that parse identically as workload grants; the only separator is a claim that issuer writes. Separate profiles make "authoritative for humans, not workloads" enforceable at the dispatch layer (per-issuer accepted_profiles), not downstream of trusting the token; a trust record can restrict accepted payload profiles just as it restricts types, so separate types buy isolation and implementation discipline rather than a control unavailable any other way, and neither stops an over-authorized issuer. The isolation is still worth having: with separate types, cross-population acceptance requires two independent misconfigurations (accepting that type, from that issuer), while one type plus an entity claim requires one, checked after full validation inside a shared pipeline with internal branching, the topology where JWT confusion failures have historically lived. Operational is not a demotion; the famous JWT confusion failures were operational.
4. The hard case saves nothing. Subject-is-human plus actor-is-workload needs the delegation machinery and composition negotiation regardless; a subject-side discriminator only adds a second way to be an agent inside one document.
5. The economics invert once counted. Each entity profile needs its own claims vocabulary, security considerations, and lifecycle text; the annexes are the profile documents at the same page count with worse coupling, while this strategy's core may legitimately be zero new documents.

Where it survives: classification within an already-dispatched profile (sub_profile in the actor representation; subject class in trust records, Required Decision 15), and as the named fallback if the working group refuses multiple documents, viable exactly when all candidate profiles share one safe validation envelope.

Exchange-only (no grant profiles; RFC 8693 at every target). Where it wins: zero new wire formats, and it is the deployed baseline (cloud workload identity federation). Why not adopted: it pushes issuer trust to every target, which is the N × M problem itself; the IdP-brokered decoupling is the point of XAA; delegation processing stays undefined; and its unprofiled misconfiguration record is Appendix B. Where it survives: chaining explicitly permits exchange acquisition, and targets may federate directly where they choose.

Workloads as clients only (no WAG; federated client authentication plus client credentials). Where it wins: removes the WAG dependency entirely; widely implemented. Why not adopted: it loses subject semantics that deployed relying parties demonstrably use (service users and service principals resolved as subjects), collapses entitlements onto client_id (the client-versus-subject conflation the roles table forbids), and reintroduces per-target registration. Where it survives: as the Section 5.3 client-role branch, which is this architecture's own answer for entities acting only as clients.

Capability and attenuation tokens (GNAP or Biscuit-shaped delegation by caveat). Where it wins: attenuation is structural rather than policy. Why not adopted: cross-domain authorization is semantic reauthorization, not caveat-appending (Section 9), the ecosystem's rails are JWT and OIDC discovery (Appendix B's record is of that world), and adoption of caveat-based models has remained limited. Not pursued.

Appendix I: The Product Surface (Non-Normative)

The wire and the trust records are not the whole story; the product surface has its own requirement. People will @-mention the support agent in a thread, assign it a ticket, share a document with it, and expect it to have an avatar and a profile card. The affordances are user-shaped; the entry they attach to is a principal, not a person.

The affordances attach to the logical principal. You @-mention the durable agent, and whichever instance is running answers; presence is instance liveness surfacing on the logical entry. The handle is addressing, never identity: @support-agent is a mutable, per-workspace attribute exactly like a human's handle, while the identity underneath stays the canonical four-part key of Section 8, whose rule that mutable names are never identity keys is exactly this point at the product layer. GitHub's [bot] suffix has this shape, a display marker over a stable ID, and platform bots and assignable coding agents have already normalized non-human members in the directory.