OAuth Identity Assertion Trust Framework

1.1. Minimal Deployment

The smallest deployment has three moving parts:¶

1. A Resource Authorization Server publishes a Trust Policy (Section 4.2) saying which issuer-trust evidence it requires.¶

2. A Subject Authority publishes a DAI policy ([DAI]) saying which Assertion Issuers it authorizes for its namespace.¶

3. At the token endpoint, the Resource Authorization Server validates the assertion and requires one successful Trust Method in each applicable trust-evaluation category.¶

For the common case, the Resource Authorization Server lists domain_authorized_issuer; the Subject Authority publishes a DNS TXT record at _oauth-issuer-policy.{domain}; and the Resource Authorization Server checks that the assertion's iss appears in that policy for the asserted subject namespace.¶

1.2. Trust Evaluation Categories

This document defines two independent trust-evaluation categories for OAuth identity assertions (Section 3.2):¶

• issuer_authentication is the Authenticity category. It asks: is the JWT iss claim a recognized signer?¶

• subject_namespace_authorization is the Delegation Authority category. It asks: has the namespace owner authorized this issuer to assert about subjects in its namespace?¶

Each Trust Method belongs to one or more of these categories, and evidence is required from each applicable category (Section 3.2.1).¶

1.3. Motivating Use Cases

Deployments where the gap between issuer authentication and namespace authorization has practical consequences include:¶

• Workforce SSO into multi-vendor SaaS: per-customer bilateral issuer configuration, with no wire-format check that the configured Assertion Issuer is the one the customer authorizes.¶

• AI agent platforms acting across tool boundaries: the tool needs to know the platform is entitled to assert about users in the customer's namespace (Appendix D).¶

• B2B integrations carrying end-user identity: today these either accept any authenticated Assertion Issuer or maintain manual allowlists.¶

• Shared-issuer multi-tenant Identity Providers: the customer's choice of authorized tenant becomes observable on the wire ([DAI] §Single-Issuer Multi-Tenant Identity Providers) rather than implicit.¶

Today's alternatives are bilateral OAuth configuration, federation membership treated incorrectly as a proxy for namespace authority, or implicit trust in tenant-domain bindings; this document provides a wire-format alternative.¶

1.4. Relationship to Existing Mechanisms

This policy is complementary to OpenID Federation: OpenID Federation can authenticate that an issuer belongs to a trusted ecosystem, while the Domain-Authorized Issuer Trust Method lets the namespace owner say which issuers may assert about subjects in that namespace. This document also follows existing DNS authority-publication patterns such as CAA, MTA-STS, SPF, DKIM, and the Email Verification Protocol. Background and positioning details are in Appendix A.1 and [DAI] §Following Existing DNS Authority Patterns.¶

This framework is distinct from issuer discovery mechanisms such as WebFinger [RFC7033] and OpenID Connect Discovery [OIDC-DISCOVERY], which answer "given a user identifier, which issuer should a client use?" before authentication. This framework answers the verifier-side question "may this issuer, having already produced an assertion, be trusted for this subject's namespace?" Its answer is published per namespace, expresses authorization rather than routing, and is consumed at verification time. See [DAI] §Following Existing DNS Authority Patterns.¶

1.5. Documents in the Family

This document and [DAI] form a two-document set:¶

• This document: the Authority Delegation Model (Section 3) and the Identity Assertion Issuer Trust Policy (Section 4.2) published by a Resource Authorization Server, plus the Trust Method machinery, OAuth grant profile bindings, and the Subject Authority Determination concept.¶

• [DAI]: the OAuth Domain-Authorized Issuer Trust Method, defining the domain_authorized_issuer Trust Method and the Issuer Authorization Policy wire format it consumes.¶

This document does not define the Issuer Authorization Policy wire format; that lives in [DAI]. This document defines what an Assertion Issuer must satisfy to be accepted; DAI defines one class of evidence supplying that satisfaction.¶

1.6. Scope

The scope of this document is:¶

• The Authority Delegation Model (Section 3): vocabulary, trust-evaluation categories, combination rule, lookup states, and the bounded-transitivity property profiles inherit.¶

• The Trust Policy document (Section 4.2).¶

• The Trust Method machinery (categories, registry).¶

• The Subject Authority Determination concept and registry.¶

• The OAuth grant-profile bindings.¶

Concrete publication mechanisms for specific Trust Methods are out of scope and live in dedicated specifications such as [DAI].¶

The Authority Delegation Model accommodates attribute authorities whose authority is not a namespace owner (government-issued credentials, professional certifications, employment attestations, decentralized credentials). This document does not register Trust Methods for attribute attestation; implementers needing such evaluation should look to W3C Verifiable Credentials, OpenID for Verifiable Credentials, and domain-specific frameworks. Where their attestations are conveyed as OAuth identity assertions whose subject is namespace-bound, this document's issuer-trust evaluation applies regardless of the attribute-attestation layer beneath it.¶

The email Subject Identifier extraction registered in this document is user-identity-oriented. The Authority Delegation Model (Section 3) supports any Subject Identifier format with a registered extraction procedure; identity chaining for workload identities, agent identities, or other non-user subjects can be supported by registering additional extractions with no changes to the trust evaluation model (Appendix B).¶

1.7. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.1. Pattern Overview

Four roles cooperate around one delegation:¶

Authority Holder
   |  delegates authority via
Delegation Artifact
   |  identifies
Delegate
   |  signs
Assertion
   |  presented to
Validator

The Authority Holder publishes the Delegation Artifact through a profile-defined channel: a DNS record under its domain, an HTTPS document at a well-known URL on its host, a signed subordinate statement in a federation, or another profile-defined form. Control of that publication channel is itself the authority binding: whoever can publish at the channel is the Authority Holder for the namespace, claim type, or scope. The Validator validates the Delegation Artifact (which says "Authority Holder authorized Delegate") and the Assertion (which says "Delegate asserts something about Subject"). Both validations are required.¶

A delegation has a lifecycle: the Authority Holder establishes the artifact, publishes it, the Delegate uses it to mint Assertions, and revocation occurs by removing or expiring the artifact. The framework provides no remote cache-invalidation mechanism; revocation latency is bounded by the profile's cache lifetime. Subject Authorities that need fast revocation operate with short steady-state cache lifetimes. Planned transfers (provider migrations, acquisitions) and unplanned revocations (security incidents) follow the same publication path: update the artifact, accept latency bounded by the cache window.¶

