SIDN Labs

maarten.wullink@sidn.nl https://sidn.nl/

DENIC

pawel.kowalik@denic.de https://denic.de/

Internet Network Working Group This document describes how OAuth 2.0 can be used to secure object transfers in RESTful Provisioning Protocol (RPP) . It extends the RPP OAuth 2.0 authorization model defined in with mechanisms specific to federated object transfers.

Introduction NOTE: This is an early draft of how object transfer could work in RPP. It is included to illustrate the transfer flow and to facilitate discussion of the flow details and applicable security mechanisms. This document is expected to be significantly revised and updated as the transfer flow and security mechanisms are further developed and refined. This document extends the core functionality of RPP with a secure mechanism for transferring objects between registrars. It is based on the OAuth 2.0 federation model, where the registry acts as a central trust anchor and the losing registrar's authorization server (AS) issues tokens that the registry can validate locally to authorize transfers. This provides a secure, scalable, and user-friendly mechanism for authorizing transfers without exposing sensitive information in transfer requests or responses. It also prevents the use of opaque transfer tokens and their inherent security risks, such as token leakage or replay attacks. This document introduces new data objects, scopes and claims specific to the transfer flow. It defines two complementary transfer mechanisms: an interactive flow based on OAuth 2.0 federation for secure transfers with explicit registrant consent, and a fallback flow using opaque transfer tokens for transfers where interactive consent is not possible. The document also defines the trust model and security properties of the transfer mechanism.

Terminology In this document the following terminology is used. RPP server - An HTTP server responsible for processing requests and returning results in any supported media type. JWT - JSON Web Token as defined in .

Conventions Used in This Document 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 . In examples, indentation and white space are provided only to illustrate element relationships and are not REQUIRED features of the protocol. All example requests assume an RPP server using HTTP version 2 is listening on the standard HTTPS port on host rpp.example. An authorization token has been provided by an out-of-band process and MUST be used by the client to authenticate each request.

Object Transfer Details In RPP, Object Transfer Details as described in are used for interactive federated object transfers to convey the specific domain name or contact handle being transferred. The gaining registrar includes an authorization_details object of type rpp_transfer in the authorization request to the losing registrar's AS. The registrant then sees exactly which object they are consenting to transfer. The AS MUST echo the authorization_details object back as a claim in the issued access token, giving the registry verifiable, tamper-proof evidence of what was authorized and for which object. The type field MUST be set to rpp_transfer. Table lists the RAR fields defined for RPP. RPP Transfer Authorization, RAR authorization_details object (Primary Method, )

Field	Type	Requirement	Description
type	String	REQUIRED	MUST be transfer.
object_type	String	REQUIRED	The RPP object type being transferred. MUST be one of domain or contact.
object_identifier	String	REQUIRED	The unique identifier of the specific object to be transferred (e.g., foo.example or CID-12345).

Example RAR authorization_details value for a domain transfer: The losing registrar's AS MUST echo the authorization_details back as a claim in the issued JWT. The registry MUST validate the authorization_details claim in the token and MUST verify that object_type and object_identifier match the object being transferred. When the losing registrar's AS does not support RAR (), the specific object being transferred MUST be conveyed via the rpp_op_type, rpp_object_type and rpp_object_identifier claims rather than encoded in the authorization_details claim. The rpp_op_type claim MUST be set to transfer. The rpp_object_type claim MUST be set to the RPP object type being transferred (e.g., domain or contact). The rpp_object_identifier claim MUST be set to the fully qualified name or handle of the specific object being transferred (e.g., foo.example or CID-12345). The registry MUST validate that these claim values match the object being transferred.

Scopes RPP OAuth 2.0 scopes are defined in . This document does not define new scopes; the existing transfer access level scope (e.g., domain:transfer) defined in MUST be used for transfer operations.

Claims In addition to the standard claims, table lists the RPP-specific claims that are defined to enable fine-grained authorization decisions. Required claims MUST be present in every RPP access token. Optional claims SHOULD be included when applicable to the deployment or request context. RPP Specific Access Token Claims

Claim	Requirement	Type	Description
rpp_transfer_authinfo	OPTIONAL	String	The transfer authorization information used in Fallback flow object transfer. When present, the value MUST be equivalent to the value that would otherwise be sent in the RPP-Authorization header , using the same <method> <authorization information> format. The RPP server MUST treat this claim as equivalent to the RPP-Authorization header; if both are present in the same request, the claim value MUST take precedence. This claim MUST only be present in access tokens used for transfer operations.

