Secure Object Transfer for RESTful Provisioning Protocol (RPP)
draft-wullink-rpp-oauth2-transfer-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Maarten Wullink , Paweł Kowalik | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | rpp at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wullink-rpp-oauth2-transfer-00
Network Working Group M. Wullink
Internet-Draft SIDN Labs
Intended status: Standards Track P. Kowalik
Expires: 8 January 2027 DENIC
7 July 2026
Secure Object Transfer for RESTful Provisioning Protocol (RPP)
draft-wullink-rpp-oauth2-transfer-00
Abstract
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.
Status of This Memo
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 Notice
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.
Wullink & Kowalik Expires 8 January 2027 [Page 1]
Internet-Draft Secure Object Transfer for RPP July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Object Transfer Details . . . . . . . . . . . . . . . . . . . 3
5. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Data Objects . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Object Transfer Flows . . . . . . . . . . . . . . . . . . . . 8
9.1. Interactive Flow . . . . . . . . . . . . . . . . . . . . 10
9.2. Fallback Flow . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Internationalization Considerations . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Change History . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 15
14. Normative References . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. 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.
Wullink & Kowalik Expires 8 January 2027 [Page 2]
Internet-Draft Secure Object Transfer for RPP July 2026
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.
2. 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 [RFC7519].
3. 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 [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.
4. Object Transfer Details
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.
Wullink & Kowalik Expires 8 January 2027 [Page 3]
Internet-Draft Secure Object Transfer for RPP July 2026
+===================+========+=============+========================+
| 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). |
+-------------------+--------+-------------+------------------------+
Table 1: RPP Transfer Authorization, RAR authorization_details
object (Primary Method, [RFC9396])
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.
Wullink & Kowalik Expires 8 January 2027 [Page 4]
Internet-Draft Secure Object Transfer for RPP July 2026
5. Scopes
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.
6. Claims
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.
Wullink & Kowalik Expires 8 January 2027 [Page 5]
Internet-Draft Secure Object Transfer for RPP July 2026
+=======================+===========+======+========================+
| 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. |
+-----------------------+-----------+------+------------------------+
Table 2: RPP Specific Access Token Claims
7. 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.
Wullink & Kowalik Expires 8 January 2027 [Page 6]
Internet-Draft Secure Object Transfer for RPP July 2026
8. 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.
Wullink & Kowalik Expires 8 January 2027 [Page 7]
Internet-Draft Secure Object Transfer for RPP July 2026
* 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.
9. 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.
Wullink & Kowalik Expires 8 January 2027 [Page 8]
Internet-Draft Secure Object Transfer for RPP July 2026
*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
Wullink & Kowalik Expires 8 January 2027 [Page 9]
Internet-Draft Secure Object Transfer for RPP July 2026
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.
9.1. Interactive Flow
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 | |
| +-------------->| |
Wullink & Kowalik Expires 8 January 2027 [Page 10]
Internet-Draft Secure Object Transfer for RPP July 2026
| | | |
| | 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) | |
Wullink & Kowalik Expires 8 January 2027 [Page 11]
Internet-Draft Secure Object Transfer for RPP July 2026
| | | |
| |<------------------------------|
| | | |
| | 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 | | |
|<--------------| | |
| | | |
Figure 1: OAuth 2.0 Federated Secure Object Transfer -
Interactive Flow
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".
Wullink & Kowalik Expires 8 January 2027 [Page 12]
Internet-Draft Secure Object Transfer for RPP July 2026
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 ([RFC9068]). 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
[RFC8414]). 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.
9.2. 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:
Wullink & Kowalik Expires 8 January 2027 [Page 13]
Internet-Draft Secure Object Transfer for RPP July 2026
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 | | |
|<--------------| | |
| | | |
Figure 2: Fallback Object Transfer - Machine to Machine flow
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.
Wullink & Kowalik Expires 8 January 2027 [Page 14]
Internet-Draft Secure Object Transfer for RPP July 2026
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.
10. IANA Considerations
TODO
11. Internationalization Considerations
TODO
12. Security Considerations
TODO
13. Change History
13.1. Version 00
* Created initial draft with core concepts and flows.
14. Normative References
[I-D.ietf-rpp-core]
Wullink, M. and P. Kowalik, "RESTful Provisioning Protocol
(RPP)", Work in Progress, Internet-Draft, draft-ietf-rpp-
core-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rpp-
core-00>.
[I-D.wullink-rpp-oauth2]
Wullink, M. and P. Kowalik, "OAuth 2.0 for RESTful
Provisioning Protocol (RPP)", Work in Progress, Internet-
Draft, draft-wullink-rpp-oauth2-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-wullink-rpp-
oauth2-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Wullink & Kowalik Expires 8 January 2027 [Page 15]
Internet-Draft Secure Object Transfer for RPP July 2026
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
Acknowledgements
TODO
Authors' Addresses
Maarten Wullink
SIDN Labs
Email: maarten.wullink@sidn.nl
URI: https://sidn.nl/
Pawel Kowalik
DENIC
Email: pawel.kowalik@denic.de
URI: https://denic.de/
Wullink & Kowalik Expires 8 January 2027 [Page 16]