3.2. Independent Trust Evaluation Categories

A Validator combines two independent trust evaluations to accept an Assertion. Each category answers a distinct question:¶

• Authenticity: is the entity that signed the Assertion cryptographically authentic and recognized as a member of some ecosystem? Satisfied by evidence that signers and their keys belong to a recognized population (federation membership, trust-mark issuance, signed attester key).¶

• Delegation authority: has the Authority Holder for the asserted scope delegated to this signer? Satisfied by a Delegation Artifact from the appropriate Authority Holder.¶

The OAuth Trust Method categories defined in this document (Section 4.3.2) instantiate these: issuer_authentication realizes Authenticity, and subject_namespace_authorization realizes Delegation authority for namespace-bound Subject Identifiers.¶

Local policy (risk scoring, scope grants, account linking, business rules) applies on top of these two categories and remains the final decision layer (Section 5.2 step 6).¶

3.3. Open-World Delegation and Bounded Transitivity

This document targets open-world delegation: the Authority Holder is an entity independent of the Validator (a customer's domain, a federation operator) and the Validator retrieves Delegation Artifacts through the profile's publication channel at evaluation time. Open-world does not mean open acceptance; the Validator publishes (or locally configures) which Authority Sources it accepts. Closed-world delegation (Validator and Authority Holder are the same party, evidence is local configuration) is the degenerate case and remains compatible with the model.¶

The Trust Methods defined in this document and in [DAI] are bounded at depth one: the Authority Holder directly lists every authorized Delegate; no further delegation is permitted. Depth-1 keeps revocation latency bounded by one cache and prevents compromise of any non-Authority-Holder party from expanding the authorized set. OpenID Federation [OIDF-FEDERATION] is the notable chained-delegation profile in the OAuth ecosystem; the cross-category combination rule still applies independently of transitivity (a federation chain establishes Authenticity, not Delegation authority).¶

3.4. Lookup States and Fail-Closed

A Validator's lookup of a Delegation Artifact produces exactly one of three abstract states. Profiles MUST map every concrete outcome of the lookup operation onto exactly one of these states.¶

4.1. Metadata Publication

A Resource Authorization Server publishes the location of its Identity Assertion Issuer Trust Policy in its authorization server metadata [RFC8414] using the following member:¶

identity_assertion_trust_policy_uri

OPTIONAL. HTTPS URI identifying the Identity Assertion Issuer Trust Policy document.¶

A Protected Resource that publishes OAuth 2.0 Protected Resource Metadata [RFC9728] MAY include the same member to advertise the policy applied by its Resource Authorization Server. Clients that obtain the URI from Protected Resource Metadata MUST verify that the policy document's resource_authorization_server value identifies an authorization server listed in the Protected Resource's authorization_servers array. If the same member appears in both metadata documents, the authorization server metadata value is authoritative.¶

A Resource Authorization Server may additionally publish the trust policy at the well-known URI registered in Section 10.1.3. The well-known URI is derived from the Resource Authorization Server's issuer identifier by the transformation of [RFC8414] Section 3: the well-known path component identity-assertion-trust-policy is inserted between the host (and port, if any) and any path component of the issuer identifier. For an issuer with no path component this yields https://{host}/.well-known/identity-assertion-trust-policy. If both the metadata member and the well-known URI are available and identify different documents, the metadata member is authoritative.¶

A consumer retrieving a Trust Policy document (from either source) fetches it with an HTTP GET over HTTPS with TLS server authentication, subject to the following rules. The consumer MUST NOT act on a policy it could not retrieve and validate; such a retrieval failure is distinct from a successfully retrieved policy that rejects an assertion.¶

• The response MUST have status 200 and a media type of application/json or a +json-suffixed type.¶

• Consumers MUST follow HTTPS redirects up to a limit of 5 hops; every redirect target MUST use the https scheme and MUST remain within the issuer's origin. A redirect to a different origin, or exceeding the hop limit, is a retrieval failure.¶

• Any other status, a TLS failure, an unparseable body, or a body exceeding a consumer-chosen limit (which MUST allow at least 64 KiB) is a retrieval failure.¶

Example authorization server metadata:¶

{
  "issuer": "https://api.resource.example",
  "token_endpoint": "https://api.resource.example/token",
  "grant_types_supported": [
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ],
  "identity_assertion_trust_policy_uri":
    "https://api.resource.example/.well-known/identity-assertion-trust-policy"
}

4.2. Trust Policy Document

The Identity Assertion Issuer Trust Policy is a JSON object served over HTTPS with media type application/json (or a media type using the structured +json suffix). Consumers MUST reject a policy whose required members are absent or wrong-typed, MUST reject a document containing duplicate member names at any object level, and MUST ignore unrecognized members except those named in crit (Section 4.6). The policy MAY include a crit member and a signed_policy member as defined in Section 4.5 and Section 4.6. Members are registered in Section 10.1.6.¶

Example:¶

{
  "resource_authorization_server": "https://api.resource.example",
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ],
  "subject_identifier_formats_supported": ["email"],
  "issuer_trust_methods": [
    {
      "method": "openid_federation",
      "trust_anchors": ["https://federation.example.org"]
    },
    {
      "method": "domain_authorized_issuer"
    }
  ]
}

4.3. Trust Methods

{
  "method": "openid_federation",
  "trust_anchors": ["https://federation.example.org"],
  "trust_marks": [
    {
      "id": "https://federation.example.org/marks/loa3",
      "issuer": "https://federation.example.org"
    }
  ]
}

{
  "resource_authorization_server": "https://api.saas.example",
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ],
  "subject_identifier_formats_supported": ["email"],
  "issuer_trust_methods": [
    {
      "method": "openid_federation",
      "trust_anchors": ["https://federation.example.org"]
    },
    {
      "method": "domain_authorized_issuer"
    }
  ]
}

4.4. Subject Authority Determination

