OAuth Domain-Authorized Issuer Trust Method

1.1. Relationships

DAI is a concrete profile of [TRUST-FRAMEWORK] for OAuth identity assertions: the Subject Authority is the Authority Holder; the Issuer Authorization Policy is the Delegation Artifact; the DNS record (or DNS pointer plus HTTPS document) is one publication channel; the Assertion Issuer is the Delegate. Lookup state classification and fail-closed requirements follow [TRUST-FRAMEWORK] §Lookup States and Fail-Closed.¶

DAI extends [TRUST-FRAMEWORK], which owns the Trust Policy document format, Trust Method machinery, Subject Authority Determination, and OAuth grant-profile bindings. This document defines the Issuer Authorization Policy document (Section 3), the DNS and HTTPS publication channels (Section 4.1), the lookup procedure (Section 5), the verification rules (Section 6), the domain_authorized_issuer Trust Method, and an HTTPS-only deployment variant (Section 8.2). A bridge to the Email Verification Protocol's DNS records and a client-side discovery use case are sketched as future extensions in Appendix B.¶

1.2. 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.¶

4.1. Publication Channels

This document defines three publication channels. A Subject Authority chooses based on operational constraints; all produce semantically equivalent policy validated by the same lookup procedure (Section 5). The canonical lookup procedure consults DNS first and uses the HTTPS well-known channel only when DNS authoritatively indicates absence.¶

4.2. Default HTTPS Well-Known URL

A Subject Authority MAY publish a JSON document at the default HTTPS well-known URL on its own host (Section 4.4), either as the sole publication (Channel 3) or alongside a DNS record. A Subject Authority with no DAI DNS record relies on the natural negative-authoritative DNS response to bring consumers to the well-known URL (Section 5).¶

Operators are encouraged to publish the DNS record where practical because it matches the operational model of the prior-art mechanisms in Appendix A.1 and because consumer lookup behavior is DNS-first.¶

4.3. DNS Record

The Subject Authority publishes one or more DNS TXT records at _oauth-issuer-policy.{A}, where {A} is the Subject Authority rendered as a DNS name. Internationalized names are converted to A-labels per [RFC5891] before the prefix is prepended. DNS lookup names are formed without a trailing dot for comparison purposes; the wire-format root label is not part of the Subject Authority value.¶

The string segments of a TXT record ([RFC1035]) are concatenated without separator and interpreted as ASCII text (a record containing a non-ASCII octet is malformed, since all defined directive values are ASCII by construction).¶

A record is recognized if the version token v=oauth-issuer-policy1 (case-sensitive) appears at the start, terminated by end of record, by optional whitespace, or by a ; separator; leading whitespace before the token is permitted. The version token matches only that exact string: a different token (for example, a future v=oauth-issuer-policy2) is not recognized, so the record is treated as unrecognized (not malformed) and is ignored by the recognition rule. Records that do not begin with a supported version token MUST be ignored. A v= directive appearing anywhere other than the start of a recognized record makes the record malformed (Section 5.1).¶

The remainder of a recognized record is a sequence of name=value directives separated by ;. Parsing rules:¶

• Whitespace (space and horizontal tab) immediately before and after each directive is ignored. A value MUST NOT contain whitespace or non-ASCII characters; the directive values defined here (domain names in A-label form and absolute HTTPS URLs) are ASCII by construction.¶

• Directive names are case-insensitive ASCII. Values are case-sensitive and preserved as written.¶

• A directive splits into name and value at the first =. Subsequent = characters are part of the value.¶

• The value runs to the next ; or end of record. The character ; MUST NOT appear in a value (see the issuer-identifier constraint in Section 3).¶

• CR, LF, and NUL MUST NOT appear in a value.¶

• An empty directive (two consecutive ; separators with no intervening name=value) makes the record malformed (Section 5.1).¶

• Unrecognized directives MUST be ignored.¶

The parsing rules above are summarized in the following ABNF ([RFC5234] with the case-sensitive string extension of [RFC7405]) for implementer convenience; the prose above is normative if any disagreement exists.¶

record        = OWS version OWS *( ";" directive ) [ ";" OWS ]
version       = %s"v=oauth-issuer-policy1"
directive     = OWS name "=" value OWS
name          = 1*( ALPHA / DIGIT / "_" / "-" )
value         = *vchar-no-semi
vchar-no-semi = %x21-3A / %x3C-7E   ; VCHAR (%x21-7E) minus ";"
OWS           = *( SP / HTAB )

The following directives are defined:¶

authority=A

REQUIRED. The Subject Authority identifier this record claims to bind. The publisher MUST write this value in A-label (ASCII) form per [RFC5891]; consumers compare it against the Subject Authority computed from the query name (also in A-label form) using the case-insensitive ASCII comparison rules in [TRUST-FRAMEWORK] §Subject Authority Determination. Records whose authority= value does not match are discarded (see the lookup procedure in Section 5). A recognized record containing more than one authority= directive is malformed (Section 5.1).¶

uri=URL

OPTIONAL. An HTTPS URL identifying an Issuer Authorization Policy document. The URL MAY be on a different host than A. MUST use the https:// scheme and MUST NOT contain a fragment component.¶

issuer=ISSUER_URL

OPTIONAL. An Assertion Issuer identifier authorized by the Subject Authority for A. For OAuth authorization server issuer identifiers, the value MUST be an absolute HTTPS URL and MUST NOT contain a fragment component. MAY appear multiple times within a record and across records.¶

mode=MODE

OPTIONAL. Either enforce or monitor; default enforce when absent (Section 6.1). At most one mode= directive per record; a second is malformed. If any remaining record after authority= filtering carries mode=, all remaining records MUST carry mode= with the same value; a mix of differing or partially present mode= directives across records is malformed. A mode= value other than the two defined values is malformed.¶

A recognized record MUST contain at least one uri= directive or at least one issuer= directive. Recognized records containing neither MUST be treated as malformed (see Section 5.1).¶

A Subject Authority MUST publish records for at most one version of this mechanism at a time. This document defines only oauth-issuer-policy1. Future versions that are not understood by a consumer are ignored by the recognition rule above.¶

