]> FXCO Ltd.

CA fx@fxco.ca https://fxco.ca/

OAuth Working Group OAuth Government child safety age restriction 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. 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 Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in & .

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.

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

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

This specification explicitly does not attempt to: Provide user authentication or login services to RPs Expose personal attributes or identity claims (e.g., OIDC claims) Enable cross-service user identification Replace digital identity or credential systems

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

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

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.

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.

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.

The RP initiates an OAuth authorization request:

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

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

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

The RP exchanges the authorization code at the token endpoint using client authentication and PKCE . The GCCA responds with a site-scoped eligibility attestation as a standard OAuth 2.1 token response, including additional custom parameters:

The "access_token" field contains the site token, which is an RP-scoped, non-reversible eligibility attestation.

The GCCA MUST derive an internal person key using HMAC-SHA256 with a globally unique master secret key (master_secret_key) and a stable, unique national identifier for the person (national_person_id):

The site token MUST be derived deterministically using HMAC-SHA256 from the person key (person_key) and the client identifier (client_id):

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

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.

GCAC relies on OAuth 2.1 security best practices, including authorization code flow, PKCE , redirect URI allowlists, and strong client authentication. General security considerations for OAuth 2.0 also apply. To further protect the integrity and confidentiality of authorization requests, RPs SHOULD use JWT-Secured Authorization Request (JAR) . Leaked client identifiers alone do not enable token issuance. Tokens are RP-scoped and non-transferable, preventing cross-service correlation and replay attacks.

This document has no IANA actions.

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

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