Determining the Subject Authority has two steps: first identify which registered Subject Identifier format the assertion carries, then apply that format's extraction procedure. The grant-profile binding (Section 6) designates which claim conveys the Subject Identifier and thus which format applies; for the bindings in this document, a top-level email claim (with email_verified) is the email format. A format is "used by the assertion" when the designated claim for that format is present. If the designated claim maps to no registered format, the subject_namespace_authorization category cannot be evaluated and processing follows Section 5.2 step 5c.¶

The Subject Authority associated with a Subject Identifier is then determined as registered in Section 10.2. This document registers the email extraction as the initial entry. The extraction-procedure pattern (Subject Identifier format to Subject Authority) is open: future specifications register additional formats for service identities, decentralized identifiers, federated handles, and other namespaces by adding entries to the same registry without changes to the rest of the framework. See Appendix B.¶

Initial extractions:¶

email

The Subject Authority is derived from the assertion's top-level email claim, which MUST be accompanied by a top-level email_verified claim with the boolean value true. If the email_verified claim is absent or has any value other than true, consumers MUST treat the email Subject Identifier as invalid for Subject Authority determination and MUST reject the assertion when email is the Subject Identifier being evaluated. Consumers MUST NOT treat an unverified email claim as though the assertion carried no Subject Identifier.¶

The domain is the substring after the single @. Consumers MUST reject an email claim value that does not contain exactly one @ character or whose domain part is empty; this document uses the simple single-@ rule rather than the full [RFC5321] addr-spec grammar, and quoted local-parts or address forms that do not reduce to a single unquoted @ are out of scope for the email extraction. The local-part is not used. A trailing dot on the domain, if present, is removed. The domain is converted to A-label form per [RFC5891] (applying IDNA processing, including Unicode normalization) before any Public Suffix List matching, so that comparison operates on a single canonical form.¶

The A-label domain is then normalized to its registrable domain ("eTLD+1") by applying the Public Suffix List matching algorithm [PSL], including its wildcard * and exception ! rules: the Subject Authority is the shortest suffix of the domain that is one label longer than the longest matching public suffix. Consumers MUST use both the ICANN and PRIVATE divisions of the list (a delegated namespace listed in the PRIVATE division, such as team.example-pages.example, resolves to that namespace; using only the ICANN division would compute a coarser Subject Authority and query a different name). The result is compared using case-insensitive ASCII comparison of A-labels. Consumers MUST reject an email whose domain is itself a public suffix (no registrable domain exists) and MUST reject a domain that is not a valid A-label or U-label sequence. Registrable-domain normalization prevents an attacker who controls a subdomain (for example, via subdomain takeover) from overriding the legitimate record at the registrable domain.¶

A Subject Identifier whose format is not registered in Section 10.2 yields no Subject Authority; processing follows Section 5.2 step 5c.¶

Subject Authority extraction MUST be exact-match: wildcard, suffix, regular-expression, and substring matching against Subject Authority values are forbidden unless explicitly specified by the relevant Subject Identifier format's extraction procedure.¶

4.5. Signed Policy Metadata

The Trust Policy and Issuer Authorization Policy documents MAY include a signed_policy member that provides cryptographic integrity for signed policy claims. When the signed JWT contains all recognized decision-affecting policy members, signed_policy can provide object-level integrity for the policy document. This member follows the signed metadata pattern defined for authorization server metadata in [RFC8414] and protected resource metadata in [RFC9728].¶

The signed_policy value is a JWT [RFC7519] in JWS Compact Serialization [RFC7515] containing policy members as claims. The JWT MUST be digitally signed using an asymmetric algorithm, MUST contain an iss claim identifying the party attesting to the signed policy claims, and MUST contain iat. It MUST contain exp, so that a superseded signed policy cannot be replayed indefinitely (relevant in the shared-infrastructure scenario for which signing is recommended, Section 7.9); consumers MUST reject an expired signed_policy. The JOSE header SHOULD contain a kid identifying the signing key. The JWT payload SHOULD NOT contain a signed_policy claim.¶

Algorithms: [RFC8725] (JWT Best Current Practices) applies unchanged. In addition, the JWT MUST NOT use a MAC algorithm (HS256/384/512); verification keys are widely distributed and a MAC scheme would require sharing the signing key with every Validator, defeating the authority binding. Implementations MUST support ES256 and SHOULD support EdDSA and ES384; RS256 with >=2048-bit keys MAY be supported for compatibility.¶

Per [RFC8725] §3.11 (cross-context confusion), the JWT typ header MUST be trust-policy+jwt for Trust Policy documents or issuer-authorization-policy+jwt for Issuer Authorization Policy documents. These are the registered media subtypes with the application/ prefix omitted, per the [RFC8725] §3.11 convention; the corresponding media types are registered in Section 10.3.¶

The acceptable signer depends on which policy document is signed:¶

• For the Trust Policy document, the JWT iss claim MUST equal the resource_authorization_server claim. The verification key MUST be controlled by that Resource Authorization Server. Consumers MAY resolve the key from the Resource Authorization Server's authorization server metadata jwks_uri, federation entity configuration, or local configuration, except in the shared-infrastructure trust model of Section 7.9, where the jwks_uri typically traverses the same shared edge as the policy document and the key MUST instead be resolved through a channel independent of that edge (federation or local configuration).¶

• For an Issuer Authorization Policy document, the JWT payload MUST contain the member that identifies the Subject Authority in the profile's wire format (subject_authority in [DAI]). The JWT iss claim MUST either equal that Subject Authority identifier or identify a signing authority that local policy or an applicable Trust Method establishes as controlled by the Subject Authority. Consumers MUST NOT treat a signature by an Assertion Issuer the policy authorizes as proof of Subject Authority authorization unless such a relationship is explicitly established.¶

  The verification key for an Issuer Authorization Policy signer MUST be resolved through a channel independent of the one that carried the policy document. A profile that admits signed_policy on the Issuer Authorization Policy MUST specify at least one of the following key-resolution mechanisms and state its trust assumptions:¶

  • a key published under DNSSEC-signed records for the Subject Authority;¶

  • a key resolved through a federation or trust-anchor relationship established by an issuer_authentication Trust Method; or¶

  • a key configured out of band at the consumer.¶

  Rationale: an attacker who controls the publication channel can substitute both the policy and, if the key is fetched over that same channel, the key. Absent an independent channel, the signature provides integrity no stronger than channel control (which already establishes authority), and consumers MUST NOT rely on it to defend against compromise of that channel.¶