4.4. HTTPS Document URL

The default Issuer Authorization Policy URL is:¶

https://{A}/.well-known/oauth-issuer-policy

where {A} is the Subject Authority value rendered as a host (A-label form for internationalized names). The URL uses the https scheme, the host {A}, the default HTTPS port (443), and the well-known path [RFC8615]; it has no userinfo, port, query, or fragment component. A Subject Authority whose form has no host representation (none is defined in this document beyond the email-derived DNS domain) cannot use the default well-known channel. Consumers fetch this URL with an HTTP GET over HTTPS with TLS server authentication and interpret the response body as the JSON document defined in Section 3.¶

A URL obtained from a DNS uri= directive is fetched the same way; the host serving the URL is responsible for TLS server authentication of itself, not of A.¶

For every policy fetch defined here (the default well-known URL, a uri= target, and the HTTPS-only mode of Section 8.2), and for any redirect followed from one, the consumer MUST NOT connect to a host that resolves to a non-globally-routable address; see Section 9.11.¶

HTTP redirect handling is fixed so that two consumers reach the same outcome and so that a redirect cannot silently move the authority anchor to a host the Subject Authority does not control:¶

• Consumers MUST follow HTTPS redirects up to a limit of 5 hops; a request that would exceed 5 hops, or that loops, is classified as Indeterminate (Section 5.1).¶

• Every redirect target MUST use the https scheme and MUST NOT contain a fragment component.¶

