Web Authorization Protocol S. Canning Internet-Draft Canva Intended status: Standards Track 16 June 2026 Expires: 18 December 2026 Issuer-to-Domain Authority Binding for OAuth draft-canning-oauth-issuer-domain-binding-latest Abstract This document defines a mechanism by which an OAuth 2.0 Authorization Server publishes the set of email domains for which it claims authority, so that a Relying Party can determine — independently of the user-controlled email address used to discover the issuer — whether the issuer is entitled to assert identity claims (in particular, email-bearing and email_verified claims) for accounts in a given email domain. A binding document is served at a well-known URI under the issuer, or inlined into the Authorization Server metadata document, listing the authoritative email domains. Relying Parties that perform email- domain issuer discovery MUST validate that the discovered email domain is present in the issuer's binding before accepting the issuer's claims about accounts in that domain. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Editor's note: running-code basis 1.2. Terminology 2. Issuer Binding Document 2.1. Publication 2.2. Inline metadata form 2.3. Standalone document form 2.4. Matching rules for domain patterns 2.5. Signing 2.6. Caching 3. Relying Party Closing-the-Loop Rule 3.1. When the rule applies 3.2. Required validation steps 3.3. Use of email_verified 3.4. Failure handling 4. Degraded-Trust Mode 5. Auto-Account-Linking by Email 6. Security Considerations 6.1. Multi-tenant issuer overclaiming 6.2. Compromise of a single tenant's binding document 6.3. Substitution of the discovered email domain 6.4. Interaction with email-domain spoofing of inbound mail 6.5. Effect on phishing of one-time codes 6.6. Privacy: leakage of authoritative-domain lists 7. IANA Considerations 7.1. OAuth Authorization Server Metadata 7.2. Well-Known URI 7.3. Media Type 8. References 8.1. Normative References 8.2. Informative References Appendix A. Open Issues A.1. A.1 Required signing posture A.2. A.2 Per-tenant binding for shared issuer URLs A.3. A.3 Revocation A.4. A.4 Wildcard / public suffix detection A.5. A.5 Internationalised email domains A.6. A.6 Interaction with email vs. email_verified vs. other identifiers Appendix B. Acknowledgments Author's Address 1. Introduction Email-domain-based issuer discovery [I-D.canning-oauth-dns-issuer-discovery] (and the longer-standing WebFinger mechanism in [OIDC-Discovery] §2) establishes a one-way delegation: the email domain's DNS operator points at an Authorization Server (the "issuer"). It does not establish the reverse: that the issuer is authoritative for the email domain it has been pointed at. In an environment with one issuer per organisation, the two directions are effectively the same edge in the graph, and an attacker who controls neither end cannot insert themselves. In any environment where the issuer is shared between organisations — most production SaaS Identity Provider deployments, including those that use a multi-tenant Authorization Server fronted by per-tenant issuer URLs — the absence of a reverse binding is exploitable. A tenant of the shared issuer can sign tokens carrying email claims for email domains it does not control, and Relying Parties that follow naïve "discover the issuer, then trust whatever it says about email addresses" logic will accept those tokens. Google's hd parameter [GOOGLE-HD] represents the closest existing prior art: it lets Google Identity Platform pre-filter the IdP's authentication response by hosted-domain. It is proprietary, single- issuer, and does not address the multi-issuer ecosystem this profile targets. OpenID Federation 1.0 [OIDF-FED] solves a strictly stronger problem: it establishes a federation trust anchor that signs over the entire trust chain, including domain authority. Federation 1.0 is appropriate where a federation operator exists. For the general SaaS-to-enterprise ecosystem, no such operator exists, and a lighter- weight binding mechanism is required. This document specifies that mechanism. The mechanism has two parts: * An *issuer binding document* that enumerates the email domains the issuer claims authority for. * A *Relying Party closing-the-loop rule* that requires the Relying Party to verify that the email domain it used for issuer discovery is present in the issuer's binding document before accepting any identity claim from the issuer about that domain. The mechanism does not require a third-party trust anchor; it relies on the same DNS + TLS chain used elsewhere in OAuth and OpenID Connect. It is intentionally weaker than [OIDF-FED] and can serve as a stepping stone to it. 1.1. Editor's note: running-code basis This draft is motivated by gap *GAP-2* ("Issuer↔domain authority binding") recorded in spec/GAPS.md of the zeroconf-sso prototype [ZEROCONF-SSO][GAPS]. That document's own threat model identifies this binding as "the single most security-relevant gap in the profile". Unlike the companion draft on DNS issuer discovery, the prototype Relying Party does NOT yet implement this binding. The PROTOCOL.md §10.1 catalogue accordingly limits the trust placed in the discovered issuer; once this binding mechanism is widely deployed the prototype Relying Party can be updated to honour it and the trust restriction lifted. 1.2. Terminology 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. The following terms are used throughout, in addition to the terms defined in [RFC6749], [RFC8414], and [OIDC-Core]. Email domain: The substring of an email address after the final @ character. Issuer: The OAuth 2.0 Authorization Server identifier, per [RFC8414] §2. Authoritative for an email domain: An issuer is *authoritative* for an email domain D if the issuer's binding document (Section 2) lists D per the matching rules of Section 2.4. Binding document: A JSON object served by the issuer that enumerates the email domains for which the issuer claims authority. Defined in Section 2. Discovered email domain: The email domain that the Relying Party used as input to issuer discovery (per [I-D.canning-oauth-dns-issuer-discovery] or [OIDC-Discovery] §2). It is the domain part of the End-User- supplied email address. 2. Issuer Binding Document 2.1. Publication An Authorization Server that implements this specification MUST publish a binding document. The document MAY be inlined into the Authorization Server metadata document [RFC8414] via the authoritative_email_domains metadata member (Section 2.2) OR served at a separate well-known URI under the issuer (Section 2.3). Both publication forms are normatively equivalent for the purposes of the Relying Party validation in Section 3. If both forms are present, they MUST be byte-identical with respect to the authoritative_email_domains member. A Relying Party that detects a discrepancy MUST treat the issuer as NOT authoritative for any email domain (closing-the-loop failure, Section 3.4). 2.2. Inline metadata form The Authorization Server MAY register the following member in the Authorization Server metadata document [RFC8414]: authoritative_email_domains: A JSON array of strings. Each string is an email-domain pattern as defined in Section 2.4. The array MUST contain at least one element if present. The array MUST NOT contain duplicate entries (case- folded comparison per Section 2.4). Example: { "issuer": "https://idp.example.com", "authorization_endpoint": "https://idp.example.com/authorize", "token_endpoint": "https://idp.example.com/token", "jwks_uri": "https://idp.example.com/jwks", "authoritative_email_domains": [ "example.com", "*.example.com", "subsidiary.example" ] } 2.3. Standalone document form The Authorization Server MAY serve a binding document at the well- known URI: GET /.well-known/oauth-authoritative-domains The path is constructed per [RFC8414] §3, with oauth- authoritative- domains replacing oauth-authorization-server. The response MUST be 200 OK, Content-Type: application/json (or application/jose+json for the signed form, Section 2.5), and parse to a JSON object with at minimum: { "issuer": "https://idp.example.com", "authoritative_email_domains": [ "example.com", "*.example.com" ], "iat": 1797600000, "exp": 1797700000 } Members: issuer: REQUIRED. MUST equal the issuer URL at which the document is served, by simple string comparison ([RFC3986] §6.2.1, per [RFC8414] §3.3). authoritative_email_domains: REQUIRED. Format as in Section 2.2. iat: REQUIRED. Integer seconds since the Unix epoch. The time at which the document was generated by the issuer. exp: REQUIRED. Integer seconds since the Unix epoch. The time at which the document expires. The Relying Party MUST reject a document with exp <= now. The Relying Party SHOULD allow up to 60 seconds of clock skew on this comparison. The standalone form is RECOMMENDED for issuers serving more than 10 authoritative email domains, since the inline form would otherwise bloat the Authorization Server metadata document on every fetch. 2.4. Matching rules for domain patterns Each entry in authoritative_email_domains is either: * an *exact domain*, e.g. example.com; or * a *wildcard pattern* of the form *., where is a domain name with at least two labels. A discovered email domain D matches an entry E if and only if: * E is an exact domain and the U-label form of D is equal to the U-label form of E, compared per the IDNA2008 ([RFC5891]) rules for the lower-case form of each label; OR * E is a wildcard pattern *. and D ends with . (case-folded, IDNA2008), and the prefix of D before . consists of at least one full DNS label. The wildcard pattern *. MUST NOT match itself; to authorise both parent.example and sub.parent.example the issuer MUST list both parent.example and *.parent.example. Multi-label wildcards (*.*.example.com, **.example.com) are not defined by this document. A single *. matches across one DNS label only. Public Suffix List ([PSL] §3) entries are NOT a syntactic restriction; the Relying Party validation in Section 3 includes a discouragement of overbroad bindings, but does not refuse e.g. *.co.uk. Implementer-side detection of bindings that span public suffixes is RECOMMENDED but is out of scope for this document. 2.5. Signing The standalone-document form MAY be served as a JWS Compact Serialization [RFC7515] bearing Content-Type: application/jose+json and decodes to the JSON object specified in Section 2.3. The JWS protected header MUST include alg, kid, and typ, with typ set to oauth-authoritative-domains+jwt. The signing key MUST be one published in the issuer's jwks_uri ([RFC8414] §2). A Relying Party MUST validate the signature against that JWKS before consuming the document. Signing is OPTIONAL because TLS to the issuer is the same trust anchor used elsewhere in [RFC8414] for the metadata document. Use of the JWS form provides defence in depth: if an attacker briefly controls a hosting endpoint at the issuer URL but does not control the signing key, the JWS form remains tamper-evident. Issuers that use the inline form (Section 2.2) inherit the same TLS- only posture as the rest of the AS metadata document. 2.6. Caching The Relying Party MAY cache the binding document, but MUST NOT honour cache entries past the document's exp (for the standalone form) or past the cache lifetime governed by HTTP cache headers on the AS metadata document (for the inline form). RECOMMENDED minimum and maximum bounds are 5 minutes and 24 hours respectively. A Relying Party MUST invalidate any cached binding document upon observing that the issuer's jwks_uri content has rotated in a way that invalidates the cached JWS-form document's signature. 3. Relying Party Closing-the-Loop Rule 3.1. When the rule applies This rule applies to a Relying Party performing email-domain-based issuer discovery, as defined by [I-D.canning-oauth-dns-issuer-discovery] or [OIDC-Discovery] §2. It does not apply to flows in which the issuer was selected by the Relying Party out-of-band (e.g. the user clicked a "Sign in with Acme" button against a pre-configured Acme issuer; that selection itself is the binding). 3.2. Required validation steps After completing issuer discovery and Authorization Server metadata retrieval, and before initiating the authorization request, the Relying Party MUST: 1. Fetch the issuer's binding document (Section 2), preferring the inline form if present in the already-retrieved AS metadata. 2. If the standalone form is used, validate the document per Section 2.3, Section 2.4, and (if a JWS is presented) Section 2.5. A failure at any step is handled per Section 3.4 below. 3. Check that the discovered email domain matches at least one entry in authoritative_email_domains, per Section 2.4. If the discovered email domain matches, the Relying Party MAY proceed with the authorization request. 3.3. Use of email_verified A Relying Party that has performed the steps in Section 3.2 successfully MAY treat the email_verified claim ([OIDC-Core] §5.1) in the resulting ID Token as enterprise-grade evidence that the End-User controls the email claim's address, *only for addresses whose domain matches at least one entry in the issuer's binding document*. A Relying Party that has NOT performed the steps in Section 3.2, or that performed them and observed a closing-the-loop failure per Section 3.4, MUST NOT use email_verified from this issuer as enterprise-grade evidence for any address in the discovered email domain. It MAY treat the claim as consumer-grade evidence (i.e. as one signal among others), subject to local policy. 3.4. Failure handling A failure at step 1 of Section 3.2 (no binding document available), at step 2 (binding document fails validation), or at step 3 (discovered email domain not in the binding) is a *closing-the-loop failure*. On a closing-the-loop failure the Relying Party MUST NOT initiate the authorization request — except in the degraded-trust mode permitted by Section 4. If the Relying Party operates in degraded-trust mode under Section 4 and the authorization request succeeds, the resulting ID Token MUST be treated under the consumer-grade-evidence rule of Section 3.3. 4. Degraded-Trust Mode A Relying Party MAY proceed with the authorization request despite a closing-the-loop failure if and only if: * the Relying Party is operating an "unmanaged" or "experimental" tier with restricted policy (e.g. extra consent, restricted scope, no auto-account-linking by email); AND * the Relying Party logs the closing-the-loop failure and surfaces it to the End-User in the consent step. The intent of degraded-trust mode is to permit gradual deployment of this binding mechanism: issuers that have not yet published a binding document still authenticate users, but the Relying Party does not lift their tokens to enterprise-grade trust. A Relying Party that does not implement degraded-trust mode MUST fail closed on closing-the-loop failure. 5. Auto-Account-Linking by Email The most security-relevant Relying Party behaviour that this document governs is *auto-account-linking*: the practice of treating two distinct authentication paths that present the same email/ email_verified claim as referring to the same end-user identity. A Relying Party that auto-links accounts by email MUST NOT do so when the email's domain has no enterprise-grade binding (i.e. when the rule of Section 3.2 is not satisfied for this issuer and this domain). Failure to honour this restriction reintroduces the threat model described in Section 6. 6. Security Considerations 6.1. Multi-tenant issuer overclaiming The primary threat this specification addresses is overclaiming by a tenant of a multi-tenant Authorization Server. Without a binding document, a tenant evil-co of a shared Authorization Server at https://idp.example.com/ can configure its tenant policy to assert email: ceo@target.example and email_verified: true on tokens it signs. A Relying Party that does not implement this specification, and that performs issuer discovery for target.example and (by coincidence or by attacker substitution of target.example's DNS records) reaches the same shared Authorization Server, will trust those tokens. With a binding document, the Relying Party verifies that target.example appears in the issuer's authoritative_email_domains list. A shared Authorization Server operated by a competent issuer operator does NOT list every customer's domain in a single binding document; instead, it serves per-tenant issuer URLs (typically with per-tenant paths or hostnames) each with their own narrower binding document. The shared root https://idp.example.com/ either does not serve a binding document at all, or serves one listing only domains the operator itself controls. This pushes the operational responsibility for correct binding onto the Authorization Server operator, where it belongs. The Relying Party cannot, in general, distinguish a misbehaving issuer from a misconfigured issuer; it can only refuse to trust an issuer that does not produce evidence of authority for the domain in question. 6.2. Compromise of a single tenant's binding document If an attacker compromises the binding document for a single tenant (by, for example, briefly taking control of the well-known URI), the attacker can list arbitrary email domains. The window during which a Relying Party will trust the compromised document is bounded by the caching rules of Section 2.6. Issuers SHOULD set short exp values on the standalone-document form (RECOMMENDED 1 hour or less) so that recovery from compromise is fast. Issuers that have a meaningful key-rotation story SHOULD use the JWS form (Section 2.5) so that an attacker who controls the hosting endpoint but not the signing key cannot mint a forged binding document. 6.3. Substitution of the discovered email domain This document presupposes that the discovered email domain is the domain the End-User typed. An attacker who can substitute the End- User's input (e.g. cross-site scripting on the Relying Party's login form) can drive the discovery to an issuer of their choice, which they may also control. The binding mechanism does not address this threat; it is addressed by the Relying Party's normal session and input-handling protections. 6.4. Interaction with email-domain spoofing of inbound mail This document concerns SSO authentication. It says nothing about email transport (SPF, DKIM, DMARC). An issuer that is authoritative for example.com in the SSO sense is not therefore authoritative for delivering mail as example.com, nor vice versa. Operators SHOULD NOT assume that the SSO binding implies anything about email transport policy. 6.5. Effect on phishing of one-time codes A common consumer-grade phishing pattern is: attacker sends a "reset your password" email to victim@target.example, victim clicks a link that goes to an attacker site, which then walks the victim through an SSO flow at an attacker-controlled issuer that issues email_verified: target.example. This document's closing-the-loop rule, when implemented, defeats this attack: the Relying Party's issuer discovery for target.example will not reach the attacker- controlled issuer; if the Relying Party is somehow induced to use the attacker's issuer directly, the issuer's binding document will not list target.example. 6.6. Privacy: leakage of authoritative-domain lists A binding document is, by design, publicly accessible. The list of domains a shared Authorization Server is authoritative for therefore constitutes a public enumeration of that issuer's enterprise customers. For most enterprise Identity Provider operators this is not sensitive (customer logos are already on the marketing site). Operators for whom customer identity is sensitive MAY: * Use per-tenant issuer URLs that each carry only that tenant's domains, so that the shared root issuer URL serves only the operator's own marketing domains. * Treat the binding document as access-restricted in some out-of- band channel; this document does not define an access-controlled form and Relying Parties cannot consume one as currently specified. 7. IANA Considerations 7.1. OAuth Authorization Server Metadata This document registers the following member in the "OAuth Authorization Server Metadata" registry established by [RFC8414]: Metadata Name: authoritative_email_domains Metadata Description: A JSON array of email-domain patterns for which this issuer claims authority for identity assertions, including email_verified. Change Controller: IETF Reference: This document, Section 2.2 7.2. Well-Known URI This document registers the oauth-authoritative-domains well-known URI in the "Well-Known URIs" registry established by [RFC8615]. URI suffix: oauth-authoritative-domains Change controller: IETF Specification document: This document, Section 2.3 Related information: None 7.3. Media Type This document registers application/oauth-authoritative-domains+jwt as a media type for the JWS-signed form of the binding document (Section 2.5), per [RFC6838]. 8. References 8.1. Normative References [OIDC-Core] OpenID Foundation, "OpenID Connect Core 1.0 incorporating errata set 2", December 2023, . [OIDC-Discovery] OpenID Foundation, "OpenID Connect Discovery 1.0 incorporating errata set 2", December 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . 8.2. Informative References [GAPS] "zeroconf-sso: standards gaps log (spec/GAPS.md)", 2026, . [GOOGLE-HD] "Google Identity Platform: OpenID Connect — the hd parameter", 2025, . [I-D.canning-oauth-dns-issuer-discovery] Canning, S., "DNS-Based Discovery of OAuth Authorization Servers for Email Domains", 2026, . [I-D.canning-oauth-registration-lifecycle] Canning, S., "Registration Lifecycle and Continuous Signalling for OAuth Clients", 2026, . [OIDF-FED] OpenID Foundation, "OpenID Federation 1.0", 2024, . [PSL] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC Editor, DOI 10.17487/rfc8499, January 2019, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [ZEROCONF-SSO] "zeroconf-sso prototype and profile (running code)", 2026, . Appendix A. Open Issues This appendix lists open questions that remain unresolved in this revision. They are the residue of spec/GAPS.md GAP-2 in the zeroconf-sso prototype [ZEROCONF-SSO][GAPS] that this document deliberately did not foreclose. A.1. A.1 Required signing posture Section 2.5 makes the JWS form OPTIONAL. The argument for mandating it is defence-in-depth against hosting-endpoint compromise. The argument against is that the AS metadata document at the same issuer URL is already TLS-only and adding a signing requirement here introduces asymmetry (metadata unsigned, binding signed). A future revision MAY mandate the JWS form for issuers that serve binding documents listing more than one organisation's domain, on the grounds that those issuers are the multi-tenant operators where forgery has the greatest blast radius. A.2. A.2 Per-tenant binding for shared issuer URLs The §6.1 reasoning presumes that multi-tenant Authorization Servers serve per-tenant issuer URLs. A future revision MAY define a binding form keyed by an in-token tenant identifier (e.g. an aud or azp value) so that a shared issuer URL can serve a single binding document mapping → . The trade-off is added complexity in Section 3 validation and risk of malformed bindings causing silent acceptance. A.3. A.3 Revocation This document does not define a binding-revocation mechanism beyond the exp field of the standalone form. A formally signed, short-lived document with auto-rotation is the lightweight model. A heavier model — pushing revocation via SSF/CAEP, akin to the lifecycle signalling defined in [I-D.canning-oauth-registration-lifecycle] — is conceivable but not required for the threat model in Section 6. A.4. A.4 Wildcard / public suffix detection The matching rules of Section 2.4 do not refuse overbroad wildcards (e.g. *.co.uk). A future revision MAY mandate that Relying Parties refuse bindings whose wildcard parent is in the Public Suffix List [PSL] §3, on the grounds that no single issuer can legitimately be authoritative for an entire public suffix. The implementation cost of consulting the PSL is non-trivial for some Relying Party platforms; this revision does not require it. A.5. A.5 Internationalised email domains Section 2.4 specifies IDNA2008 [RFC5891] comparison. Email address local-part internationalisation ([RFC6530]) is out of scope for this document; the matching rules apply to the domain part only. A future revision SHOULD confirm Relying Party normalisation expectations for internationalised domain labels in light of operator deployment evidence. A.6. A.6 Interaction with email vs. email_verified vs. other identifiers This document focuses on email/email_verified because that is where the auto-account-linking risk concentrates. Other claims that implicitly bind to a domain (preferred_username containing an @ form; tenant_id claims that align with a domain; SAML-style NameID-with- domain claims for OAuth-to-SAML bridges) are conceptually covered by the same logic but are not enumerated here. A future revision MAY enumerate. Appendix B. Acknowledgments This work was motivated by the zeroconf-sso prototype [ZEROCONF-SSO], whose threat model (docs/BRIEF.md) and gaps log [GAPS] identify the issuer-domain binding gap as the single most security-relevant unaddressed part of the email-domain SSO bootstrap flow. Comparison with Google's hd parameter [GOOGLE-HD] and OpenID Federation 1.0 [OIDF-FED] clarified what a lightweight binding needs to do and what it can leave to a heavier mechanism. Author's Address Simon Canning Canva Email: scanning@canva.com