If both unsigned policy members and signed_policy are present, the signed policy claims MUST be used as the policy values for all claims present in the JWT. Unsigned members that are not represented as claims in the JWT MAY be used subject to the normal processing rules for unrecognized members. A conflict exists when a member name appears in both the unsigned outer document and the signed JWT payload AND the two values are not equal when compared as parsed JSON values (member order and insignificant whitespace ignored; equivalently, their JCS [RFC8785] serializations differ). Consumers MUST reject a policy that contains any such conflict; an attacker who can modify the outer document but not the signed JWT otherwise has a lever to inject visible-but-ignored members that may mislead operators or downstream tooling.¶

A publisher that needs to require signed_policy processing by all conforming consumers lists signed_policy in the document's crit member (Section 4.6); a consumer that does not implement signed_policy processing then rejects the document rather than silently ignoring the signature. Absent a crit entry, the presence of signed_policy provides integrity only for consumers that support and verify it, or for deployments where local policy requires signed policy processing.¶

If a consumer requires object-level integrity by local policy, the consumer MUST verify the signed JWT before acting on the policy, and the JWT payload MUST contain every recognized decision-affecting member used by that consumer. The consumer MUST NOT use unsigned recognized decision-affecting members that are absent from the JWT payload. If signature verification fails, if the verification key is unacceptable, if the JWT is malformed, if the required issuer binding above is not satisfied, or if the JWT omits a recognized decision-affecting member required for evaluation, the consumer MUST reject the policy as malformed.¶

4.6. Critical Members

The Trust Policy and Issuer Authorization Policy documents MAY include a crit member: a JSON array of strings naming other members of the same document whose correct processing is REQUIRED for safe interpretation. A consumer that does not recognize, or does not implement processing for, any member named in crit MUST reject the document as malformed rather than ignoring the unrecognized member. Members not named in crit retain the default handling: unrecognized members are ignored.¶

crit, when present, MUST be a non-empty array of strings; each string SHOULD name a member that is actually present in the document. A consumer MUST reject the document if crit is present but not a non-empty array of strings, and MUST reject if crit names crit itself. This is the same fail-closed pattern JWS ([RFC7515] Section 4.1.11) uses for critical header parameters.¶

Publishers MUST place crit in the outer (unsigned) document: a crit present only in a signed_policy JWT payload is invisible to consumers that do not process signatures and therefore has no effect on them. It MAY additionally be duplicated as a claim in the signed JWT so that its value is integrity-protected.¶

This mechanism is defined in the base specification, with no member named critical by default, so that a future extension can mark a new decision-affecting member critical and have already-deployed consumers honor it; an extension that omitted it from the base could not retrofit fail-closed behavior onto the deployed base. The DNS record form does not carry crit; see Appendix B.3.¶

5.1. Client Processing

A client that wants to obtain an identity assertion JWT for a Resource Authorization Server:¶

1. Discovers the Resource Authorization Server metadata [RFC8414].¶

2. Confirms that the desired grant profile is supported by checking the authorization_grant_profiles_supported parameter ([ID-JAG] §7.2) in the authorization server's metadata.¶

3. Fetches the identity_assertion_trust_policy_uri document.¶

4. Determines whether an available Assertion Issuer can satisfy the Trust Method combination rule in Section 5.2. For namespace-bound Subject Identifiers, this usually means satisfying both an issuer_authentication method (such as federation membership) and a subject_namespace_authorization method (such as authorization by the Subject Authority).¶

5. Determines whether the Assertion Issuer can produce a Subject Identifier in a format listed in subject_identifier_formats_supported, if that member is present, and required by the applicable grant profile.¶

6. Requests an identity assertion JWT from the selected Assertion Issuer.¶

The client MUST NOT treat the Trust Policy as a guarantee that a particular assertion will be accepted. The Resource Authorization Server always applies local policy at token request time.¶

5.2. Resource Authorization Server Processing

This section specifies the normative processing procedure. It is the OAuth-identity-assertion instantiation of the Authority Delegation Model (Section 3): each Trust Method category in the applicable Trust Policy is evaluated under the cross-category combination rule (Section 3.2.1); lookup outcomes are classified per Section 3.4; source selection is deterministic per Section 3.2.2.¶

When evaluating an identity assertion JWT presented in a token request, the Resource Authorization Server MUST:¶

1. Select and parse the Trust Policy that applies to the token request. If the policy document is malformed, reject the assertion. (Recognition of individual Trust Method objects is handled in step 5a.)¶

2. Validate the assertion per the applicable grant profile ([RFC7521], [RFC7523], [ID-JAG]). This validation is provisional with respect to signing-key resolution: a Trust Method evaluated in step 5 MAY constrain the source of the key used to verify the assertion signature (for example, openid_federation requires a federation-resolved JWKS, Section 4.3.4.1). The Resource Authorization Server MUST NOT accept the assertion until the signature has been verified with a key permitted by each key-source-constraining Trust Method that it relies on to satisfy the combination rule in step 5 (not every listed method: under the or-semantics of Section 3.2.1, a category may be satisfied by one of several alternative methods, and only the constraints of the method actually relied on apply). A signature validated only against an unconstrained source, such as the iss URL's authorization server metadata, does not satisfy this step when the relied-on Trust Method constrains the key source.¶

3. Verify that the applicable grant profile is listed in authorization_grant_profiles_supported.¶

4. If subject_identifier_formats_supported is present, verify that the Subject Identifier format used by the assertion is listed, unless the applicable grant profile defines a different format selection rule.¶

