| Internet-Draft | Secure Object Transfer for RPP | July 2026 |
| Wullink & Kowalik | Expires 8 January 2027 | [Page] |
This document describes how OAuth 2.0 [RFC6749] can be used to secure object transfers in RESTful Provisioning Protocol (RPP) [I-D.ietf-rpp-core]. It extends the RPP OAuth 2.0 authorization model defined in [I-D.wullink-rpp-oauth2] with mechanisms specific to federated object transfers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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 [RFC2119].¶
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.¶
In RPP, Object Transfer Details as described in [I-D.wullink-rpp-oauth2] 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 Table 1 lists the RAR fields defined for RPP.¶
| 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:¶
[{
"type": "transfer",
"object_type": "domain",
"object_identifier": "foo.example"
}]
¶
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 ([RFC9396]), 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.¶
RPP OAuth 2.0 scopes are defined in [I-D.wullink-rpp-oauth2]. This document does not define new scopes; the existing transfer access level scope (e.g., domain:transfer) defined in [I-D.wullink-rpp-oauth2] MUST be used for transfer operations.¶
In addition to the standard [RFC9068] claims, table Table 2 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.¶
| 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 [I-D.ietf-rpp-core], 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. |
The RPP Data Object Catalog is extended to include each registrar's AS metadata.¶
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.¶
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 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:¶
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:¶
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 [RFC9068] 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.¶
The interactive flow uses the OAuth 2.0 Authorization Code grant Section 4.1 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 Section 9.2.¶
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) [RFC9396] as described in Section 4. 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:¶
Client Gaining Registry Losing
(Registrant) Registrar Registrar
| | | |
| 1. Initiate | | |
| transfer of | | |
| foo.example | | |
+-------------->| | |
| | | |
| | 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:¶
foo.example).¶
authorization_details parameter of type rpp_transfer with object_type: "domain" and object_identifier: "foo.example".¶
authorization_details claim echoing the rpp_transfer object.¶
Authorization header.¶
authorization_details claim (RAR), the registry MUST verify that the type is rpp_transfer and that object_identifier matches the object being transferred.¶
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:¶
Client Gaining Registry Losing
(Registrant) Registrar Registrar
| | | |
| 1. Initiate | | |
| transfer | | |
| (authz token| | |
| provided | | |
| out-of-band| | |
| by losing | | |
| registrar) | | |
+-------------->| | |
| | | |
| | 2. Transfer | |
| | request | |
| | (RPP-Authori-| |
| | zation: | |
| | <token>) | |
| +-------------->| |
| | | |
| | | 3. Validate |
| | | authz token |
| | | |
| | | 4. Execute |
| | | transfer & |
| | | notify Losing|
| | | Registrar |
| | +-------------->|
| | | |
| | 5. Transfer | |
| | successful | |
| |<--------------| |
| | | |
| 6. Transfer | | |
| confirmed | | |
|<--------------| | |
| | | |
The steps in the diagram are as follows:¶
RPP-Authorization header.¶
TODO¶
TODO¶