Internet-Draft M. Fulz Intended status: Standards Track Independent Expires: May 31, 2026 November 27, 2025 OAuth Trust Binding Extension (OTBE) draft-fulz-oauth-trust-binding-00 Abstract This document defines the OAuth Trust Binding Extension (OTBE), a mechanism allowing Resource Owners to explicitly authorize which Authorization Servers may assert their identity towards Relying Parties, mitigating silent impersonation and namespace-based identity capture. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2025 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. RFC 2119 / RFC 8174 Language 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 RFC 2119 and RFC 8174 when, and only when, they appear in all capitals. 1. Introduction OAuth 2.0 and OpenID Connect are widely deployed for delegated authorization and federated identity. A fundamental, often implicit assumption is that the Authorization Server (AS) and the Resource Owner (RO) share an established trust relationship before any authorization request is made. In practice, the current ecosystem assigns implicit trust based solely on possession of an identifier, typically an email address. This creates critical vulnerabilities where: * any Authorization Server hosting an identity namespace (e.g., *@gmail.com*) can impersonate users who never created an account with that AS; * Relying Parties (clients) accept identities without any ability to verify whether the RO intentionally approved OAuth-based login for that AS; * large IdPs (Google, Facebook) gain unilateral access to potentially all RP accounts linked by email identifiers alone. This document introduces the OAuth Trust Binding Extension (OTBE), a mechanism enabling explicit user-controlled trust binding between an identity namespace and an Authorization Server. 2. Problem Statement Current OAuth deployments allow the AS to assert identity ownership solely on the basis of email-domain control. This leads to: 2.1. Silent Impersonation Risk A user who owns "user@example.com" may have no account at Google, but if an RP accepts "Sign in with Google", Google can legitimately assert that identity, creating: * account takeover potential, * unobservable impersonation, * unilateral trust decisions by third parties. 2.2. No User-Driven Consent to Provider-Level Trust There is currently no mechanism for a user to declare: "I trust AS X to authenticate me for RP Y (or globally)." Instead, trust is assumed, not expressed. 2.3. Centralization and Surveillance Risks This implicit trust model enables concentrated identity control in dominant AS entities. Under legal compulsion, such providers could impersonate users across the entire ecosystem. 2.4. Namespace Capture Email domain providers become de facto identity authorities even when users have no intention of delegating authentication to them. OTBE resolves these issues by introducing explicit Trust Binding Records controlled by the Resource Owner. 3. Terminology AS Authorization Server. RO Resource Owner (end-user). RP Relying Party (Client). Trust Binding (TB) A cryptographic or secret-binding record that authorizes a particular AS to authenticate the RO's identifier. TB-Record The stored representation of a Trust Binding at an RP. 4. Protocol Overview OTBE extends OAuth as follows: 1. Before an RP accepts a login from an AS for identifier "user@example.com", it MUST verify that a Trust Binding exists. 2. Trust Bindings are simple key-value artifacts: * either user-generated secrets, * or AS-provided cryptographic attestations. 3. Trust Bindings are created by the user, either: * manually (copy/paste token), * during an enrollment flow, * or via a federated mechanism provided by the identity namespace owner. 4. Without a valid Trust Binding, authentication MUST fail. 5. Trust-Binding Registration 5.1. Creating a Trust Binding An RO creates a random secret or receives a cryptographic token from the AS. Examples: TB-Token = base64url(random(256 bits)) 5.2. Binding the Token to the RP The RO stores the TB-Token at the RP during a special "Enable External Login" step: 1. RO authenticates with the RP using primary credentials. 2. RO selects "Enable login with AS X". 3. RP displays a TB-Token (or asks RO to paste one). 4. RP stores: { identifier, AS, TB-Token }. 6. Authorization Flow Modifications During OAuth login: 1. AS sends authorization assertion to RP. 2. RP extracts RO identifier and AS identity. 3. RP retrieves the stored TB-Token. 4. RP computes verification: * If AS supplies a signed TB-Token, RP validates the signature. * If AS only supplies identifier, AS must also echo the TB-Token (via standard or extension claim). 5. If no valid TB-Token is presented, RP returns an error such as: error = "trust_binding_missing" 7. Security Considerations * Prevents silent impersonation by AS. * Reduces impact of AS compromise. * Prevents surveillance-based identity impersonation. * Ensures user agency in RP–AS trust relationships. * TB failure forces RP to reject unexpected logins. 8. Privacy Considerations * OTBE eliminates automatic identity leakage to AS because RPs will no longer accept unsolicited authentication attempts. * TB-Tokens must be stored securely and treated as secrets. 9. Backward Compatibility * RPs may operate in compatibility mode where legacy logins still function. * Deployment SHOULD prefer a "progressive enforcement" model. 10. Deployment Considerations * Can be implemented without changes to OAuth core specifications. * AS vendors may gradually adopt TB-token signing for stronger assurances. * RPs must update user-account-management UIs to allow TB setup. 11. IANA Considerations This draft requests registration of: * "trust_binding_token" — OAuth extension claim. * "trust_binding_required" — OAuth error code. 12. Appendix A — Examples 12.1. Example TB-Record { "subject": "user@example.com", "as": "https://accounts.example-idp.com", "tb": "zY9sD2..." } 13. Appendix B — Threat Model 13.1. Addressed threats * AS-driven impersonation. * Government-compelled impersonation. * Namespace hijacking. * Centralized identity coercion. 13.2. Out of scope * Phishing. * RP credentials compromise. Authors' Addresses Matthias Fulz Independent Ingolstadt Germany Email: mfulz@olznet.de