5. Verify that the Assertion Issuer identified by iss satisfies the Trust Method combination rule:¶

   a. Partition the Trust Method objects in issuer_trust_methods by category (see Section 4.3.2). A Trust Method registered with multiple categories belongs to each. If any object in issuer_trust_methods is not recognized, is malformed, or cannot be assigned to a category known to the Resource Authorization Server, the Resource Authorization Server MUST reject the assertion: it cannot determine whether it is evaluating the full set of requirements the operator declared, and silently ignoring the object would evaluate a strict subset (a fail-open category downgrade). A single evidence item MUST NOT be counted toward more than one category even when its Trust Method is registered in several.¶

   b. Each category present in the partitioned policy is applicable to every assertion evaluated under this policy; applicability is a property of the policy, not the assertion (Section 3.2.1.1). For each present category, the Assertion Issuer MUST satisfy at least one Trust Method from that category.¶

   c. When the policy contains a subject_namespace_authorization Trust Method, the assertion MUST carry a Subject Identifier from which a Subject Authority can be determined per Section 4.4 or an equivalent registry. If the assertion carries no such Subject Identifier, or no Subject Authority can be determined, the Resource Authorization Server MUST reject the assertion. The Resource Authorization Server MUST NOT treat the subject_namespace_authorization category as inapplicable because the assertion omits a Subject Identifier, and MUST NOT consume any subject or identity claim from the assertion for account linking, authorization, or subject resolution when the namespace category is present but cannot be evaluated.¶

   d. Local policy MAY require satisfaction of additional Trust Methods for specific clients, subjects, or scopes.¶

   e. When the policy lists only issuer_authentication methods and the assertion carries a namespace-bound Subject Identifier (one whose format has a registered Subject Authority extraction procedure, Section 10.2, so that the Resource Authorization Server can determine this without running a namespace method), the Resource Authorization Server MUST reject the assertion unless local policy independently establishes authority over the subject namespace: federation membership alone does not establish authority over a particular subject namespace.¶

6. Apply local policy (account-linking, consent, authorization, risk) and the applicable grant profile's client authentication and sender-constraining; this document does not specify either.¶

Failure to satisfy issuer trust, subject identifier, or assertion claim requirements in the Trust Policy MUST result in an OAuth invalid_grant error unless another error is defined by the applicable grant profile. Detailed trust-evaluation failure state MUST NOT be returned to public clients in the OAuth error response; it is a reconnaissance target.¶

6.1. ID-JAG

For ID-JAG [ID-JAG], authorization_grant_profiles_supported contains the value urn:ietf:params:oauth:grant-profile:id-jag. The Subject Identifier for ID-JAG is the top-level email claim, accompanied by email_verified=true, extracted per Section 4.4. When the Trust Policy contains a subject_namespace_authorization method, Section 5.2 step 5c requires the ID-JAG to carry that Subject Identifier and requires rejection if it is absent or unresolvable.¶

In addition to the processing in Section 5.2, the Resource Authorization Server MUST:¶

1. Validate the ID-JAG per [ID-JAG].¶

2. Verify that the email Subject Identifier, when the assertion carries one, uses a format listed in subject_identifier_formats_supported, if that trust policy member is present. (Whether the assertion is required to carry the Subject Identifier at all is governed by Section 5.2 step 5c.)¶

3. Use the email attribution only for subject resolution and Subject Authority evaluation. The Resource Authorization Server MUST NOT treat the mere presence or value of the email claim as proof that the ID-JAG issuer is authoritative for the subject; issuer acceptability is established only by evaluating the Trust Methods.¶

6.2. Generic JWT-Bearer Assertion Grant

This section provides the binding for the JWT-bearer authorization grant of [RFC7523] Section 2.1 when the assertion carries an identity claim to which Subject Authority Determination applies. Other identity-carrying grant profiles (e.g., ID-JAG, Section 6.1) supply their own bindings.¶

A Resource Authorization Server that accepts generic RFC 7523 JWT-bearer assertion grants advertises urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported. RFC 7523 defines no distinct grant-profile identifier, so this framework reuses that grant-type URN as the grant-profile identifier; a deployment accepting this grant MUST list it in authorization_grant_profiles_supported so Section 5.2 step 3 applies uniformly.¶

As with ID-JAG, the Subject Identifier for this binding is the top-level email claim, accompanied by email_verified=true, extracted per Section 4.4. The sub claim is not a Subject Identifier source under this binding, even when its value is in email form: sub is an issuer-scoped identifier ([RFC7519]) that may merely resemble an email, and no verification signal attests it (email_verified attests the email claim). Fixing a single source preserves the deterministic single-source-selection requirement of Section 3.2.2; an Assertion Issuer whose subject identifiers are email-form sub values participates by also emitting the email and email_verified claims. A future extension MAY register an additional extraction procedure (Section 10.2) for other claim sources.¶

In addition to the processing in Section 5.2, the Resource Authorization Server MUST:¶

1. Validate the JWT per [RFC7523].¶

2. Verify that the email Subject Identifier, when the assertion carries one, uses a format listed in subject_identifier_formats_supported, if that trust policy member is present.¶

3. Treat the identity claim only as input to Subject Authority evaluation. Issuer acceptability is established only by evaluating the Trust Methods.¶

Because the generic JWT-bearer grant carries no tenant claim, tenant-scoped authorization is not expressible for assertions delivered under this grant; the resulting constraint on Subject Authorities that rely on shared multi-tenant Assertion Issuers is specified in [DAI] §Single-Issuer Multi-Tenant Identity Providers.¶

This binding does not apply to JWT client authentication ([RFC7523] Section 2.2), where the Subject Identifier is the client_id registered with the authorization server and no external namespace-owner delegation exists.¶

7.1. Alignment with OAuth Security BCP

This document complements the OAuth 2.0 Security Best Current Practice ([RFC9700]); it does not duplicate or override it. The subject_namespace_authorization category is the wire-format analog of [RFC9700] §4.4 (AS mix-up mitigations): to the extent the Subject Authority's publication channel provides integrity, a Resource Authorization Server will not accept an assertion from an AS that the Subject Authority has not listed. This guarantee is only as strong as the integrity of that channel: a Trust Method whose evidence is published over unauthenticated DNS or a compromisable HTTPS origin can be defeated by an attacker who controls that channel (see the per-Trust-Method security analysis, e.g. [DAI], and Section 3.2.2). It is not an unconditional guarantee. Other [RFC9700] topics (redirect URI validation, bearer-token replay, client authentication) apply at the grant-profile and client-authentication layers and are not addressed here. Implementations SHOULD follow [RFC9700] at those layers.¶

7.2. Unverified Claim Exploitation

Source selection (Section 3.2.2) chooses which Authority Source's delegation applies to the incoming Assertion. At the point of selection, the Assertion's signature has not yet been validated against any Delegation Artifact; the Assertion is an untrusted payload. A profile whose source-selection algorithm considers multiple claims, applies preference ordering, or falls back from one input to another gives an attacker a selection lever.¶

