Web Authorization Protocol F. Morin Internet-Draft FXCO Ltd. Intended status: Standards Track 16 December 2025 Expires: 19 June 2026 OAuth 2.1 Government Content Access Control draft-fx-oauth-government-content-access-control-00 Abstract This document defines an OAuth 2.1 profile that enables a government authority to enforce age-based and content-based access restrictions for online services while preserving user privacy. The protocol allows relying parties to request government-defined regulatory scopes (such as pornography or social media access) and receive cryptographically verifiable eligibility decisions without disclosing user identity, exact age, or personally identifiable information. The profile constrains OAuth features to prevent abuse, cross-service correlation, and unauthorized token issuance. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fx-oauth-government-content- access-control/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. 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." Morin Expires 19 June 2026 [Page 1] Internet-Draft OAuth 2.1 Government Content Access Cont December 2025 This Internet-Draft will expire on 19 June 2026. 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 5. Scope Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Government-Defined Scopes . . . . . . . . . . . . . . . . 4 5.2. Scope Evaluation Semantics . . . . . . . . . . . . . . . 4 6. Client Registration . . . . . . . . . . . . . . . . . . . . . 5 7. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Authorization Request . . . . . . . . . . . . . . . . . . 5 7.2. User Authentication and Evaluation . . . . . . . . . . . 5 7.3. Authorization Response . . . . . . . . . . . . . . . . . 5 7.4. Token Request and Response . . . . . . . . . . . . . . . 5 8. Token Derivation . . . . . . . . . . . . . . . . . . . . . . 5 9. Re-Verification . . . . . . . . . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 12.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Morin Expires 19 June 2026 [Page 2] Internet-Draft OAuth 2.1 Government Content Access Cont December 2025 1. Introduction Governments increasingly require online services to restrict access to certain categories of content based on the age or legal status of users. Existing approaches frequently rely on disclosure of personal data, third-party identity providers, or proprietary mechanisms that enable tracking across services. This document specifies *OAuth 2.1 Government Content Access Control (GCAC)*, an OAuth 2.1 profile in which a government-operated authorization server evaluates user eligibility for regulated content categories and issues privacy-preserving attestations to relying parties. GCAC is designed to answer narrowly scoped regulatory questions (e.g., whether a user may access a category of content) while minimizing data disclosure and preventing correlation across services. GCAC is not an identity system and MUST NOT be used for authentication, user login, or personalization. 2. Conventions and Definitions 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 additional terms are used: - *Government Content Control Authority (GCCA)*: - A government-operated OAuth Authorization Server responsible for identity verification, age evaluation, and policy enforcement. - *Relying Party (RP)*: - An OAuth client requesting eligibility decisions for regulated content. - *Scope*: - A government-defined content access category (e.g., pornography, social_media, gambling, alcohol, firearms, vpn, proxy). - *Person Key*: - A government-internal, pseudonymous identifier derived from a national identity record and never exposed outside the GCCA. - *Site Token*: - An RP-scoped, non-reversible token representing a government eligibility attestation. 3. Goals and Non-Goals Morin Expires 19 June 2026 [Page 3] Internet-Draft OAuth 2.1 Government Content Access Cont December 2025 3.1. Goals The goals of this specification are: - Enable government-enforced content access controls - Support multiple regulatory scopes defined by government policy - Prevent disclosure of identity, date of birth, or exact age - Prevent cross-RP correlation of users - Leverage existing OAuth 2.1 security mechanisms 3.2. Non-Goals This specification explicitly does not attempt to: - Provide user authentication or login - Expose personal attributes or identity claims - Enable cross-service user identification - Replace digital identity or credential systems 4. Architecture Overview GCCA uses the OAuth 2.1 Authorization Code flow with mandatory security extensions and additional semantic constraints. User → Relying Party → Government Content Control Authority ↑ ↓ └──── OAuth 2.1 ───────┘ The GCCA operates as a constrained OAuth Authorization Server, and the RP operates as a confidential OAuth client. 5. Scope Model 5.1. Government-Defined Scopes Scopes represent legally regulated content categories. Examples include: pornography social_media gambling alcohol firearms vpn proxy Each scope: - MUST be defined and governed by the GCCA - MUST correspond to a legal or regulatory access rule - MUST prevent scope definitions or combinations thereof that would allow an RP to infer a user’s exact age or approximate age range through multiple eligibility queries. Scopes MUST be coarse-grained and legally motivated, and MUST NOT be parameterized by numeric age values. 5.2. Scope Evaluation Semantics For each requested scope, the GCCA determines whether the user satisfies the applicable legal requirement. The RP receives only a boolean eligibility result per scope. Morin Expires 19 June 2026 [Page 4] Internet-Draft OAuth 2.1 Government Content Access Cont December 2025 6. Client Registration Relying parties MUST register with the GCCA prior to using GCAC. During registration, the RP MUST provide: - Legal entity identification - Intended use and justification for requested scopes - One or more redirect URIs - A client authentication method (mutual TLS or private_key_jwt) The GCCA MAY restrict which scopes an RP is authorized to request. 7. Protocol Flow 7.1. Authorization Request The RP initiates an OAuth authorization request: GET /authorize ?response_type=code &client_id=client_id &redirect_uri=registered_uri &scope=pornography social_media &state=random_nonce &code_challenge=pkce_value` The GCCA MUST reject requests that include unregistered redirect URIs or unauthorized scopes. 7.2. User Authentication and Evaluation The GCCA authenticates the user using government-controlled mechanisms and evaluates eligibility for each requested scope. 7.3. Authorization Response Upon successful evaluation, the GCCA redirects the user back to the RP with an authorization code. 7.4. Token Request and Response The RP exchanges the authorization code at the token endpoint using client authentication and PKCE. The GCCA responds with a site-scoped eligibility attestation: json { "site_token": "opaque_string", "scope_results": { "pornography": true, "social_media": false }, "expires_at": "timestamp" } 8. Token Derivation The GCCA MUST derive an internal person key as follows: Morin Expires 19 June 2026 [Page 5] Internet-Draft OAuth 2.1 Government Content Access Cont December 2025 person_key = HMAC(master_secret_key, national_person_id) The site token MUST be derived deterministically: site_token = HMAC(person_key, client_id) The person key and national identifiers MUST NOT be exposed outside the GCCA. 9. Re-Verification Relying parties MUST provide a user-accessible mechanism to re- initiate the GCAC flow. Re-verification MUST follow the same protocol as the initial authorization. 10. Security Considerations GCAC relies on OAuth 2.1 security best practices, including authorization code flow, PKCE, redirect URI allowlists, and strong client authentication. Leaked client identifiers alone do not enable token issuance. Tokens are RP-scoped and non-transferable, preventing cross-service correlation and replay attacks. 11. IANA Considerations This document has no IANA actions. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Morin Expires 19 June 2026 [Page 6] Internet-Draft OAuth 2.1 Government Content Access Cont December 2025 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . 12.2. Informative References [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, . Acknowledgments The author would like to acknowledge ongoing discussions within the OAuth and digital privacy communities that informed the design principles of this specification. Author's Address Francois-Xavier Morin FXCO Ltd. Morin Expires 19 June 2026 [Page 7]