Data Objects The RPP Data Object Catalog is extended to include each registrar's AS metadata.

• Auth Server Metadata Object: This describes an authorization_server object for each registrar that operates its own AS. This object contains the necessary metadata for the gaining registrar to interact with the losing registrar's AS, including the authorization endpoint URI and JWKS URI or public key material.

Trust Model The Secure Transfer depends on the OAuth 2.0 federation model, where the registry acts as the central trust anchor, operating as a hub-and-spoke topology. Registrars establish a trust relationship with the registry during accreditation; they do not need to establish direct trust relationships with each other. This allows any two registrars to participate in a Secure Transfer without any prior bilateral arrangement. Registry as trust anchor. As part of registrar onboarding, each registrar that operates its own AS (i.e., maintains registrant accounts) MUST register its AS metadata with the registry. This includes at minimum:

• The AS's authorization endpoint URI, used by the gaining registrar to construct the redirect.
• The AS's JWKS endpoint URI or the public key material itself, used by the registry to validate tokens issued by that AS.

The registry stores this metadata as part of the registrar's profile and makes it available via the discovery mechanism. Token validation without bilateral trust. When the registry receives a transfer request carrying a JWT issued by the losing registrar's AS, it validates the token locally using the losing registrar's public key that was registered at onboarding. No runtime call to the losing registrar or its AS is required. The registry already trusts that public key because it was registered through the accreditation process. Gaining registrar. The gaining registrar only needs to trust the registry. It obtains the losing registrar's AS URI from the registry's discovery endpoint, redirects the registrant's browser there, and exchanges the resulting authorization code for a token. It does not need to pre-configure or authenticate the losing registrar. The browser redirect and back-channel token exchange are both secured by standard HTTPS and do not require a federated identity relationship between the two registrars. Security properties. This model provides the following guarantees:

• No need for pre-established bilateral trust between registrars. Any two registrars can participate in a secure transfer as long as they both trust the registry.
• The traditional transfer token is replaced with a signed JWT access token that the registry can validate locally, eliminating the risks of token leakage or replay attacks.
• A rogue registrar cannot forge a transfer token that the registry will accept, because only the legitimate losing registrar's public key (registered at onboarding) can produce a valid signature.
• The gaining registrar cannot forge registrant consent, because the token is issued by the losing registrar's AS, not the gaining registrar.
• The registry controls the set of trusted ASs by controlling which registrar IdP metadata it accepts at onboarding.
• Registrars need no knowledge of each other beyond what the registry exposes via the discovery endpoint.

Object Transfer Flows The server MAY support a secure object transfer mechanism based on OAuth 2.0 federation for secure object transfer between registrars, the gaining registrar can obtain an access token from the losing registrar's AS to authorize the transfer request. This provides a secure mechanism for transferring objects without exposing sensitive information in the transfer request or response messages. This also prevents the use of opaque transfer tokens and their inherent security risks, such as token leakage or replay attacks. If any of the parties in the transfer flow does not support the secure transfer mechanism based on OAuth 2.0 federation, then the transfer MUST fall back to the Fallback flow transfer mechanism using opaque transfer tokens, using the RPP-Authorization header to include the transfer token in the transfer request messages. The two transfer mechanisms cover complementary scenarios:

• Interactive flow (OAuth 2.0 federated): The current registrant has an account at the losing registrar and actively initiates or approves the transfer themselves — for example, a registrant migrating their own domain to a new registrar. The registrant authenticates at the losing registrar's AS and grants explicit, object-scoped consent.
• Fallback flow (authinfo): The losing registrar has not registered an AS URI with the registry, or the domain has been sold and the new owner has no account at the losing registrar. In this case interactive consent at the losing registrar is not possible. The seller (the previous owner, who does have an account at the losing registrar) obtains a transfer authorization code (authinfo) out-of-band and passes it to the buyer. The buyer provides the authinfo to the gaining registrar, which includes it in the transfer request via the RPP-Authorization header or the rpp_transfer_authinfo JWT claim. The registry validates the authinfo and executes the transfer without requiring the new owner to have any account at the losing registrar.

Flow selection is not at the discretion of the gaining registrar. The gaining registrar MUST use whichever flow the losing registrar's capabilities dictate, as determined by registry discovery. Specifically:

• If the registry's discovery endpoint returns an AS URI for the losing registrar, the gaining registrar MUST use the interactive OAuth 2.0 federated flow. Fallback flow MUST NOT be used as a substitute, even if it would be simpler to implement. The only exception is if the new owner is a different party than the previous owner (e.g., the domain was sold), in which case the gaining registrar MUST use Fallback flow because the new owner cannot authenticate to the losing registrar's AS to give consent.
• If the registry's discovery endpoint returns no AS URI for the losing registrar, the gaining registrar MUST use Fallback flow.

The registry MUST enforce this: if a Fallback flow transfer request (i.e., a request carrying an RPP-Authorization header or rpp_transfer_authinfo claim) is received for an object whose losing registrar has a registered AS URI, the registry MUST reject the request with an appropriate error response. This prevents downgrade attacks and ensures that registrars cannot bypass the stronger OAuth 2.0 flow for operational convenience once they have declared support for it. Token single-use enforcement. Access tokens issued by the losing registrar's AS for use in the interactive federated transfer flow MUST be single-use. The registry MUST reject any transfer request that presents a token that has already been used to authorize a transfer, even if the token has not yet expired. The losing registrar's AS MUST issue tokens with the intent of single use, and SHOULD include a unique jti (JWT ID) claim in each token to facilitate replay detection. The registry MUST maintain a short-lived cache of observed jti values and MUST reject any token whose jti has already been seen. If the registry cannot enforce single-use semantics (e.g., due to lack of shared state in a distributed deployment), the token lifetime MUST be set as short as operationally feasible, on the order of a few seconds, to minimize the window of opportunity for replay attacks. Token lifetimes for interactive transfer tokens MUST NOT exceed 60 seconds. For the secure transfer mechanism based on OAuth 2.0 federation, the RPP server requires an established trust relationship with the AS of the losing registrar. The server MUST support the necessary mechanisms for validating tokens issued by the losing registrar's AS. This requires the server to support the JWT profile for OAuth 2.0 Access Tokens and to support the necessary mechanisms for validating tokens issued by external ASs. The client MUST include a valid access token in the Authorization header of the transfer request, and the server MUST validate the token and the associated permissions before allowing the transfer to proceed. The server MUST also implement appropriate error handling for cases where the token is invalid, expired, or does not have the necessary permissions for the requested transfer operation. Registrars implementing secure transfer mechanisms based on OAuth 2.0 federation MUST support the federated identity provider function.

Interactive Flow The interactive flow uses the OAuth 2.0 Authorization Code grant to obtain explicit, object-specific registrant consent directly from the losing registrar's AS. Before redirecting the registrant, the gaining registrar MUST first query the RPP authorization server metadata endpoint to resolve the losing registrar's AS authorization URI. If no AS URI is available for the losing registrar, the gaining registrar MUST fall back to the Fallback flow described in . The authorization request MUST convey the specific object being transferred so that the losing registrar's AS can present the registrant with an accurate consent screen. The primary method is Rich Authorization Requests (RAR) as described in . When the losing registrar's AS does not support RAR, the fallback method is to include the object identifier in the rpp_object_id claim. The following diagram illustrates a successful interactive OAuth 2.0 federated secure object transfer, where both gaining and losing registrars support RAR and the registrant authenticates to the losing registrar to approve the transfer:

OAuth 2.0 Federated Secure Object Transfer - Interactive Flow | | | | | | | | | 2. Lookup | | | | losing reg | | | | AS URI | | | +-------------->| | | | | | | | 3. Return | | | | losing reg | | | | AS URI | | | |<--------------| | | | | | | 4. Redirect | | | | to Losing Reg| | | | AS (RAR: | | | | authz_details| | | | type=rpp_ | | | | transfer, | | | | id= | | | foo.example)| | | | | | | |<--------------| | | | | | | | 5. Auth & | | | | approve | | | | transfer at | | | | Losing Reg | | | | AS | | | +---------------------------------------------->| | | | | | 6. Auth code | | | | + redirect to| | | | Gaining Reg | | | | callback URI | | | |<----------------------------------------------| | | | | | 7. Follow | | | | redirect | | | | (auth code | | | | delivered) | | | +-------------->| | | | | | | | | 8. Exchange | | | | auth code for| | | | access token | | | +------------------------------>| | | | | | | 9. JWT token | | | | (authz_ | | | | details= | | | | {type:rpp_ | | | | transfer, | | | | id= | | | | foo.example) | | | | | | | |<------------------------------| | | | | | | 10. Transfer | | | | request + | | | | Bearer token | | | +-------------->| | | | | | | | | 11. Local JWT | | | | validation | | | | (losing reg | | | | AS pubkey, | | | | verify scope)| | | | | | | | 12. Execute | | | | transfer & | | | | notify Losing| | | | Registrar | | | +-------------->| | | | | | | 13. Transfer | | | | successful | | | |<--------------| | | | | | | 14. Transfer | | | | confirmed | | | |<--------------| | | | | | | ]]>