The attack: the attacker constructs an Assertion whose claims satisfy multiple potential bindings. The Validator's selection algorithm picks the weakest (or most attacker-favorable) Authority Source's policy. The Assertion is evaluated against a Delegation Artifact that the legitimate Authority Holder for the target namespace never authorized.¶

Worked example: an Assertion carries sub: alice@victim.example AND tenant_context: attacker-tenant.example. A loosely written profile selects the Authority Source by tenant context when present, falling back to subject domain. The Validator selects attacker-tenant.example, fetches that Authority Holder's Delegation Artifact (which the attacker controls), validates the Assertion against it, and accepts a claim about a victim.example subject.¶

The mitigation is deterministic source selection (Section 3.2.2): a binding function from Assertion + request context to exactly one Authority Source. Profiles MUST define that function explicitly and the function MUST:¶

• Use explicitly defined inputs (a single named claim, header, request parameter, or fixed tuple).¶

• Produce exactly one Authority Source for any valid input, or fail deterministically (no preference ordering, no fallback across candidates).¶

• Be invariant under attacker-controlled inputs outside the binding function: the presence, absence, or value of any other claim MUST NOT alter the selected Authority Source.¶

The email extraction registered by this document derives the Subject Authority deterministically from a single claim and does not fall back; profiles registering additional extractions MUST preserve this property.¶

7.3. Applicability Bypass

The cross-category combination rule (Section 3.2.1) requires the Validator to evaluate every applicable category. A profile that lets category applicability depend on the incoming Assertion gives the attacker a way to waive the category by constructing a matching Assertion.¶

The attack: the profile (or local configuration) declares "the delegation-authority category is not applicable when the Assertion is from a legacy issuer" (or carries a legacy-flag claim, or fails some heuristic that signals "legacy"). The attacker constructs an Assertion matching the legacy condition. The Validator silently skips the entire delegation-authority evaluation; the open-world defense layer is bypassed and the Validator falls back to authenticity alone, which the cross-category combination rule was explicitly designed to forbid as sufficient.¶

The mitigation: category applicability MUST be a property of the Validator's published Trust Policy, not of the incoming Assertion. Migration scenarios where some traffic legitimately predates a category's availability are handled at the policy layer, not by silently waiving the category. Per-deployment-phase policy is a configuration boundary; Assertion-driven waiver is an attacker-controlled boundary.¶

7.4. Authority Source Compromise

