Federated Authentication for the Registration Data Access Protocol (RDAP) Using OpenID Connect
Extracted elements (29)
The specification supports two distinct client types (session-oriented and token-oriented) because different deployment contexts have different needs: web browsers naturally use cookie-based sessions, while headless scripts and CLI tools work better with direct OAuth token flows. Defining both allows the protocol to cover a broad range of RDAP client implementations without forcing a single authentication model.
Username/password authentication does not scale in the RDAP ecosystem because it requires users to maintain credentials with hundreds of different registry operators and does not provide sufficient identity detail for fine-grained access control. Federated authentication via OpenID Connect allows clients to reuse a single credential across multiple RDAP servers while enabling richer identity claims.
The OpenID Connect Discovery protocol [OIDCD] is OPTIONAL and not widely implemented, so RDAP servers acting as RPs may use out-of-band methods or maintain internal OP associations instead. Servers SHOULD support explicit OP specification via the farv1_iss query parameter as a fallback when discovery is unavailable.
A token-oriented RDAP client MUST include the 'farv1_iss' query parameter and Issuer Identifier with an RDAP query if the token was issued by a remote OP. The server MUST validate a received access token prior to using it for access control; validation MAY include token introspection (RFC 7662) or JWT analysis.
After receiving the farv1_session/device response, the client MUST send a farv1_session/devicepoll request. This request MUST include the farv1_dc query parameter carrying the device_code from the device response, and MUST include an end-user identifier or OP Issuer Identifier if the server supports only remote OPs.
An RDAP server MUST maintain session state for the duration of an active session. In the absence of a logout request, the session MUST be terminated after a server-defined timeout. The server SHOULD invalidate the HTTP cookie and SHOULD revoke tokens or log out from the OP on session termination.
An RDAP server MUST provide information about its capabilities and supported OPs in the 'help' query response in the 'farv1_openidcConfiguration' data structure, and MUST support at least one method of OP discovery. The server MUST set either 'sessionClientSupported' or 'tokenClientSupported' to true.
Clients MAY operate as either session-oriented or token-oriented, but MUST do so consistently without mixing token-oriented and session-oriented requests while interacting with an OP. Servers SHOULD support both types to maximize interoperability but MAY restrict to one type per local policy.
If 'implicitTokenRefreshSupported' is false, the client MUST explicitly refresh the session using farv1_session/refresh; if that fails, the client MUST establish a new session via farv1_session/login. If the OP does not support refresh tokens, the client MUST submit a new login request once the access token expires.
Once the OP is known, the RP MUST form an Authentication Request per Section 3 of OIDCC. The OAuth 2.0 Implicit Flow is considered insecure and MUST NOT be used; the authorization code flow (response_type=code) is the assumed path.
RDAP responses that contain values defined in this specification MUST indicate conformance by including 'farv1' in the rdapConformance array. An RDAP server MUST determine during an authenticated query whether the end user is authorized to perform the query and MAY reject or redact responses based on the user's authorization level.
RDAP servers MUST reject queries with identification information from an unsupported OP by returning HTTP 400 (Bad Request). When identification information from a recognized OP is present, the server MUST perform user authentication with the OP, process the query, and return a response appropriate to the user's authorization level.
Server operators MUST NOT log, track, or record any association of the query and the end user's identity if the end user is successfully identified and authorized, if 'rdap_dnt_allowed' is present with value true, and if accepting the claim complies with local regulations regarding logging and tracking.
The login response MUST be a valid RDAP response per RFC 9083 and MUST NOT include members relating to a specific RDAP object type. On success it MUST include a 'farv1_session' with a 'sessionInfo' object; on failure it MUST include a 'farv1_session' omitting userClaims and sessionInfo.
The server MUST return HTTP 403 (Forbidden) if the requested 'farv1_qp' purpose is not in the end user's allowed purposes. The server MUST return HTTP 403 if it is unable to perform the action requested by 'farv1_dnt'. Unrecognized query parameters MUST be ignored.
When a session-oriented client receives a session cookie, it MUST include that cookie in all subsequent RDAP requests within the session scope, including refresh, status, and logout requests. A second login request without a cookie MUST start a new session; a second login that includes a cookie MUST receive HTTP 409 (Conflict).
The userClaims returned in farv1_session responses can include personally identifiable information (name, email, picture, etc.). The 'rdap_dnt_allowed' do-not-track claim relies on the good will of the RDAP server and associated proxies; misuse or acceptance of the claim risks information loss that could seriously impair audit capabilities.
The 'farv1_deviceInfo' data structure contains the fields defined in RFC 8628 Section 3.2 (device_code, user_code, verification_uri, verification_uri_complete, expires_in, interval) to support OAuth 2.0 Device Authorization Grant for clients with constrained user interfaces.
The 'farv1_openidcConfiguration' data structure is returned in RDAP 'help' query responses and describes the server's OpenID Connect capabilities, including boolean flags for sessionClientSupported, tokenClientSupported, dntSupported, providerDiscoverySupported, issuerIdentifierSupported, and implicitTokenRefreshSupported, plus an optional list of supported OPs.
The 'farv1_session' data structure contains optional members userID, iss, userClaims (the set of OIDC claims from the OP), and sessionInfo (an object with tokenExpiration integer and tokenRefresh boolean). It is returned in login, status, and refresh responses.
The 'rdap_allowed_purposes' JWT claim is an array of case-sensitive StringOrURI values that identifies the purposes for which an end user is authorized to access a protected RDAP resource. Identity providers MUST ensure purpose values are only assigned to identities authorized to use them; unrecognized values MUST be ignored.
The 'rdap_dnt_allowed' JWT claim is a JSON boolean that, when true, indicates the end user is authorized to perform queries without having their identity associated with those queries logged, tracked, or recorded by the server. Servers MUST NOT log the association when this claim is present, true, the user is authenticated, and accepting the claim complies with local regulations.
Token exchange (RFC 8693) is available when the RP receives an access token whose 'aud' claim does not include the RP's client_id — for example when the client is acting as a proxy. The RP may exchange the token with the OP to obtain a new token with a corrected 'aud' claim.
Two client types are defined: 'session-oriented' clients that delegate OIDC authentication to the RDAP server and use HTTP cookies to maintain session state, and 'token-oriented' clients that perform OIDC authentication directly as an RP and send access tokens in HTTP Authorization headers.
Two RDAP query parameters are defined: 'farv1_qp' carries a single query purpose string from the user's allowed purposes, and 'farv1_dnt' carries a boolean requesting that the server not log or record identity information associated with the query. Both are OPTIONAL and appended to RDAP request URIs using application/x-www-form-urlencoded syntax.
IANA created the 'Registration Data Access Protocol (RDAP) Query Purpose Values' registry under the Specification Required policy. Initial values include: domainNameControl, personalDataProtection, technicalIssueResolution, domainNameCertification, individualInternetUse, businessDomainNamePurchaseOrSale, academicPublicInterestDNSResearch, legalActions, regulatoryAndContractEnforcement, criminalInvestigationAndDNSAbuseMitigation, and dnsTransparency.
IANA registered the 'farv1' extension identifier in the RDAP Extensions Registry (registry operator: Any; specification: RFC 9560) and two new claims in the JSON Web Token Claims Registry: 'rdap_allowed_purposes' (array of allowed RDAP query purposes) and 'rdap_dnt_allowed' (boolean do-not-track flag).
The OAuth 2.0 Implicit Flow is considered insecure and MUST NOT be used. TLS practices per RFC 9325 MUST be followed. RDAP server operators must develop policies to ensure that personally identifiable information in userClaims is disclosed only to authorized clients.
Session lifecycle for session-oriented clients: (1) ACTIVE — entered via farv1_session/login or farv1_session/devicepoll; transitions to ACTIVE via farv1_session/refresh; (2) NO SESSION — entered via farv1_session/logout or server timeout; requests to status/refresh/logout in this state MUST return HTTP 409; requests with an expired session cookie MUST return HTTP 401.