Summary

  • RFC 9560 lets RDAP servers use OpenID Connect and OAuth to identify users and validate bearer tokens without maintaining a separate credential at every server.
  • The optional purpose and do-not-track claims remain inputs to server policy. They do not prove a user's motive, a query's entitlement, universal non-logging or the quality of returned registry data.
  • A defensible access record must join token validation to the policy version, query purpose, field-level disclosure, source-record provenance and later investigative outcome.

The bearer token passes validation. That is a real achievement: the issuer, audience, expiry and token structure have supplied enough evidence for the RDAP server to continue. It is also the moment at which language becomes dangerous. “Authenticated user” can quietly turn into “authorized query,” then “legitimate purpose,” then “trustworthy answer.” RFC 9560 does not make those substitutions.

Published on the IETF Standards Track in April 2024, RFC 9560 brings federated authentication to the Registration Data Access Protocol. An RDAP client can discover supported OpenID Providers, use a session-oriented or token-oriented flow, and present identity information without creating an account at every RDAP service. The shared mechanism is useful precisely because authorization remains local.

Authentication closes one question

For token-oriented access, the server must validate a bearer token under local policy and confirm that it is a legitimate access token. It may introspect the token under RFC 7662 or analyse a JWT. Audience matters: a token issued for another relying party may not be trusted, although RFC 8693 token exchange can produce a token with a suitable audience.

These steps answer whether the server is prepared to rely on a credential in this interaction. They do not decide what every identity may see. After validation, the server evaluates claims and determines an authorization level under its own policy. During an active session it must still decide whether the user may perform each query, and may reject the request, omit fields or redact information.

Purpose is an assigned privilege, not a window into motive

RFC 9560 defines the optional rdap_allowed_purposes claim. An identity provider assigns purpose values only to identities authorized to use them. A client can state the purpose of a particular query in farv1_qp; the server should compare that value with the allowed set and must return 403 when the requested purpose is not permitted.

The discipline is valuable, but its evidentiary scope is narrow. The claim says that an identity has been granted a category of use. It cannot observe why a human typed this query, whether later use stays inside the declaration or whether a broad purpose label was assigned too generously. The server may also ignore purpose data when they conflict with local policy. If no purpose parameter is supplied, it must still make an access decision using other information.

The distinction is not scepticism about identity. It is ordinary control design. A building pass may identify an employee and open one door; it does not prove why the employee entered, which file was needed or how the information was later used.

Do-not-track trades one form of assurance for another

The optional rdap_dnt_allowed claim can authorize a query without recording the association between the user's identity and that query. Acceptance depends on identification, authorization, a true claim and compliance with local logging rules. The RFC is unusually candid about the boundary: do-not-track relies on the good will of the RDAP server and proxies, requires out-of-band trust and can impair audit capability through information loss.

That is not a contradiction. Some investigations need query confidentiality. The governance question is who grants the privilege, which intermediaries are covered, what evidence remains, and how misuse can be examined without reconstructing the protected query trail. “Do not track accepted” is a policy event, not cryptographic proof that no system anywhere retained an association.

The answer has its own evidence burden

farv1 in an RDAP response announces conformance with this extension. It does not certify the underlying registration record. A technically correct response may be a policy-limited subset. The source record may have its own update time, verification method, correction history and unresolved ambiguity. HTTP 200 proves neither completeness nor usefulness; HTTP 403 proves neither bad faith nor wrongdoing.

The minimum common layer should standardize discovery, token handling, claim names and query parameters. It should not pretend to standardize every lawful purpose, disclosure threshold or investigation outcome. Heng Lu's reality-layer argument supplies the sharper test: identity, token, purpose privilege, authorization decision, disclosed record and real-world result are all real, but none may borrow the authority of the next.