The authority binding (publication channel) is the highest-value target. A compromise of the publication channel (DNS hijack, TLS misissuance plus DNS redirect, registrar account takeover, compromise of the federation operator's signing key) substitutes the Authority Holder's voice with the attacker's. Delegation Artifacts published through the compromised channel are indistinguishable from legitimate ones.¶

This framework does not provide cryptographic recovery from publication-channel compromise. Recovery is operational. Profiles SHOULD recommend operational defenses appropriate to their publication channel (DNSSEC, registry-lock, CAA records, Certificate Transparency monitoring, federation key rotation). See [DAI] §Security Considerations for the DNS+HTTPS publication-channel compromise model.¶

7.5. Transitive Authorization is Bounded

The two trust categories make different transitivity choices, both permitted within the taxonomy of Section 3.3:¶

• issuer_authentication permits chained transitivity. The openid_federation Trust Method accepts a chain from a leaf entity to a trust anchor; the trust anchor's signature on intermediate Subordinate Statements transitively authenticates the leaf.¶

• subject_namespace_authorization requires depth-1 (no chaining). A Subject Authority lists specific Assertion Issuers directly; it cannot delegate further to whoever Issuer X federates. Revocation latency is bounded by the Subject Authority's own cache lifetime and does not compound across delegations.¶

The two categories are independent: federation membership does not establish namespace authority, and namespace authorization does not establish authenticity. The cross-category combination rule (Section 5.2) enforces this independence at evaluation time. See Appendix A.1 for positioning against OpenID Federation.¶

7.6. Scope of Namespace Authorization

Trust-policy evaluation establishes that the Assertion Issuer is authorized to assert this class of Subject Identifiers under the namespace. Resource Authorization Servers MUST still validate the assertion (signature, audience, expiration, replay protection, client binding) per the applicable grant profile, and MUST NOT infer any of the following from a successful trust-policy evaluation:¶

• The named subject exists at the Assertion Issuer or controls the email local-part ([DAI] §Email Local-Part Is Not Authenticated).¶

• The subject's current employment, enrollment, or organizational status.¶

• The strength, freshness, or method of the Assertion Issuer's authentication.¶

• Account-linking semantics (case sensitivity, plus-address or alias handling) compatible with this Resource Authorization Server's.¶

• Suitability for any specific risk class, scope sensitivity, or compliance regime.¶

These properties are out of scope and obtained, if needed, through mechanisms outside this framework (authentication-method/AAL claims, fresh-authentication signals, account-status attestations, out-of-band verification). In particular, email_verified=true is a prerequisite for deriving namespace authority from the email's domain; it is not evidence of current mailbox control.¶

The authorization is also not audience-scoped: the subject_namespace_authorization category constrains which Assertion Issuers may assert about a namespace, not which Resource Authorization Servers an authorized issuer may target, so a compromised-but-authorized issuer can mint assertions about the namespace's subjects for any consumer. Audience binding is enforced by the assertion's aud claim and the applicable grant profile, not by the Subject Authority; a future extension may let Authority Holders constrain acceptable audiences (see [DAI] §Future Extensions).¶

7.7. Per-Assertion Revocation Is Out of Scope

This framework decides whether an Assertion Issuer is authorized; it does not revoke individual assertions. JWT bearer tokens are stateless and remain valid until exp regardless of session termination, credential revocation at the Assertion Issuer, or Subject Authority withdrawal of the issuer's authorization via DAI (which prevents NEW assertions but does not invalidate already-issued ones). Deployments requiring synchronous revocation MUST use OAuth 2.0 Token Revocation [RFC7009], Token Introspection [RFC7662], or short assertion lifetimes at the grant-profile layer.¶

7.8. Policy Document Integrity

The trust policy MUST be served over HTTPS with TLS server authentication. Deployments needing integrity beyond TLS use the signed_policy member (Section 4.5), with the signer binding rules defined there. Mirrored or cached copies MUST NOT be relied on beyond their HTTP cache lifetime (Section 7.11).¶

7.9. Shared Infrastructure and Hosted Well-Known Paths

Many deployments host /.well-known/ resources behind third-party Content Delivery Networks (CDNs), shared edge platforms, or multi-tenant cloud hosting systems. TLS server authentication proves that the client reached an endpoint serving the requested host name; it does not prove that every routing rule, origin-pull rule, cache rule, or tenant boundary inside the shared platform is controlled by the namespace owner.¶

This matters for both the Resource Authorization Server trust policy and the Subject Authority's Issuer Authorization Policy. If an attacker can exploit shared infrastructure to serve a forged /.well-known/oauth-issuer-policy response for a victim domain, the attacker can attempt to authorize an Assertion Issuer for that victim's namespace even though the HTTPS connection itself succeeds. Similar risks arise from misconfigured path routing, dangling origins, tenant takeover, cache poisoning, or origin authentication failures.¶

Administrators SHOULD avoid delegating security-critical well-known paths to multi-tenant infrastructure unless they can ensure exclusive control over routing for those paths, authenticated origin access, cache invalidation, and tenant isolation. Deployments that host policy documents on shared infrastructure and treat the shared edge as outside their trust boundary MUST use object-level cryptographic integrity for the policy document itself, such as the signed_policy member (Section 4.5), rather than relying on the TLS channel to the shared edge. The signing key MUST be controlled by the Subject Authority or Resource Authorization Server independently of CDN tenant configuration, and MUST be resolvable through a channel independent of the shared edge (see the key-resolution requirement in Section 4.5).¶

Because the crit member (Section 4.6) is itself carried in the unsigned document, an attacker who can strip signed_policy can strip crit with it; publisher-side criticality therefore does not defend against stripping by an on-path or edge attacker. A signed_policy member is only effective against such an attacker if consumers are configured to require it: the attacker can otherwise serve an unsigned document, which a consumer not configured to require signatures would accept (a signature-stripping downgrade). A consumer operating in a shared-infrastructure trust model therefore MUST require and verify signed_policy before acting on the policy, MUST reject a policy that omits it, and MUST treat a valid TLS connection to a shared edge as insufficient by itself.¶

7.10. Downgrade Attacks

A Resource Authorization Server that supports multiple Trust Methods SHOULD define local precedence rules. Because or-semantics apply within a single Trust Method category and the client cannot observe per-subject local requirements, Resource Authorization Servers MUST enforce differentiated requirements at token request time rather than relying on the policy document alone; a client's choice of a weaker listed Trust Method is not a protocol violation the client can be held to but a condition the Resource Authorization Server rejects. The cross-category combination rule in Section 5.2 prevents downgrade across categories (for example, satisfying only an issuer_authentication method when a subject_namespace_authorization method is also applicable).¶

7.11. Trust Policy Caching

Consumers cache the Trust Policy using ordinary HTTP caching (see [RFC9111] for the mechanism), bounded by a local maximum cache lifetime. Independent of any policy-document cache expiration, revocation status of validated trust evidence MUST be checked at the cadence required by the applicable Trust Method specification. Transport integrity is addressed in Section 7.8.¶

7.12. Observability

Trust-policy evaluation is a security-critical decision; deployments are encouraged to log, for each processed assertion, at minimum the Assertion Issuer identifier, the Trust Policy URI with its retrieval time and cache validator (for example, its ETag), the Trust Methods that succeeded, the matched trust anchor or Issuer Authorization Policy origin, the Subject Identifier format, and the accept/reject outcome, and to support correlation across the issuance and verification halves of an identity-chain transaction.¶

10.1. Trust Policy Registrations

10.2. Subject Authority Extraction Procedures Registry

IANA is requested to establish a new registry titled "Subject Authority Extraction Procedures" under the "OAuth Parameters" registry group.¶

Registration policy: Specification Required [RFC8126].¶

Each registry entry contains:¶

Subject Identifier Format:

The Subject Identifier format identifier (typically registered in the "Security Event Subject Identifier Formats" registry per [RFC9493]).¶

Subject Authority Form:

A short description of the form taken by the Subject Authority for this format (for example, "DNS domain", "URL host").¶

Extraction Procedure:

A reference to the specification text that defines how the Subject Authority is computed from a Subject Identifier of this format.¶

Designated Expert instructions: the expert verifies that the format has a well-defined namespace authority, that the extraction procedure is deterministic (two consumers compute the same Subject Authority from the same Subject Identifier), and that it specifies exact-match comparison semantics per Section 4.4.¶

Future specifications that define new Subject Identifier formats are expected to register additional entries here when those identifiers have a well-defined namespace authority.¶

Initial entries:¶

10.3. Media Type Registrations

IANA is requested to register the following media types in the "Media Types" registry for the signed document forms (Section 4.5). Following [RFC8725] §3.11, the JWT typ header value is the media subtype with the application/ prefix omitted (trust-policy+jwt and issuer-authorization-policy+jwt, respectively), as required in Section 4.5.¶

For application/trust-policy+jwt: Type name application; Subtype name trust-policy+jwt; Required parameters none; Optional parameters none; Encoding considerations 8bit (the value is a JWT in JWS Compact Serialization, a sequence of base64url-encoded values separated by periods, per [RFC7519] Section 10.3.1); Security considerations Section 4.5 and the Security Considerations of this document; Interoperability considerations none; Published specification this document; Applications OAuth Resource Authorization Servers; Fragment identifier considerations none; Change controller IETF.¶

For application/issuer-authorization-policy+jwt: as above, with Subtype name issuer-authorization-policy+jwt and Applications OAuth Subject Authorities and Resource Authorization Servers.¶

11.1. Normative References

[ID-JAG]

"Identity Assertion JWT Authorization Grant", <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/>.

[OIDF-FEDERATION]

"OpenID Federation 1.0", n.d., <https://openid.net/specs/openid-federation-1_0.html>.

[PSL]

"Public Suffix List", n.d., <https://publicsuffix.org/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5891]

Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/rfc/rfc5891>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7521]

Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <https://www.rfc-editor.org/rfc/rfc7521>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9493]

Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, <https://www.rfc-editor.org/rfc/rfc9493>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