The steps in the diagram are as follows:

1. The client initiates a transfer request to the gaining registrar, specifying the object to transfer (e.g., foo.example).
2. The gaining registrar queries the registry's registrar discovery endpoint to look up the losing registrar's AS authorization URI. The losing registrar is identified from the current sponsoring registrar data on the domain.
3. The registry returns the losing registrar's AS authorization URI. If no URI is registered, the gaining registrar MUST fall back to the Fallback flow.
4. The gaining registrar redirects the client's browser to the losing registrar's AS. The authorization request MUST include an authorization_details parameter of type rpp_transfer with object_type: "domain" and object_identifier: "foo.example".
5. The client authenticates at the losing registrar's AS and explicitly approves the transfer scope, providing direct, verifiable consent to release the specific object.
6. The losing registrar's AS issues an authorization code and redirects the client's browser back to the gaining registrar's registered callback URI.
7. The client's browser follows the redirect, delivering the authorization code to the gaining registrar's callback endpoint.
8. The gaining registrar exchanges the authorization code for an access token at the losing registrar's AS token endpoint.
9. The losing registrar's AS validates the code and issues a signed JWT access token (). When RAR was used, the token MUST contain an authorization_details claim echoing the rpp_transfer object.
10. The gaining registrar submits the transfer request to the registry, including the JWT as a Bearer token in the Authorization header.
11. The registry validates the JWT locally using the losing registrar's AS public key (obtained via OAuth 2.0 AS Metadata ). No live call to the losing registrar is required. The registry MUST verify the transfer authorization using the appropriate method: if the token contains an authorization_details claim (RAR), the registry MUST verify that the type is rpp_transfer and that object_identifier matches the object being transferred.
12. The registry executes the transfer and notifies the losing registrar.
13. The registry returns a successful transfer response to the gaining registrar.
14. The gaining registrar confirms the completed transfer to the client.

Fallback Flow The Fallback flow uses opaque transfer authorization tokens to authorize object transfers between registrars. The gaining registrar obtains the transfer authorization token out-of-band from the losing registrar (e.g., via the registrant or a prior registrar-to-registrar agreement) and includes it in the transfer request. No OAuth 2.0 federation or end-user interaction is required. The registry validates the opaque token against the losing registrar's records to authorize the transfer. The transfer authorization token MUST be conveyed using the rpp_transfer_authinfo claim embedded in a JWT access token. The following diagram illustrates the machine-to-machine Fallback flow for a secure object transfer:

Fallback Object Transfer - Machine to Machine flow | | | | | | | | | 2. Transfer | | | | request | | | | (RPP-Authori-| | | | zation: | | | | ) | | | +-------------->| | | | | | | | | 3. Validate | | | | authz token | | | | | | | | 4. Execute | | | | transfer & | | | | notify Losing| | | | Registrar | | | +-------------->| | | | | | | 5. Transfer | | | | successful | | | |<--------------| | | | | | | 6. Transfer | | | | confirmed | | | |<--------------| | | | | | | ]]>

The steps in the diagram are as follows:

1. The client initiates a transfer request to the gaining registrar, providing the transfer authorization token that was obtained out-of-band from the losing registrar (e.g., via the registrant or a prior registrar-to-registrar agreement).
2. The gaining registrar submits the transfer request to the registry, including the opaque authorization token in the RPP-Authorization header.
3. The registry validates the authorization token against the losing registrar's records.
4. The registry executes the transfer and notifies the losing registrar.
5. The registry returns a successful transfer response to the gaining registrar.
6. The gaining registrar confirms the completed transfer to the client.

IANA Considerations TODO

Internationalization Considerations TODO

Security Considerations TODO

Change History

Version 00

• Created initial draft with core concepts and flows.

Normative References

Acknowledgements TODO