apron-auth normalizes hosted-domain claims via TenancyContext.owns_email_domain, do not bake provider-specific claim names (Google hd, Microsoft tid) into schemas

apron-auth's IdentityProfile exposes tenancies: tuple[TenancyContext, ...] rather than per-provider claim fields. Each TenancyContext carries id, name, domain, raw, and a normalized owns_email_domain: bool flag set by the provider handler at fetch_identity time. Google's preset maps hd → TenancyContext(domain=hd, owns_email_domain=True) (see apron_auth/providers/google.py); Microsoft, Atlassian, Salesforce, Linear, and HubSpot populate tenancies from their own tenant claims. The consumer-facing helper IdentityProfile.domain_owning_tenancy() returns the first tenancy with owns_email_domain=True (or None). A consumer that adds a hosted_domain (or hd_claim) column keyed to Google specifics locks itself out of Microsoft/Workspace-style tenancy capture without a schema change, and bypasses the library's normalization layer. Verified against apron-auth as installed in a downstream consumer, 2026-05; the contract is documented inline in apron_auth/models.py on TenancyContext and IdentityProfile. Single observation from one consumer codebase, verify the abstraction is still present in the version you depend on before relying on it.

When persisting or gating on tenant-asserted identity in an apron-auth consumer, call IdentityProfile.domain_owning_tenancy() and store the returned TenancyContext.domain (nullable). Do not name columns or call sites after Google's hd claim or any other provider-specific identifier, tenancy_domain (or similar provider-neutral name) is the right shape. Before relying on this, verify the current contract by reading TenancyContext and IdentityProfile.domain_owning_tenancy in apron_auth/models.py of the version you have installed; check that the provider handler you care about (e.g. apron_auth/providers/google.py) sets owns_email_domain=True on the relevant tenancy.