]> FXCO Ltd.

fx@fxco.ca

OAuth Working Group OAuth Government child safety 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. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OAuth Working Group Working Group mailing list (mailto:standard@fxco.ca), which is archived at Source for this draft and an issue tracker can be found at

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.

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

Goals and Non-Goals

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

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

Architecture Overview GCCA uses the OAuth 2.1 Authorization Code flow with mandatory security extensions and additional semantic constraints.

GCCA Code Flow

The GCCA operates as a constrained OAuth Authorization Server, and the RP operates as a confidential OAuth client.

Scope Model

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.

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.

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.

Protocol Flow

Authorization Request The RP initiates an OAuth authorization request:

Example: GCCA request

The GCCA MUST reject requests that include unregistered redirect URIs or unauthorized scopes.

User Authentication and Evaluation The GCCA authenticates the user using government-controlled mechanisms and evaluates eligibility for each requested scope.

Authorization Response Upon successful evaluation, the GCCA redirects the user back to the RP with an authorization code.

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:

Example: GCCA Response

Token Derivation The GCCA MUST derive an internal person key as follows:

Person Key Pseudocode

The site token MUST be derived deterministically:

Site Token Pseudocode

The person key and national identifiers MUST NOT be exposed outside the GCCA.

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.

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.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Informative References This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

Acknowledgments The author would like to acknowledge ongoing discussions within the OAuth and digital privacy communities that informed the design principles of this specification.