11.2. Informative References

[DAI]

"OAuth Domain-Authorized Issuer Trust Method", <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-domain-authorized-issuer/>.

[I-D.ietf-oauth-identity-chaining]

"OAuth Identity and Authorization Chaining Across Domains", <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/>.

[OIDC-DISCOVERY]

"OpenID Connect Discovery 1.0", n.d., <https://openid.net/specs/openid-connect-discovery-1_0.html>.

[RFC5321]

Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/rfc/rfc5321>.

[RFC6530]

Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <https://www.rfc-editor.org/rfc/rfc6530>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC7033]

Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <https://www.rfc-editor.org/rfc/rfc7033>.

[RFC7489]

Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/rfc/rfc7489>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

A.1. Relationship to OpenID Federation

OpenID Federation [OIDF-FEDERATION] and this framework address distinct questions: federation answers "is this issuer an authentic ecosystem member?" via trust chains; this framework adds "is this issuer authorized for this namespace?" via Subject Authority publication. Federation membership feeds the issuer_authentication category through the openid_federation Trust Method (Section 4.3.4.1); namespace authority comes from the orthogonal subject_namespace_authorization category. This document does not duplicate or replace federation mechanisms; it composes with them.¶

A.2. Why Bounded-Depth-1 Namespace Authorization

The subject_namespace_authorization category is bounded at depth one: the Subject Authority lists each authorized Assertion Issuer directly, with no provision for "and whoever issuer X federates further." This is deliberate:¶

• A Validator never has to compute a multi-hop authorization chain to evaluate a namespace claim; a single customer-published policy names the Assertion Issuer.¶

• Revocation latency is bounded by the Subject Authority's own cache lifetime, not by the depth of a delegation chain.¶

• Compromise at any intermediate party (a federation operator, a delegated issuer) cannot expand the namespace authorization of any issuer the Subject Authority did not list directly.¶

Federation chains for issuer authentication remain in scope under the issuer_authentication category; only the namespace-authorization graph is bounded.¶

B.1. Additional Subject Identifier Formats

This document registers one Subject Authority extraction procedure (email, Section 4.4). The policy model accommodates additional Subject Identifier formats. A future specification adding a new format would register a Subject Authority Extraction Procedure in Section 10.2 defining how a Subject Authority is computed from values of the new format, and either reuse domain_authorized_issuer (when the computed Subject Authority is a DNS-publishable domain) or register a new subject_namespace_authorization Trust Method. The Trust Policy document format, Issuer Authorization Policy document format, Trust Method category structure, combination rule, and bounded-transitivity property remain unchanged across such extensions.¶

Candidate formats considered as future work include URL-host Subject Identifiers (url_host), Decentralized Identifiers (did), and a subdomain-exact email variant that requires an explicit delegation from the registrable-domain authority to prevent subdomain takeover.¶

B.2. Presented Delegation Credentials

The subject_namespace_authorization methods defined so far are declarative and fetched: the Validator retrieves the Authority Holder's published policy at verification time. The complementary shape is a presented credential: the Authority Holder signs a delegation ("issuer X may assert for namespace A until time T", optionally audience-scoped), gives it to the Assertion Issuer, and the issuer presents it with the assertion, in the manner of an x5c chain or an OpenID Federation Subordinate Statement. Verification becomes offline once the Authority Holder's key is known, removing the per-verification lookup from the token path and enabling constraints a flat record cannot express, such as audiences and scopes (and delegation chains, should a future revision relax the depth-1 bound of Section 7.5). The costs are the mirror image: the Authority Holder needs key management and signing automation, key discovery recurses to a DNS- or HTTPS-anchored channel, and revocation requires status checking or short-lived credentials. Nothing in this framework precludes such a method: it would register as a subject_namespace_authorization Trust Method whose evidence is carried in-band, satisfy the checklist in Section 4.3.3, and compose with existing methods under the combination rule. It is deferred as an assurance-tier extension for deployments whose requirements justify the operational cost.¶

B.3. Critical Directives for the DNS Record Form

The JSON document forms carry a crit member defined in the base specification (Section 4.6), so an extension that adds a decision-affecting member to the Trust Policy or Issuer Authorization Policy can mark it critical and have already-deployed consumers honor it. The DNS record form has no analogous per-directive criticality mechanism today; its version token ([DAI]) prevents misinterpretation of incompatible future syntax by making unrecognized versions ignored (which steers the lookup to the HTTPS channel or a Negative outcome, not to a hard rejection). A future extension that needs true per-directive fail-closed semantics in the DNS form would define a crit= directive and its recognition rules at that time.¶

B.4. Actor Identity Trust Evaluation

OAuth assertions can carry an act object expressing actor delegation (a service acting on behalf of a user). A future extension can apply the trust-evaluation categories of Section 3 to actor identities: a Resource Authorization Server would evaluate, in addition to the assertion's iss and sub, whether the asserting issuer is entitled to attest the (act.iss, act.sub) pair. This requires registering a Subject Authority extraction procedure applicable to actor-carried Subject Identifiers and is therefore tied to the OAuth Actor Profile being progressed separately. Until that extension lands, trust evaluation of actor identities is governed by local policy at the Resource Authorization Server.¶

B.5. Trust Policy Discovery

This document specifies how a Resource Authorization Server publishes its Trust Policy (via authorization server metadata or protected resource metadata) but assumes a client or peer that already knows the Resource Authorization Server's identity. In open-world deployments (agent runtimes, AI tools, cross-organization integrations), a peer may need to discover a Resource Owner's Trust Policy before any prior bilateral relationship exists.¶

A future Trust Policy Discovery extension can let a Resource Owner publish a DNS-named pointer at _oauth-trust-policy.{resource-domain} to its Trust Policy document, mirroring the DNS-authority pattern of [DAI] for the resource-side. The Resource Owner's domain becomes the publication channel for "where do I trust assertions from?", the dual of DAI's "who do I authorize to assert about me?".¶

The extension is deferred because the open-world first-contact case is not yet a deployed need for the namespace and federation profiles defined here; bilateral configuration plus the metadata endpoints suffice for the current target deployments.¶