• Every redirect target MUST remain within the same registrable domain as the initial fetch host (the Subject Authority {A} for the default well-known channel; the uri= pointer's host for the pointer channel), where the registrable domain is computed with the Public Suffix List algorithm of [TRUST-FRAMEWORK] §Subject Authority Determination (ICANN and PRIVATE divisions) applied to the A-label host. A redirect to a different registrable domain MUST NOT be followed and is classified as Indeterminate; cross-registrable-domain policy hosting is expressed only through the uri= pointer, where the delegation is published in DNS and visible to the Subject Authority.¶

• The final response MUST have HTTP status 200 and a media type of application/json or any media type using the structured +json suffix (media type parameters ignored); any other final status is classified per Section 5.1.¶

4.5. HTTPS Policy Document Contract

The document retrieved from either the default well-known URL or a DNS uri= pointer is the Issuer Authorization Policy defined in Section 3; consumers MUST NOT interpret any other JSON shape as an Issuer Authorization Policy. Consumers MUST validate the complete policy as a unit; a malformed entry makes the whole policy malformed, not just the offending entry.¶

Bounds (a response exceeding any bound is classified per Section 5.1): consumers MUST accept a policy document of at least 64 KiB and MAY reject one larger; publishers MUST keep the document within 64 KiB. Consumers MUST accept at least 100 authorized_issuers entries and MAY reject more. Consumers SHOULD apply an overall fetch timeout and SHOULD limit JSON nesting depth (the defined document has a fixed shallow structure). Consumers SHOULD send a conditional request (for example, If-None-Match) when they hold a cached policy, treating a 304 response per Section 5.1.¶

The document's shape and members are defined, with an example, in Section 3.¶

5.1. Failure Handling

DAI lookup outcomes map onto the Affirmative / Negative / Indeterminate lookup states of the Authority Delegation Model ([TRUST-FRAMEWORK] §Lookup States and Fail-Closed). The normative requirements (fail closed on Negative and Indeterminate; no fallback to a different Authority Source; bounded cache reuse on transient Indeterminate) apply unchanged; this section maps the concrete DAI outcomes onto those states.¶

The Indeterminate state covers:¶

• DNS-side: SERVFAIL, REFUSED, timeout, truncation with no successful retry.¶

• HTTPS transport: TLS error, connection failure, redirect loop, non-HTTPS redirect target.¶

• HTTPS response: 5xx; 4xx other than 404 and 410 (for example 401, 403, 405, 429, 451); 2xx other than 200; a 3xx that is not a followed redirect (Section 4.4) and not a 304 validating a held cached policy; unsupported media type; a body larger than the size limit, or containing more authorized_issuers entries than the consumer's entry limit (Section 4.5).¶

• DNS record validation: authority= missing from any recognized record; all recognized records discarded for authority= mismatch; more than one authority= or mode= in a record; differing or partially present mode= values across remaining records; a mode= value other than enforce or monitor; a recognized record with neither uri= nor issuer=; multiple distinct uri= values; an empty or otherwise malformed directive.¶

• HTTPS document validation: body that is not a syntactically valid Issuer Authorization Policy; a mode value other than enforce or monitor; subject_authority that does not match A.¶

Any outcome not explicitly mapped to Affirmative or Negative above MUST be treated as Indeterminate.¶

The following deterministic conflict rules apply:¶

• Multiple recognized TXT records containing no uri= directive are merged into a single virtual policy. issuer= values across records are deduplicated into a set; order carries no semantics (Section 5, step 2c).¶

• If any recognized record contains a uri= directive after authority= filtering, the HTTPS document at the single uri= target is authoritative and all issuer= directives across all records are ignored (Section 5, step 2b). More than one distinct uri= value is malformed.¶

• If both DNS and the HTTPS well-known URL are populated with differing content, DNS is authoritative when it returns an Affirmative response. Consumers do not consult or reconcile the HTTPS well-known URL in that case.¶

• Multiple authorized_issuers entries for the same issuer value but different tenant values are independent authorizations. Entries with tenant do not shadow entries without tenant for the same issuer.¶

• Only the Subject Authority computed by the extraction procedure for the assertion's Subject Identifier applies. Another Subject Authority's policy cannot grant authority over that subject.¶

• If the assertion's claims conflict with the matched policy entry, the assertion fails the Trust Method.¶

Consumers MUST treat both Negative and Indeterminate as assertion rejection. A fresh cached Affirmative policy MAY be used during transient Indeterminate on the live channel, subject to Section 7; the cache lifetime MUST NOT be extended by repeated Indeterminate retrievals.¶

6.1. Monitor Mode

A Subject Authority deploying its first policy cannot easily know whether its issuer list is complete; an omission breaks sign-in for its users. Monitor mode, following the deployment pattern of the DMARC [RFC7489] p=none policy, lets the Subject Authority publish, observe, and then enforce.¶

When the retrieved policy's mode is monitor (Section 3):¶

• The consumer MUST evaluate steps 3 and 4 normally, and SHOULD log every evaluation under the monitored policy (Subject Authority, assertion issuer, matched or mismatched, timestamp) so the Subject Authority can be informed out of band.¶

• If no entry matches (including the empty-array explicit-denial case), the Trust Method is nevertheless satisfied: the consumer MUST NOT reject the assertion on the basis of the mismatch.¶

• If an entry matches, the outcome is identical to enforce mode.¶

Monitor mode affects only the evaluation of a successfully retrieved policy. It does not alter lookup-state classification: Indeterminate outcomes still fail closed (the consumer cannot know the mode of a policy it could not retrieve), and Negative outcomes are unchanged.¶

Monitor mode provides no protection: while it is in effect, any authenticated issuer is accepted for the namespace exactly as if no policy were enforced, with logging as the only difference. It is a transitional state; Subject Authorities SHOULD move to enforce mode promptly once the observed mismatches are resolved (see Section 11 for the rollout sequence and Section 9.6 for the downgrade risk).¶

An aggregate reporting mechanism by which consumers deliver monitored-mismatch reports to the Subject Authority (analogous to DMARC's rua) is deferred; see Appendix B.¶

8.1. domain_authorized_issuer

The domain_authorized_issuer method indicates that the Assertion Issuer is acceptable if the Subject Authority identified by the assertion's Subject Identifier authorizes the Assertion Issuer to assert identities in that namespace, using the publication channels (Section 4.1), lookup procedure (Section 5), and verification rules (Section 6) of this document.¶

This Trust Method natively expresses authorization for either form of multi-tenant Assertion Issuer:¶

• Per-tenant issuer identifiers (for example, https://login.microsoftonline.com/{tenant-id}/v2.0): the authorized_issuers[].issuer field accepts any absolute HTTPS URL issuer identifier, and case-sensitive comparison against the JWT iss claim distinguishes tenants under the same host. Each authorized tenant is one authorized_issuers entry.¶

• Shared issuer with a tenant claim (for example, https://accounts.google.com serving every Google Workspace tenant via the top-level tenant claim of [ID-JAG] §6.1): the authorized_issuers[].tenant field binds the authorization to a specific tenant of the shared issuer, with the security properties described in Section 9.10.¶

{
  "method": "domain_authorized_issuer"
}

With no additional members, the Resource Authorization Server retrieves the Issuer Authorization Policy by applying the canonical lookup procedure in Section 5: a DNS query at _oauth-issuer-policy.{A} with HTTPS well-known URL fallback when the DNS response is negative-authoritative. The optional lookup member is used only for the HTTPS-only deployment variant in Section 8.2.¶

8.2. HTTPS-Only Deployment Variant

Some deployments cannot or will not depend on DNS-published authority. Those deployments can use the same Issuer Authorization Policy document format with direct HTTPS retrieval from the Subject Authority's well-known URL. This is a deployment variant of the DAI mechanism, not a second Trust Method registered by this document.¶

Under this variant, the Assertion Issuer is acceptable if the Subject Authority identified by the assertion's Subject Identifier publishes an HTTPS well-known Issuer Authorization Policy authorizing the Assertion Issuer.¶

{
  "method": "domain_authorized_issuer",
  "lookup": "https_only"
}

The lookup member is OPTIONAL. If present, its value MUST be https_only. This variant reuses the Issuer Authorization Policy document format (Section 3), Subject Authority determination rules ([TRUST-FRAMEWORK] §Subject Authority Determination), HTTPS document URL (Section 4.4), verification rules (Section 6), and caching rules (Section 7), but it does not perform the DNS lookup defined in Section 5.¶

When evaluated, the Resource Authorization Server MUST:¶

1. Determine the Subject Authority A from the assertion's Subject Identifier per [TRUST-FRAMEWORK] §Subject Authority Determination. If the format is not registered in [TRUST-FRAMEWORK] §Subject Authority Extraction Procedures Registry, reject the assertion.¶

2. Fetch the Issuer Authorization Policy directly from the default HTTPS well-known URL https://{A}/.well-known/oauth-issuer-policy per Section 4.4. The Resource Authorization Server MUST NOT query _oauth-issuer-policy.{A} as part of this Trust Method and MUST NOT use a DNS uri= pointer.¶

3. Classify HTTPS retrieval and document validation outcomes per Section 5.1. Negative and Indeterminate states MUST result in rejection, except that a fresh cached policy MAY be used when the live retrieval is Indeterminate.¶

4. Verify the fetched policy and match the Assertion Issuer against authorized_issuers using steps 3 and 4 of Section 6, including Section 6.1 when the policy's mode is monitor.¶

A Resource Authorization Server uses this variant when it requires authority publication via HTTPS only and explicitly does not accept DNS-published authority (inline or DNS pointer). Compared to canonical DNS-first lookup, this mode:¶

• Eliminates dependence on DNS resolution integrity for the authority lookup. The Subject Authority is determined per [TRUST-FRAMEWORK] §Subject Authority Determination, but the authorization itself is retrieved only over TLS-authenticated HTTPS.¶

• Rejects the inline DNS form (where the policy is carried in the TXT record itself) and the DNS pointer form (where DNS points at a different HTTPS host). Both require trusting DNS for the authoritative selection of either issuers or policy host.¶

• Forces the Subject Authority to control the apex web origin identified by the well-known URL.¶

8.3. Choosing the Lookup Mode

Within domain_authorized_issuer, a Resource Authorization Server selects one lookup mode:¶

• Canonical DNS-first lookup is the default. The Resource Authorization Server queries _oauth-issuer-policy.{A} first and falls back to the HTTPS well-known URL on negative-authoritative DNS responses (Section 5). The "no DNS record, only HTTPS document" Subject Authority case is therefore already covered without the HTTPS-only variant.¶

• HTTPS-only lookup is an explicit deployment variant. Use it when local policy distrusts DNS-published authority entirely and requires authority retrieval over TLS-authenticated HTTPS only. Inline DNS records and DNS pointer forms are rejected.¶

Resource Authorization Servers MUST NOT evaluate both lookup modes as alternatives for the same assertion. Doing so creates an availability-driven fallback: an attacker who can drive the DNS lookup to indeterminate (resolver denial-of-service, BGP disruption) could force fallthrough to HTTPS-only evaluation, defeating the fail-closed property of the DNS-first lookup.¶

9.1. Namespace Authority Bootstrap

DAI's authority binding is DNS control of the registrable domain (or corresponding HTTPS well-known URL), the bootstrap model used by CAA [RFC8659] and MTA-STS [RFC8461]. Pre-existing DNS realities (typosquatting, expired-domain takeover, registrar account compromise) apply unchanged and are not introduced by this document. The registrable-domain default contains subdomain-takeover impact ([TRUST-FRAMEWORK] §Subject Authority Determination); identity binding beyond DNS control (legal-entity verification) requires out-of-band mechanisms.¶

9.2. Transport Integrity

HTTPS retrieval integrity rests on TLS server authentication of the policy host; the inline DNS form rests on DNS resolution alone; the pointer form rests on both. Subject Authorities concerned about TLS misissuance are encouraged to publish CAA records [RFC8659] for the policy-hosting domain and to monitor Certificate Transparency logs.¶

9.3. HTTPS-Only Authority Trust Model

The HTTPS-only lookup mode (Section 8.2) substitutes TLS-server authentication for DNS-published authority. The threat surfaces differ from the canonical DNS-first lookup of domain_authorized_issuer:¶

• DNS-record attacks (Section 9.4) do NOT affect authority retrieval; the TXT record is not fetched.¶

• Apex-hostname resolution still uses DNS. A DNS-redirect of the apex combined with TLS misissuance substitutes the policy; CAA records and Certificate Transparency monitoring are the primary defenses (Section 9.2).¶

• The DNS pointer form's policy-host risk (Section 9.5) does not apply; the policy is served from the Subject Authority's own apex origin.¶

• Subject Authorities that cannot control the apex web origin (apex hosted on a marketing CDN with no path control) cannot participate via this mode.¶

The trade-off between the two lookup modes is discussed in Appendix A.4.¶

9.4. DNS Integrity and Compromise

An adversary who can substitute a forged DNS response (off-path resolver spoofing, authoritative nameserver hijack, registrar account compromise, BGP hijack, recursive cache poisoning) can substitute the Subject Authority's policy: add an attacker- controlled Assertion Issuer to the inline form, redirect a uri= pointer, or force indeterminate outcomes to benefit a cached attacker-friendly policy. The pointer form additionally depends on TLS authentication of the pointed-at host: TLS does not mitigate the DNS compromise that selected that host.¶

Absent DNSSEC or an authenticated resolver path, the inline DNS form's integrity is no stronger than the recursive resolver path between consumer and authoritative server. Deployments needing a stronger guarantee SHOULD sign the zone with DNSSEC or use the HTTPS document form with the controls of [TRUST-FRAMEWORK] §Shared Infrastructure and Hosted Well-Known Paths; the inline form's "common case" simplicity (Section 4.1) is an operability tradeoff, not an integrity guarantee.¶

Required framework defenses:¶

• Consumers MUST discard records whose authority= does not match the queried Subject Authority. This is the wildcard mitigation: a permissive parent-zone wildcard cannot authorize subdomains because consumers reject records lacking the matching authority= directive.¶

• Consumers MUST verify TLS for any host named by uri=.¶

• Consumers MUST bound cache lifetimes (Section 7; recommended absolute ceiling 24 hours).¶

• Consumers performing DNSSEC validation MUST treat validation failure as indeterminate, not negative-authoritative, to prevent signature-strip downgrade to HTTPS fallback.¶

• Subject Authorities SHOULD sign _oauth-issuer-policy.{A} with DNSSEC, and consumers that do not validate DNSSEC SHOULD use a trustworthy resolver path (DoH/DoT to a vetted resolver).¶

Forged-Negative downgrade: a negative-authoritative DNS result (NXDOMAIN/NODATA) triggers the HTTPS well-known fallback (Section 5). A consumer that does not validate DNSSEC cannot distinguish a forged negative answer from a genuine one, so an attacker able to both spoof a negative DNS response and serve (or redirect to) the victim's apex HTTPS origin can suppress a legitimately published inline record and substitute an attacker-controlled HTTPS policy. Consumers that do not validate DNSSEC and expect a Subject Authority to publish inline records SHOULD NOT honor a Negative-to-HTTPS transition for that authority without an authenticated resolver path; where the Subject Authority's publication channel is configured or discoverable, treat an unexpected Negative with the same suspicion as Indeterminate.¶

Operational defenses Subject Authorities are encouraged to apply: registrar account lock; monitoring of the record set and policy document for unexpected changes; cross-region/cross-resolver checks to detect localized substitution; avoiding wildcard TXT records in zones participating in this mechanism.¶

9.5. Policy Hosts

The DNS pointer form lets the Subject Authority move rich policy from DNS into an HTTPS document. In this version, the pointed-to host is expected to be under the Subject Authority's operational control. General shared-infrastructure risks (multi-tenant CDNs, cache rules, dangling origins) are covered in [TRUST-FRAMEWORK] §Shared Infrastructure and Hosted Well-Known Paths. Three DAI-specific points:¶

• The pointer target is trusted fully for the policy contents and is appropriate only when the host is operated for, or otherwise controlled by, the Subject Authority.¶

• Both the DNS-side authority= directive and the JSON-side subject_authority member MUST match the queried Subject Authority. Each binding is published through a different control path; one missing check would let a compromise of either party claim arbitrary namespaces.¶

• The uri= pointer is a long-lived trust delegation. Subject Authorities SHOULD reduce DNS TTLs in advance of any planned change of policy host.¶

9.6. Monitor-Mode Downgrade

An attacker who can modify the published policy has a stealthier option than adding their own issuer: flipping mode from enforce to monitor. The policy remains present and superficially intact, but enforcement is silently off (Section 6.1). A variant targets signed policies: because unsigned members absent from the signed JWT are not conflict-checked ([TRUST-FRAMEWORK] §Signed Policy Metadata), an attacker who can edit the outer document but not the JWT can inject an unsigned mode: monitor beside an intact signature. Subject Authorities publishing signed_policy SHOULD therefore include mode among the signed claims, so that an injected outer value is rejected as a conflict. Consumers SHOULD surface mode transitions for a given Subject Authority in their logs, and Subject Authorities SHOULD monitor their published records for unexpected mode changes with the same rigor as for issuer-list changes (Section 11). Because monitor mode accepts any authenticated issuer for the namespace, a policy observed in monitor mode for an extended period SHOULD be treated by operators on both sides as a misconfiguration signal.¶

9.7. Policy Conflicts and Determinism

The lookup procedure (Section 5) is deterministic across the common conflict scenarios that arise when multiple records or sources coexist. Determinism is a security property: two verifiers receiving the same DNS and HTTPS responses MUST reach the same conclusion about what (if any) policy applies. An attacker with partial control of one publication channel cannot exploit interpretive ambiguity at the consumer.¶

Common conflict scenarios and their deterministic dispositions are specified in Section 5.1.¶

9.8. Mechanism Limits

• Authentication. The inline DNS form has no signing mechanism; its authority binding is DNS control. The HTTPS document form relies on DNS selection plus TLS to the selected policy host.¶

• Scope. A Resource Authorization Server MUST NOT use a matched Issuer Authorization Policy to establish trust for subjects outside that Subject Authority's namespace.¶

• Inline-form features. The inline DNS form expresses only "issuer X is authorized for Subject Authority A." Deployments needing tenant, subject_identifier_formats, valid_from, valid_until, or explicit denial (an empty authorized_issuers array, Section 3) MUST use the HTTPS or DNS pointer form; a recognized inline record with no issuer= is malformed, so the inline form cannot publish an empty delegation set.¶

9.9. Email Local-Part Is Not Authenticated

domain_authorized_issuer evaluates only the email's registrable domain. The local-part is unauthenticated by this Trust Method: it attests that the Assertion Issuer may assert about emails in the namespace, not that any specific local-part is correct. Resource Authorization Servers that normalize local-parts (case folding, plus-address stripping, alias collapsing) inherit those assumptions from the Assertion Issuer; an attacker controlling an issuer-accepted alias can land on a different normalized user. Either disable local-part normalization or verify the local-part through a mechanism outside this document. See also [TRUST-FRAMEWORK] §Scope of Namespace Authorization.¶

9.10. Single-Issuer Multi-Tenant Identity Providers

The shared-issuer case and its tenant binding are demonstrated in the Shared Issuer Variant of the End-to-End Example. Two security points apply:¶

• Unconstrained-listing risk. A Subject Authority that lists a shared issuer with no tenant value authorizes every tenant of that Identity Provider, almost never the intent. Subject Authorities listing a shared issuer SHOULD include tenant. Resource Authorization Servers SHOULD log a warning when accepting under an unconstrained entry and SHOULD consider rejecting as a matter of local policy.¶

• Tenant-isolation dependency. The tenant binding is a wire-format expression of trust, not a cryptographic guarantee. The Resource Authorization Server verifies match against the Subject Authority's chosen tenant value, but cannot verify the Identity Provider's tenant-isolation implementation. A tenant-isolation defect (cross-tenant minting bug, misconfigured admin operation) defeats the wire-format check. Subject Authorities SHOULD prefer per-tenant issuer identifiers where offered and treat shared-issuer listings as long-lived delegations requiring due diligence on the Identity Provider's tenant-isolation guarantees.¶

• Grant profiles without a tenant claim. Under a grant profile that carries no tenant claim (e.g., the generic JWT-bearer grant, [TRUST-FRAMEWORK] §Generic JWT-Bearer Assertion Grant), only entries that omit tenant can match, so tenant-scoped authorization is not expressible. A Subject Authority relying on a shared multi-tenant Assertion Issuer SHOULD NOT authorize that issuer for such a grant unless per-tenant issuer identifiers are used.¶

9.11. Denial of Service, Amplification, and SSRF

The domain_authorized_issuer lookup can be triggered before the Assertion Issuer is known to be trustworthy: the assertion signature validates against the issuer's own key, which an attacker operating their own authorization server controls. An attacker can therefore drive lookups at will, creating three risks:¶

• Reflection/amplification and cache exhaustion. A flood of assertions carrying distinct Subject Authorities (email: x@{random}.example) makes the Resource Authorization Server issue a live DNS query, and on a Negative result an HTTPS fetch, per distinct authority, turning it into a request amplifier aimed at third-party DNS/HTTPS infrastructure and filling its own cache with distinct-authority entries. Consumers MUST bound lookup work: enforce per-Subject-Authority and global rate limits and bound concurrent outstanding lookups. Consumers SHOULD cache Negative and Indeterminate outcomes per Section 7, and MAY impose a maximum number of distinct-authority lookups per unit time, shedding load by treating excess as Indeterminate (fail-closed).¶

• Server-Side Request Forgery. Every HTTPS policy fetch resolves a host the attacker may control: the Subject Authority {A} for the default well-known fetch (the attacker presents an assertion whose namespace is a domain it owns, then points that domain's apex A/AAAA records at an internal address), the uri= pointer's host, the well-known host under the HTTPS-only mode, and any redirect target. The fetch occurs regardless of whether the body validates, enabling blind internal probing through timing and error differentials. For every such fetch, consumers MUST NOT connect to a host that resolves to a private-use, loopback, link-local, unique-local, or otherwise non-globally-routable IPv4 or IPv6 address, MUST cap redirects and response size (Section 4.4, Section 4.5), and SHOULD apply a fetch timeout. The same-registrable-domain constraint on redirects (Section 4.4) further limits redirect-based SSRF.¶

• Cost asymmetry. A single small assertion can cause a full DNS+HTTPS round trip. Consumers SHOULD prefer cached results and SHOULD NOT perform a live lookup until the assertion has passed the cheaper grant-profile validation checks (signature, audience, expiry; [TRUST-FRAMEWORK] §Resource Authorization Server Processing step 2).¶

12.1. Well-Known URI for Issuer Authorization Policy

Registers the following well-known URI in the IANA "Well-Known URIs" registry [RFC8615], for use by this document:¶

URI Suffix:

oauth-issuer-policy¶

Change Controller:

IETF¶

Specification Document:

This document¶

Status:

permanent¶

Related Information:

None¶

The suffix names the document rather than the consuming framework; see Appendix A.2.¶

12.2. Underscored DNS Node Name

Registers the following entry in the IANA "Underscored and Globally Scoped DNS Node Names" registry per [RFC8552] and [RFC8553], for use by this document:¶

RR Type:

TXT¶

_NODE NAME:

_oauth-issuer-policy¶

Reference:

This document, Section 4.3¶

12.3. Trust Method Registrations

This document registers the following entry in the Identity Assertion Issuer Trust Methods registry ([TRUST-FRAMEWORK] §Identity Assertion Issuer Trust Methods Registry):¶

12.4. Issuer Authorization Policy Directives Registry

IANA is requested to establish a new registry titled "OAuth Issuer Authorization Policy DNS Directives" under the "OAuth Parameters" registry group, for the name=value directives carried in the DNS TXT record (Section 4.3).¶

Registration policy: Specification Required [RFC8126].¶

Each entry contains a Directive Name (character set [a-z0-9_-]), a Description, a Change Controller, and a Reference. Designated Expert instructions: the expert verifies the directive name is unique, its value syntax is specified within the ABNF value production of Section 4.3 (ASCII, no ;, no whitespace), and its multiplicity and duplicate-handling rules are stated.¶

Initial entries:¶

12.5. Issuer Authorization Policy Members Registry

IANA is requested to establish a new registry titled "OAuth Issuer Authorization Policy Members" under the "OAuth Parameters" registry group, for the JSON members of the Issuer Authorization Policy document (Section 3).¶

Registration policy: Specification Required [RFC8126].¶

Each entry contains a Member Name, a Description, a Change Controller, and a Reference. Designated Expert instructions: the expert verifies the member name does not collide with an existing member, its JSON type and semantics are specified, and any decision-affecting member states how a consumer that does not recognize it behaves (the default is to ignore unrecognized members; a member requiring fail-closed handling uses the crit mechanism of [TRUST-FRAMEWORK] §Critical Members).¶

Initial entries:¶

13.1. Normative References

[ID-JAG]

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

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[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>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[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>.

[RFC7405]

Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/rfc/rfc7405>.

[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>.

[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>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC8553]

Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", BCP 222, RFC 8553, DOI 10.17487/RFC8553, March 2019, <https://www.rfc-editor.org/rfc/rfc8553>.

[RFC8615]

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

[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>.

[TRUST-FRAMEWORK]

"OAuth Identity Assertion Trust Framework", <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-assertion-framework/>.

13.2. Informative References

[I-D.hardt-email-verification]

"Email Verification Protocol", <https://datatracker.ietf.org/doc/draft-hardt-email-verification/>.

[OIDC-DISCOVERY]

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

[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>.

[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>.

[RFC8461]

Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/rfc/rfc8461>.

[RFC8659]

Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, <https://www.rfc-editor.org/rfc/rfc8659>.

[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>.

A.1. Following Existing DNS Authority Patterns

The Domain-Authorized Issuer Trust Method applies the same authority-publication pattern that domain owners already use for CAA [RFC8659], MTA-STS [RFC8461], SPF, DKIM, DMARC, and the Email Verification Protocol [I-D.hardt-email-verification]. [TRUST-FRAMEWORK] §Authority Delegation Model covers the abstract pattern; this document chooses DNS at _oauth-issuer-policy.{domain} as the authoritative publication channel. The name=value record syntax is closest to DMARC's, and DMARC's operational experience with the Public Suffix List and the organizational-domain boundary informs the Subject Authority Determination approach in [TRUST-FRAMEWORK] §Subject Authority Determination (see also the DBOUND discussion there).¶

Unlike CAA (deployment-time), SPF/DKIM (spam-score signal), and MTA-STS (inbound mail), the _oauth-issuer-policy record is consumed during user sign-in; the operational consequences of that are covered normatively in Section 11.¶

Relationship to issuer discovery. WebFinger [RFC7033] and OpenID Connect Discovery answer a different question: given a user identifier, where does a client go to authenticate the user? This Trust Method is verifier-side and authorization-oriented: given an assertion already in hand, is its issuer authorized for the subject's namespace? DAI is published per namespace (not per user), over a DNS channel whose control establishes the authority binding, and it carries authorization semantics (validity windows, tenant binding, format restrictions) that a discovery record does not. A deployment could layer client-side discovery on top (see Appendix B.4), but that is out of scope here.¶

Relationship to the Email Verification Protocol. EVP [I-D.hardt-email-verification] also publishes, in DNS, issuers associated with an email domain, but for a different purpose: it names issuers that can verify control of an email address (an issuance-time question), whereas DAI names issuers authorized to assert identities in a namespace (a verification-time authorization question). The records differ accordingly: DAI uses full issuer identifiers (including path components) and PSL-normalized Subject Authorities, and carries authorization constraints. Convergence with EVP on a shared record or node name is possible future work; Appendix B.3 sketches a bridge.¶

A.2. Why a Generic Record Name

The DNS node name, well-known URI suffix, and version token name the document they locate (the Issuer Authorization Policy), not the identity framework consuming it. The wire format is subject-class-agnostic: no member or directive is specific to email or identity assertions; the subject class is expressed through subject_identifier_formats ([RFC9493]), and the identity-specific machinery lives in [TRUST-FRAMEWORK], whose own well-known URI is identity-scoped for that reason. A future Subject Identifier format with a DNS-publishable Subject Authority reuses domain_authorized_issuer and this same record ([TRUST-FRAMEWORK] §Future Extensions); an identity-scoped name would force a second record at a second DNS name. One per-domain policy surface, extended through registered members rather than new names, follows the oauth-authorization-server metadata precedent.¶

A.3. Why First-Class Tenant Binding

Shared-issuer multi-tenant Identity Providers (Google Workspace, Auth0 in some configurations, Microsoft Entra B2B in some flows) serve many customer tenants under a single issuer URL. The deployment reality is that these Identity Providers are common; authorizing them without tenant binding effectively authorizes every tenant of the Identity Provider for the namespace, which is almost never the intent.¶

The tenant member on authorized_issuers[] entries binds authorization to the specific tenant identifier the Identity Provider populates in the top-level tenant claim defined in [ID-JAG] §6.1. The binding makes the Subject Authority's choice of authorized tenant observable on the wire and verifiable per assertion. It does not eliminate the trust assumption on the Identity Provider's tenant-isolation enforcement; it makes the assumption explicit and auditable. See Section 9.10.¶

A generic claim-matching mechanism (matching arbitrary JWT claims against publisher-specified values) was considered as an alternative. First-class tenant was preferred because the claim name is standardized in [ID-JAG], the deployment intent is unambiguous, and the wire-format expression is simpler than a generic claim-matching object.¶

A.4. Choosing Between DNS-Published and HTTPS-Only Authority

Canonical DNS-first lookup and HTTPS-only lookup are not strictly ordered by security strength; they trade different risks. HTTPS-only lookup is resilient to TXT-record attacks but depends on apex-hostname resolution plus the public CA trust system; a DNS redirect combined with TLS misissuance defeats it. domain_authorized_issuer in the inline form is resilient to TLS misissuance against the apex because the authority artifact is the TXT record itself; an attacker needs DNS-write or DNSSEC-bypass capability. The DNS pointer form and HTTPS fallback inherit TLS-misissuance risk on the pointed-at host while also depending on DNS for selection.¶

A Subject Authority with strong DNSSEC and weak TLS-issuance controls favors the inline DNS form. A Subject Authority with strong CAA/CT monitoring and limited DNS control favors HTTPS-only.¶

A.5. Why HTTPS Fallback

The framework supports an HTTPS-hosted Issuer Authorization Policy at a well-known URL on the Subject Authority's host. This serves two purposes:¶

• Backward-compatibility runway. Subject Authorities that cannot or do not yet operate the DNS record can participate via HTTPS publication only. The lookup procedure consults the HTTPS well-known URL when the DNS query returns negative-authoritative (Section 5).¶

• Richer policy expression. The HTTPS form supports the full Issuer Authorization Policy JSON schema (validity windows, tenant binding, format restrictions) that the inline DNS form cannot express.¶

DNS remains the entry point; HTTPS is consulted only as fallback when the DNS query returns negative-authoritative. This preserves the DNS-authority pattern as the primary channel while accommodating deployment variations.¶

B.1. Monitoring Reports

Monitor mode (Section 6.1) relies on consumer-side logging with out-of-band delivery to the Subject Authority. A future extension can define an aggregate reporting mechanism, analogous to DMARC's rua: a policy member naming a reporting endpoint, a report format (observed issuers, match/mismatch counts, time window), and delivery requirements. It is deferred because report formats and transport carry privacy and abuse considerations (a reporting endpoint learns which Resource Authorization Servers a namespace's users sign in to, concentrating the metadata discussed in Section 10) that deserve their own document.¶

B.2. Audience-Scoped Delegations

An authorized_issuers entry authorizes an issuer for a namespace without constraining which Resource Authorization Servers may accept the resulting assertions; a compromised-but-listed issuer can assert the namespace's users to any consumer ([TRUST-FRAMEWORK] §Scope of Namespace Authorization). A future permitted_audiences member on entries would let a Subject Authority bound that blast radius by enumerating or pattern-matching acceptable audiences. It is deferred because audience identifiers are grant-profile-specific and an enumerable audience set does not exist for the open-world deployments this mechanism targets; a workable design likely needs audience patterns and an interaction rule with the assertion's aud claim.¶

B.3. Email Verification Protocol Bridge

The Email Verification Protocol [I-D.hardt-email-verification] defines a DNS TXT record at _email-verification.{domain} whose iss= value names an authorized issuer for the namespace, using a bare hostname rather than a full HTTPS issuer identifier. A future Trust Method (provisionally email_verification_dns) could let a Resource Authorization Server honor those records without requiring the Subject Authority to also publish an _oauth-issuer-policy record.¶

The bridge is deferred because it forces the reader to learn a second record format, a different issuer-identifier shape (bare-origin only, no path component), and a different email-domain semantics (the Email Verification Protocol parses the email's raw domain part, whereas this document normalizes to the registrable domain via the Public Suffix List). It is also deferred because [I-D.hardt-email-verification] is progressing on its own timeline independent of this document. Deployments wanting the bridge can either publish both records (an _oauth-issuer-policy record satisfying domain_authorized_issuer plus their existing _email-verification record for other consumers) or wait for the future Trust Method specification.¶

B.4. Assertion Issuer Discovery (Client-Side)

The same DAI records that let a Resource Authorization Server verify an assertion can also let a client discover which Assertion Issuer is authoritative for a subject identifier's namespace before any assertion exists: given alice@acme.example, a client can query _oauth-issuer-policy.acme.example, retrieve the Issuer Authorization Policy, and resolve an authorized issuer's authorization server metadata to find its token endpoint (entry order carries no semantics, so issuer selection would need to be specified by the profiling document).¶

This client-side use case is deferred from the first version of DAI because it adds a second mental model (back-channel discovery vs. verification at token exchange), introduces privacy concerns distinct from verification (the discovery query reveals the queried Subject Authority to DNS resolvers and to the policy host before any user interaction), and is not on the Resource Authorization Server implementer's critical path. A future specification can profile the discovery flow with appropriate privacy guidance and integration with OAuth Authorization Server Metadata [RFC8414] and OpenID Connect Discovery [OIDC-DISCOVERY].¶

C.1. Cast

• Subject Authority, acme.example. A small organization that owns its DNS but does not operate an authorization server capable of issuing identity assertions.¶

• Assertion Issuer, https://idp.example.net. A managed authorization server service acme.example has contracted with.¶

• Resource Authorization Server, https://api.resource.example.¶

• Client, a backend SaaS integration.¶

• End user, Alice (alice@acme.example).¶

C.2. Publication

The Subject Authority publishes a single DNS TXT record:¶

_oauth-issuer-policy.acme.example. IN TXT ( "v=oauth-issuer-policy1;"
    "authority=acme.example;"
    "issuer=https://idp.example.net" )

The quoted segments are concatenated without a separator, yielding v=oauth-issuer-policy1;authority=acme.example;issuer=https://idp.example.net. No HTTPS endpoint is operated on acme.example.¶

The Resource Authorization Server publishes a trust policy that accepts domain-authorized issuer delegations with DNS-based discovery:¶

{
  "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": "domain_authorized_issuer"
    }
  ]
}

C.3. Issuance and Token Request

1. The Client is configured, by a deployment-specific mechanism outside DAI, to use https://idp.example.net for Acme users. It authenticates Alice at that issuer and requests an ID-JAG with audience https://api.resource.example carrying Alice's email:¶

   {
     "iss": "https://idp.example.net",
     "aud": "https://api.resource.example",
     "exp": 1780166400,
     "iat": 1780166100,
     "jti": "5a17...",
     "sub": "user-9241ab",
     "email": "alice@acme.example",
     "email_verified": true
   }
   

   ¶

2. The Client posts to the Resource Authorization Server's token endpoint with private_key_jwt client authentication:¶

   POST /token HTTP/1.1
   Host: api.resource.example
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
   &assertion=eyJhbGciOiJSUzI1NiIs...
   &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
   &client_assertion=eyJhbGciOiJFUzI1NiIs...
   

   ¶

C.4. Verification (Resource Authorization Server Side)

1. The Resource Authorization Server validates the ID-JAG: signature (via https://idp.example.net/.well-known/openid-configuration JWKS), aud, exp, iat, replay protection.¶

2. The Resource Authorization Server evaluates the domain_authorized_issuer Trust Method.¶

   a. It extracts the Subject Authority from the top-level email claim (with email_verified=true): acme.example.¶

   b. Applying the canonical lookup procedure (Section 5), the Resource Authorization Server queries DNS TXT at _oauth-issuer-policy.acme.example and parses the record published earlier in this example.¶

   c. The authority=acme.example directive matches. No uri= is present. The Resource Authorization Server constructs a virtual policy for acme.example with one authorized_issuers entry for https://idp.example.net.¶

   d. The ID-JAG iss value https://idp.example.net matches the single entry's issuer value. Verification succeeds.¶

3. The Resource Authorization Server validates private_key_jwt, then issues an access token in the response body.¶

C.5. Migration Variant: Pointer Form

If acme.example later wants to express validity windows, format restrictions, or tenant binding, it can switch to the pointer form without changing any consumer behavior:¶

_oauth-issuer-policy.acme.example. IN TXT ( "v=oauth-issuer-policy1;"
    "authority=acme.example;"
    "uri=https://acme.example/.well-known/oauth-issuer-policy" )

and publish the richer JSON document at the pointed-at URL:¶

{
  "subject_authority": "acme.example",
  "authorized_issuers": [
    {
      "issuer": "https://idp.example.net",
      "subject_identifier_formats": ["email"],
      "valid_until": "2027-05-30T00:00:00Z"
    },
    {
      "issuer": "https://idp-backup.example.net",
      "subject_identifier_formats": ["email"]
    }
  ],
  "last_updated": "2026-05-29T00:00:00Z"
}

Resource Authorization Servers transparently follow the uri= directive and consume the JSON document. No verifier software changes are required.¶

C.6. Shared Issuer Variant: Multi-Tenant Identity Provider

The simple example above uses a per-tenant issuer identifier (https://idp.example.net is dedicated to Acme). Some Identity Providers serve every tenant under a single shared issuer (for example, https://accounts.google.com) and distinguish tenants via the ID-JAG top-level tenant claim ([ID-JAG] §6.1). For these, the authorized_issuers[].tenant member binds the authorization to a specific tenant of the shared issuer.¶

Suppose Acme uses a multi-tenant Identity Provider with shared issuer https://accounts.shared.example and Acme's tenant identifier in that Identity Provider is acme-corp. Acme publishes the pointer form pointing at the richer JSON:¶

{
  "subject_authority": "acme.example",
  "authorized_issuers": [
    {
      "issuer": "https://accounts.shared.example",
      "tenant": "acme-corp",
      "subject_identifier_formats": ["email"]
    }
  ],
  "last_updated": "2026-05-29T00:00:00Z"
}

Verification adds one check to the simple flow: in addition to matching iss, the Resource Authorization Server requires the ID-JAG's top-level tenant claim to equal "acme-corp". An assertion from https://accounts.shared.example with a different tenant value (or no tenant) does not match this entry. The security properties and operational guidance for this case are in Section 9.10.¶

C.7. Failure Variants

• A DNS SERVFAIL at _oauth-issuer-policy.acme.example is classified as indeterminate (Section 5.1). The Resource Authorization Server does not fall back to https://acme.example/.well-known/oauth-issuer-policy; it returns invalid_grant.¶

• A wildcard record at *.example covering acme.example would have to carry authority=acme.example to be accepted. A wildcard with a different authority= is discarded; if no other recognized record remains, the response is malformed (Indeterminate) and the assertion is rejected with no fallback to the well-known URL.¶

• If acme.example rotates its authorized Assertion Issuer and the Resource Authorization Server has a cached virtual policy, the Resource Authorization Server may continue accepting assertions from the old issuer until its cache expires. Subject Authorities are encouraged to use short DNS TTLs during rotation; consumers enforce a local cache ceiling per Section 7.¶