



RPP (RESTful Provisioning Protocol) Working Group             P. Kowalik
Internet-Draft                                                  DENIC eG
Intended status: Informational                                M. Wullink
Expires: 31 August 2026                                        SIDN Labs
                                                        27 February 2026


                            RPP Architecture
                     draft-ietf-rpp-architecture-01

Abstract

   Advancements in development, integration, deployment environments and
   operational paradigms have led to a desire for an alternative for the
   Extensible Provisioning Protocol (EPP).  This document defines the
   architecture for the RESTful Provisioning Protocol (RPP) - an HTTP
   based provisioning protocol leveraging the REST architectural style
   and JSON data-interchange format, aiming to standardise a RESTful
   protocol for provisioning database objects.  The architecture
   includes support for extensibility, allowing for multiple possible
   use cases.  RPP is intended to co-exist with EPP, offering an
   alternative protocol including data model compatibility with EPP core
   objects and the benefits associated with the REST architectural style
   and widely adopted HTTP-based technologies.

Contributing

   When contributing to this document, please use the following GitHub
   project: https://github.com/ietf-wg-rpp/RPP-architecture.

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 31 August 2026.





Kowalik & Wullink        Expires 31 August 2026                 [Page 1]

Internet-Draft            ietf-rpp-architecture            February 2026


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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   5
     4.1.  Resource Oriented Architecture  . . . . . . . . . . . . .   7
     4.2.  Architecture Layers . . . . . . . . . . . . . . . . . . .   7
       4.2.1.  HTTP Transport Layer  . . . . . . . . . . . . . . . .   7
       4.2.2.  Data Representation Layer . . . . . . . . . . . . . .   9
       4.2.3.  Resource Definition Layer . . . . . . . . . . . . . .  10
   5.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  HTTP Transport Layer Details  . . . . . . . . . . . . . .  10
       5.1.1.  Transport Security  . . . . . . . . . . . . . . . . .  11
       5.1.2.  Authentication and Authorisation  . . . . . . . . . .  11
       5.1.3.  Credential management . . . . . . . . . . . . . . . .  11
       5.1.4.  Resource Addressing . . . . . . . . . . . . . . . . .  13
       5.1.5.  Mapping of basic operations to HTTP uniform interface
               (verbs) . . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.6.  Mapping of operations beyond HTTP uniform interface to
               URLs and verbs  . . . . . . . . . . . . . . . . . . .  16
       5.1.7.  Server-Managed Resources  . . . . . . . . . . . . . .  18
       5.1.8.  HTTP response status codes  . . . . . . . . . . . . .  18
       5.1.9.  Content negotiation for media types . . . . . . . . .  18
       5.1.10. Caching . . . . . . . . . . . . . . . . . . . . . . .  19
       5.1.11. Language negotiation for textual content  . . . . . .  19
       5.1.12. Client Signalling for Response Verbosity  . . . . . .  19
       5.1.13. Client Signalling for Request Validation  . . . . . .  20
       5.1.14. Asynchronous Operation Processing . . . . . . . . . .  20
       5.1.15. Service Messages  . . . . . . . . . . . . . . . . . .  21
       5.1.16. RPP specific status codes and relation to HTTP response
               status codes  . . . . . . . . . . . . . . . . . . . .  22
       5.1.17. Transaction tracing and idempotency . . . . . . . . .  23
       5.1.18. Message verification  . . . . . . . . . . . . . . . .  24



Kowalik & Wullink        Expires 31 August 2026                 [Page 2]

Internet-Draft            ietf-rpp-architecture            February 2026


       5.1.19. Protocol Versioning . . . . . . . . . . . . . . . . .  24
       5.1.20. Profiles  . . . . . . . . . . . . . . . . . . . . . .  24
       5.1.21. Definition of special resources . . . . . . . . . . .  25
       5.1.22. Service discovery mechanisms  . . . . . . . . . . . .  25
       5.1.23. Scalability . . . . . . . . . . . . . . . . . . . . .  27
     5.2.  Data Representation Layer . . . . . . . . . . . . . . . .  27
       5.2.1.  Data structure  . . . . . . . . . . . . . . . . . . .  27
       5.2.2.  Data format . . . . . . . . . . . . . . . . . . . . .  27
       5.2.3.  Data Validation . . . . . . . . . . . . . . . . . . .  28
       5.2.4.  Media Type definition . . . . . . . . . . . . . . . .  28
       5.2.5.  Optionality . . . . . . . . . . . . . . . . . . . . .  29
     5.3.  Resource Definition Layer . . . . . . . . . . . . . . . .  29
       5.3.1.  Data Elements . . . . . . . . . . . . . . . . . . . .  29
       5.3.2.  Relationships . . . . . . . . . . . . . . . . . . . .  30
       5.3.3.  Mapping . . . . . . . . . . . . . . . . . . . . . . .  30
       5.3.4.  Operations  . . . . . . . . . . . . . . . . . . . . .  31
       5.3.5.  Server-Managed Resource Types . . . . . . . . . . . .  31
       5.3.6.  Data privacy  . . . . . . . . . . . . . . . . . . . .  31
     5.4.  Extension mechanisms  . . . . . . . . . . . . . . . . . .  32
       5.4.1.  Layered Extensibility . . . . . . . . . . . . . . . .  32
       5.4.2.  Protocol Element Extension  . . . . . . . . . . . . .  32
       5.4.3.  IANA Registry-Based Discovery . . . . . . . . . . . .  33
       5.4.4.  Compatibility and Profiles  . . . . . . . . . . . . .  33
       5.4.5.  Name Management and Collision Avoidance . . . . . . .  33
       5.4.6.  Extension Security  . . . . . . . . . . . . . . . . .  34
       5.4.7.  Extension Review  . . . . . . . . . . . . . . . . . .  34
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   7.  Change History  . . . . . . . . . . . . . . . . . . . . . . .  34
     7.1.  -00 to -01  . . . . . . . . . . . . . . . . . . . . . . .  35
     7.2.  -03 to draft-ietf-rpp-architecture-00 . . . . . . . . . .  37
     7.3.  -02 to -03  . . . . . . . . . . . . . . . . . . . . . . .  37
     7.4.  -01 to -02  . . . . . . . . . . . . . . . . . . . . . . .  37
     7.5.  -00 to -01  . . . . . . . . . . . . . . . . . . . . . . .  38
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  38
     8.2.  Informational References  . . . . . . . . . . . . . . . .  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42

1.  Introduction

   This document outlines the architecture of the RESTful Provisioning
   Protocol (RPP).  RPP aims to provide a modern, standardised, and
   developer-friendly protocol for provisioning and managing objects in
   a shared database or registry, initially focusing on functional
   equivalents of EPP object mappings for domain names [RFC5731], hosts
   [RFC5732], and contacts [RFC5733].  RPP also considers provisioning
   of other objects as a potential use case, aiming for a uniform API
   layer for various registry operations.



Kowalik & Wullink        Expires 31 August 2026                 [Page 3]

Internet-Draft            ietf-rpp-architecture            February 2026


   RPP is designed to leverage the benefits of REST (REpresentational
   State Transfer), including statelessness, ease of integration, and
   compatibility with existing web infrastructure and tooling such as
   OpenAPI, API gateways, and web application firewalls.  By adopting
   JSON as the data-interchange format, RPP seeks to align with current
   development practices and the successful deployment patterns observed
   in protocols such as RDAP [RFC9082].  The choice of REST and JSON
   also facilitates direct browser and mobile application integration
   including modern security mechanisms such as OAuth2.0.

   This architecture document serves as a foundation for a series of
   specifications that will collectively define RPP.  It details the
   layered approach, core components, and design considerations for
   building an interoperable and extensible provisioning protocol.  RPP
   is intended to coexist with EPP, offering an alternative for
   implementers seeking a RESTful approach without aiming to replace EPP
   or define migration paths from EPP.  RPP aims for data model
   compatibility with EPP core objects to allow automatic and mechanical
   mapping and conversion, especially for core objects (domain, contact,
   host).

2.  Terminology

   This document uses terminology from RFC5730 [RFC5730] and broadly
   adopts the REST architectural principles as defined in [REST] and
   related RFCs.

   *  *RPP:* RESTful Provisioning Protocol.  The protocol being defined
      by the RPP working group.

   *  *EPP:* Extensible Provisioning Protocol as defined in [RFC5730].

   *  *REST:* Representational State Transfer architectural style
      [REST].

   *  *JSON:* JavaScript Object Notation [RFC8259].

   *  *JWT:* JSON Web Token [RFC7519].

   *  *OpenAPI:* The OpenAPI Specification (OAS) (formerly known as
      Swagger Specification) is an API description format for REST APIs
      [OpenAPI].

   *  *RPP client:* An entity or application that interacts with the RPP
      server to perform provisioning operations, such as creating,
      updating, or deleting resources.





Kowalik & Wullink        Expires 31 August 2026                 [Page 4]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  *EPP AuthInfo:* EPP password based Authorisation Information
      defined in [RFC5731] and [RFC5733].

   *  *Sponsoring Client:* The RPP Client that currently has sponsorship
      of the object.

   *  *Gaining Client:* The client seeking to gain sponsorship of the
      object in a Transfer Operation.

   *  *IDN:* Internationalised Domain Names as defined in [RFC5890]

   *  *TLS:* Transport Layer Security, as defined in [RFC8446] or its
      successors.

   *  *HTTPS:* HTTP over TLS, as defined in [RFC9110] or its successors.

3.  Requirements

   This document is based on the requirements defined by the RPP Working
   Group as of 5 December 2025 [RPPReq].

4.  Architectural Overview

   This chapter provides an overview of the RPP architecture.  A key
   design principle is to leverage existing web standards, particularly
   HTTP and REST.  This allows RPP to delegate functionality and
   features to the well-established infrastructure and semantics of the
   web, focusing its own definitions on the specific domain of object
   provisioning.  Therefore, we assume:

   *  *HTTP and RESTful principles are foundational:* RPP leverages HTTP
      for transport and adheres to RESTful principles for resource
      management.

   *  *Domain-specific logic resides in data representations:* The
      specifics of resource provisioning are encoded within the data
      structures and semantics of the RPP message bodies.

   *  *Layered architecture for modularity:* The architecture is layered
      to promote modularity, separation of concerns, and independent
      evolution of different aspects of the protocol.

   The architecture is divided into three main layers: *HTTP Transport*,
   *Data Representation*, and *Resource Definition*. Each layer defines
   specific aspects of the protocol.  This layered approach allows for
   clear separation of concerns.





Kowalik & Wullink        Expires 31 August 2026                 [Page 5]

Internet-Draft            ietf-rpp-architecture            February 2026


   *Data Structure* is a sub-layer of Data Representation and described
   later in this document.  It focuses on the structure of RPP messages.

   Similarly *Data Elements*, their *Mapping* onto Data Structure and
   *Operations* are elements of Resource Definition.  They focus on the
   semantic structure of RPP resources and transformation of those
   resources.

     +---------------------------------------------------------+
     |                      HTTP Transport                     |
     |                                                         |
     | +-----------------------------------------------------+ |
     | |                 Data Representation                 | |
     | |                                                     | |
     | |   +- - - - - - - - - - - - - - - - - - - - - - -+   | |
     | |   |                Data Structure               |<-------+
     | |                                                     | |  |
     | |   | +-----------------------------------------+ |   | |  |
     | |     |           Resource Definition           |     | |  |
     | |   | |                                         | |   | |  |
     | |     | +--------------+       +--------------+ |     | |  |
     | |   | | |              |       |              | | |   | |  |
     | |     | |     Data     |       |   Mapping    | |     | |  |
     | |   | | |   Elements   |------>|              |------------+
     | |     | |              |       |              | |     | |
     | |   | | |              |       |              | | |   | |
     | |     | +--------------+       +--------------+ |     | |
     | |   | |     ^                                   | |   | |
     | |     |     |                                   |     | |
     | |   | |     |      +--------------+             | |   | |
     | |     |     |      |              |             |     | |
     | |   | |     |      |  Operations  |             | |   | |
     | |     |     +------|              |             |     | |
     | |   | |            |              |             | |   | |
     | |     |            +--------------+             |     | |
     | |   | |                                         | |   | |
     | |     +-----------------------------------------+ |   | |
     | |   +- - - - - - - - - - - - - - - - - - - - - - -+   | |
     | +-----------------------------------------------------+ |
     +---------------------------------------------------------+











Kowalik & Wullink        Expires 31 August 2026                 [Page 6]

Internet-Draft            ietf-rpp-architecture            February 2026


4.1.  Resource Oriented Architecture

   RPP adopts a Resource Oriented Architecture (ROA), aligning with
   RESTful principles.  This approach defines all manageable entities as
   "resources," identified by unique URLs.  Operations on these
   resources are performed through a uniform interface using the
   standard HTTP methods and their semantics.  This contrasts with RPC-
   style protocols, which often define new and specific operations with
   custom parameters.  ROA promotes a more standardised and
   interoperable approach, leveraging the existing web infrastructure
   and its well-defined semantics.  Key aspects of ROA within RPP
   include:

   *  *Resource Identification:* Each resource is uniquely identifiable
      by a URL.

   *  *Uniform Interface:* HTTP methods (HEAD, GET, POST, PUT, DELETE,
      PATCH) are used to perform operations on resources in a consistent
      manner.

   *  *Operation Singularity* Operations, excluding collection
      retrieval, are defined to target a single resource.  Operations
      intended to affect multiple resources, such as bulk operations (a
      single command applied to multiple resources) or command sets
      (multiple commands on multiple resources), should be modelled
      through dedicated "batch" or "bulk operation" resources.

   *  *Representation:* Resources can be represented in various formats
      (e.g., JSON, XML) through HTTP standard content negotiation.

   *  *Statelessness:* Each request to a resource is treated as
      independent of previous requests.  The server does not maintain
      client state between requests.

   *  *Cacheability:* Responses can be cached to improve performance.

4.2.  Architecture Layers

4.2.1.  HTTP Transport Layer

   This layer defines the transport mechanism for RPP messages,
   utilising HTTP as the underlying protocol.

   The HTTP Transport Layer consists of two sub-layers:







Kowalik & Wullink        Expires 31 August 2026                 [Page 7]

Internet-Draft            ietf-rpp-architecture            February 2026


4.2.1.1.  Built-in HTTP Features

   These are features that are fully specified by the HTTP standard
   itself.  RPP leverages these features directly, specifying their use
   within the protocol without a need to define their behaviour.

   It encompasses aspects such as:

   *  *Transport security:* Mechanisms to secure message transmission

   *  *Authentication and Authorisation:* Mechanisms for verifying the
      identity of clients and controlling access to resources.

   *  *Resource Addressing using URLs:* Consistent and meaningful URL
      structures for identifying, accessing resources and enabling
      request routing.

   *  *Mapping of basic operations to HTTP uniform interface (verbs):*
      Mapping CRUD (Create, Read, Update, Delete) operations to POST,
      HEAD/GET, PUT/PATCH, and DELETE respectively.

   *  *Mapping of operations beyond HTTP uniform interface to URLs and
      verbs:* Handling more complex operations through appropriate URL
      structures and HTTP methods.

   *  *HTTP response status codes:* Utilising standard HTTP response
      status codes to indicate the outcome of requests.

   *  *Content negotiation for media types:* Supporting multiple data
      representation formats and using content negotiation to select the
      appropriate format.

   *  *Caching:* Leveraging HTTP caching mechanisms to improve
      performance.

   *  *Language negotiation for textual content:* Supporting multiple
      languages for textual content and using language negotiation to
      select the appropriate language.

   *  *Representation preferences:* The option for a client to indicate
      a preference for either a full representation of an object or a
      limited representation.









Kowalik & Wullink        Expires 31 August 2026                 [Page 8]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  *Validation preferences:* Defining the approach to the input data
      validation that shall be applied by the server.  The server may
      apply lenient validation where the server makes best effort to
      process the understood part of the request as opposed to strict
      processing where the server would reject a request where part of
      the data is not understood

4.2.1.2.  RPP-Specific Extensions

   These are protocol features where HTTP provides the necessary
   building blocks, but RPP defines additional rules, conventions, or
   mechanisms to address protocol-specific requirements.

   It encompasses aspects such as:

   *  *Asynchronous Operation Management:* Facilitating the handling of
      operations that are not completed immediately, by defining an
      HTTP-based interaction pattern for status checking and deferred
      result retrieval.

   *  *RPP specific error codes and relation to HTTP response status
      codes:* Defining RPP-specific error codes while relating them to
      standard HTTP response status codes for consistency.

   *  *Transaction tracing and idempotency:* Mechanisms for tracking
      requests and ensuring idempotent operations where appropriate.

   *  *Versions and profiles:* Support signalling of versions of RPP
      protocol and other protocol elements as well as defining sets of
      protocol elements and their versions in the form of profiles.

   *  *Definition of special resources:* Defining specific resources for
      service discovery, metadata retrieval, etc.

   *  *Service discovery mechanisms:* Mechanisms for clients to discover
      available RPP services.

4.2.2.  Data Representation Layer

   This layer focuses on the data representation of RPP messages.  It
   defines the media type used to carry RPP data and supports various
   data representation formats.

   It encompasses aspects such as:

   *  *Data structure:* Defining the structure and schema of the RPP
      data, potentially using a specific schema language.




Kowalik & Wullink        Expires 31 August 2026                 [Page 9]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  *Data format:* Defining the specific format used to represent RPP
      data within the representation (e.g., JSON, XML or JWT).

   *  *Media Type definition:* Defining the specific media type to be
      used in RPP, including any constraints on the data format and
      structure

4.2.3.  Resource Definition Layer

   This layer defines the structure and operations for each resource
   type, independent of media type or representation.  It ensures
   resources are well-defined and allows for easy extensibility and
   compatibility with different media types.

   It encompasses aspects such as:

   *  *Data elements:* Defining the individual data elements that make
      up a resource, including their data types, formats, and any
      constraints.

   *  *Resource type definitions:* Defining the structure of specific
      resource types by combining data elements.

   *  *IANA registry definitions:* Potentially registering resource
      definitions with IANA for standardised and automated processing.

   *  *Mapping of data elements to media types:* Defining how the data
      elements of a resource type are represented in different media
      types (e.g., JSON, XML).

   *  *Extension mechanisms:* Providing mechanisms for creating new
      resource types and for extending existing resource types with new
      data elements or operations including potentially new response
      status codes.

5.  Protocol Details

   This section provides further details on each layer of the RPP
   architecture.

5.1.  HTTP Transport Layer Details

   The RPP architecture uses the best practices described in [RFC9205]
   for the HTTP transport layer.







Kowalik & Wullink        Expires 31 August 2026                [Page 10]

Internet-Draft            ietf-rpp-architecture            February 2026


5.1.1.  Transport Security

   RPP communication relies on HTTPS with TLS to provide protection for
   data in transit, addressing threats such as eavesdropping, tampering,
   and man-in-the-middle attacks.  Specific security policy details are
   delegated to TLS standards and best practices, allowing
   implementations to adapt to evolving security requirements without
   changes to the protocol specifications.

5.1.2.  Authentication and Authorisation

   RPP is aimed to leverage scalable and modern authorisation standards,
   with a focus on OAuth 2.0 [RFC6749] and related frameworks.  However,
   to maintain functional equivalence with EPP client authentication,
   RPP SHOULD also support authentication schemes that can carry a
   client identifier and a password, such as HTTP Basic Authentication
   [RFC7617].  RPP should be able to support future authentication and
   authorisation standards defined for HTTP.

5.1.3.  Credential management

   The management of client credentials is not considered to be a part
   of the core protocol, for this an extension can be created using the
   extension points described in Section 5.4.  This will enable support
   for situations where management of authentication credentials is not
   delegated to a separate identity provider.

   Specifications will define profiles for:

   *  HTTP Authentication schemes (e.g., HTTP Basic Authentication,
      Bearer Token [RFC6750] etc.)

   *  Authorisation frameworks (e.g., OAuth 2.0 [RFC6749])

   Implementations will be able to choose authentication and
   authorisation methods appropriate for their security requirements.

5.1.3.1.  Authorisation Scopes

   RPP specifications will standardise authorisation scopes (like
   rpp:read or rpp:write) to define granular access control for
   different usage scenarios.  These scopes will be defined for various
   operations and resource types, ensuring that clients can be granted
   only the necessary permissions.







Kowalik & Wullink        Expires 31 August 2026                [Page 11]

Internet-Draft            ietf-rpp-architecture            February 2026


5.1.3.2.  Fine-Grained Authorisation

   RPP authorisation models may become fine-grained, extending beyond
   simple auth-code based models used in EPP.  Authorisation decisions
   will be able to consider the specific operation being performed
   (e.g., update vs. read), the resource being accessed (e.g., a
   specific domain name), and potentially even attributes within the
   resource.

   Here solutions like OAuth2 RAR [RFC9396] could be considered to
   provide fine-grained access control.

5.1.3.3.  Relationship between clients and authentication credentials

   RPP authentication and authorisation model will make a clear
   distinction between the login credentials and the authorisation to
   act in context of a given RPP client.  More than one credential might
   be authorised to act on behalf of the same RPP client.  The same
   credential however must always be assigned to one and only one RPP
   client context.

   In case of HTTP Basic Authentication, one user-id is always bound to
   at most one RPP client.  For OAuth, the issued token is bound to the
   context of at most one RPP client, even though the OAuth client
   itself might have access to multiple RPP clients.  The assignment of
   tokens to specific RPP clients can be controlled through the
   authorisation flow using the OAuth scope parameter.  For example, if
   an OAuth client has access to two RPP clients (Client A and Client
   B), the scope parameter can specify which client the token applies
   to.  A scope value like scope=rpp:clientA would ensure the token is
   valid only for Client A, while scope=rpp:clientB would apply to
   Client B.

5.1.3.4.  Security

   RPP will not explicitly define security related policies related to
   authentication or authorisation (such as password complexity, token
   lifetime, cryptography used, or additional measures to verify the
   client) on the protocol level.  Instead, these properties will be
   delegated to the best practices of the chosen authentication schemes,
   which may evolve over time and would have to be independent of the
   protocol itself.

5.1.3.5.  Credential and Token Lifecycle

   RPP will support mechanisms for revoking, rotating or deprecating
   credentials, tokens, or permissions when they are no longer needed or
   if they become compromised.



Kowalik & Wullink        Expires 31 August 2026                [Page 12]

Internet-Draft            ietf-rpp-architecture            February 2026


   The architecture delegates revocation mechanisms to the specific
   authentication method in use, following their established practices.
   For OAuth-based deployments, standard token revocation mechanisms as
   defined in [RFC7009] should be utilised.  For HTTP Basic
   Authentication revocation must be fulfilled by off-band operational
   practice, or using extension as described in Section 5.1.3 to rotate
   the credential.  Protocol specifications must emphasise, that
   implementations should ensure that revocation takes effect promptly
   and that revoked credentials are consistently rejected across all RPP
   endpoints.

   Service discovery endpoints may advertise supported revocation
   mechanisms, enabling clients to discover how to revoke credentials
   when necessary.

5.1.3.6.  Object level authorisation

   RPP will define a mechanism for object-level authorisation,
   preventing unauthorised access to specific objects or resources.
   Each object will have an associated sponsor or owner with full
   control over an object, and the protocol will allow for the
   specification of which clients are authorised to access or modify
   non-sponsored/owned objects.  This could be achieved through state-
   of-the-art standards like OAuth authorisation tokens, scopes, and
   resource-specific permissions but also shared secrets for backward
   compatibility with EPP password-based authorisation information.  All
   RPP specifications shall support the operational practices described
   in [RFC9154], such as not allowing long-term storage of plaintext EPP
   AuthInfo used for object transfer operations.  All parties involved
   in a running or completed process, such as the Sponsoring Client and
   the Gaining Client for a transfer operation, must be allowed to query
   the status of the process using the same process resource.

5.1.4.  Resource Addressing

   RPP resources are addressed using URLs.  Considerations include:

   *  Hierarchical URL structure to represent resources of different
      types (e.g., /domains/{domain-name}, /contacts/{contact-id}).

   *  URL structure to represent list of related resources (e.g.,
      /domains/{domain-name}/contacts/)

   RPP URL structure will be designed to be human-readable, intuitive,
   and RESTful, allowing clients to easily navigate and interact with
   resources.





Kowalik & Wullink        Expires 31 August 2026                [Page 13]

Internet-Draft            ietf-rpp-architecture            February 2026


   RPP would not require all URLs to be hard wired to server's RPP root
   URL.  Instead, it would allow for relative URLs to be defined and
   discovered by the client.  This would allow servers to distribute
   resources across multiple servers and URLs and allow for easier
   scaling as described in [RFC9205].  At the same time the URLs shall
   be deterministic for the duration of the client session in order to
   minimise round trips and streamline the interaction.

   As a matter of extensibility consideration RPP should allow for
   additional path segments to be added to the URLs and be discoverable
   by clients.

   RPP responses will include URLs for related resources, allowing
   clients to navigate newly created resources easily.  This is similar
   to the "links" concept in RESTful APIs, where related resources are
   linked together.

5.1.4.1.  Collection Representation

   RPP supports retrieval of collections of resources via dedicated
   collection endpoints (e.g., /domains/ for listing domains).  For
   collections that may contain large numbers of resources, RPP supports
   pagination using established mechanisms such as HTTP Link headers as
   defined in [RFC8288].  Items within a collection may be returned as
   partial representations rather than full resource details, reducing
   payload size.  Clients can retrieve full details by following links
   to individual resources.  RPP may also support query parameters for
   filtering and sorting collection results.

   These capabilities are optional at the protocol level.  RPP does not
   mandate bulk operations, resource listing, or filtering where such
   functionality may negatively impact server scalability or
   performance.  Server operators may choose not to support these
   features, or may restrict their scope, based on their operational
   requirements.  Supported capabilities are advertised through the
   service discovery mechanism (see Section 5.1.22).

5.1.4.2.  Internationalised Domain Names (IDN)

   RPP will address the handling of IDNs in resource addressing.
   Specifications will define whether to use IDN or UTF-8 encoding
   directly in URLs and whether to employ redirects to canonical URLs or
   "see-also" linking for alternative representations.  For example, a
   "see-also" link could point from a UTF-8 encoded URL to an IDN URL
   and vice versa, allowing clients to use either URL.  Another way
   would be to always redirect to the canonical URL, which would be the
   IDN URL.




Kowalik & Wullink        Expires 31 August 2026                [Page 14]

Internet-Draft            ietf-rpp-architecture            February 2026


5.1.4.3.  Canonical Addressing

   A single resource can be addressed using multiple alternative
   identifiers in a URL.  These identifiers may represent different
   alternative syntactic forms, these include, but are not limited to:

   *  Internationalised identifiers (IDNs) and their ASCII/Punycode
      equivalents

   *  Unicode identifiers and their percent-encoded representations

   The canonical address is the authoritative identifier for the
   resource and is the form that RPP uses for:

   *  Persistent storage and internal references

   *  Hypermedia links generated by the server

   *  Resource metadata and self-links

   *  Equality checks

   Any other valid address for the same resource is to be treated
   strictly as an alias.  When a resource is addressed using an alias,
   RPP must ensure canonicalisation through at least one of the
   following mechanisms:

   *  Redirecting the client to the canonical URL

   *  Returning a representation that explicitly declares the canonical
      URL

   *  Internally resolving the alias to the canonical identifier before
      any authorisation, or state mutation occurs

   Canonicalisation shall be performed prior to any operation that
   depends on resource identity.

5.1.5.  Mapping of basic operations to HTTP uniform interface (verbs)

   RPP operations are mapped to standard HTTP methods to leverage the
   uniform interface and RESTful principles:

   *  *HEAD:* Retrieve resource state (e.g., retrieving domain existence
      information).  This may be a candidate for equivalence of EPP
      check command, however it may come with a few caveats to consider:





Kowalik & Wullink        Expires 31 August 2026                [Page 15]

Internet-Draft            ietf-rpp-architecture            February 2026


      -  EPP check is intended to check whether (future) resource
         provisioning is possible.  This is not semantically the same as
         resource state.  Overloading HEAD with EPP semantics may lead
         to confusion, especially as some frameworks implicitly
         implement HEAD out of GET handling.

      -  a better equivalence of EPP check would be a POST with Expect
         header, however this header being a reserved header in browsers
         it may not be available to all client implementations

      The conclusion is that RPP should not overload HTTP HEAD with own
      semantics, and support HEAD as it is defined in HTTP.

   *  *OPTIONS* RPP shall not define any new semantics for OPTIONS
      however the specifications should make implementers aware of its
      role in CORS and pre-flight requests typically made by web
      browsers

   *  *GET:* Retrieve resource state (e.g., retrieving domain or contact
      information) - EPP info command

   *  *POST:* Create a new resource (e.g., registering a domain or
      create contact object) - EPP create command

   *  *PUT:* Update an existing resource in its entirety (e.g., updating
      domain registration details) - not 100% equivalent of EPP update
      command

   *  *DELETE:* Delete a resource (e.g., deleting a domain registration)
      - EPP delete command

   *  *PATCH:* Partially modify a resource (e.g., updating specific
      attributes of a domain or contact) - EPP update command

5.1.6.  Mapping of operations beyond HTTP uniform interface to URLs and
        verbs

   Many of EPP commands do not map directly to the HTTP uniform
   interface.  RPP will define how to handle these operations using
   appropriate URL structures and HTTP methods.  In order to model
   additional operations RPP will define an abstraction of process, this
   being either a transient or a long running operations with state.  In
   both cases such process may accept additional input data as well as
   have an outcome or result not being part of the resource state
   itself.  Processes shall therefore be modelled as separate sub-
   resources of the resource being processed, with own uniform interface
   and set of operations (CRUD).




Kowalik & Wullink        Expires 31 August 2026                [Page 16]

Internet-Draft            ietf-rpp-architecture            February 2026


   EPP transfer commands (query and transform), may be modelled by a
   subresource /transfer of the resource being transferred, or a
   collection /transfers with a PUT/POST operation correspondingly to
   initiate the transfer, GET operation to query the transfer status and
   POST operation to approve or reject the transfer.

   Other transform operations like renew, or restore which are not
   directly addressable resources in terms of REST will modelled as a
   convention of URLs with processing resources with only POST
   interface, e.g. /renewal.

   Bulk operations can be supported on collections of resources, such as
   updating multiple domain objects within a single transaction.  URLs
   for bulk operations must unambiguously indicate that the operation
   targets multiple objects, ensuring clear intent for clients and
   servers.  Unless explicitly specified otherwise by the server
   operator, bulk operations should be executed atomically in a single
   transaction, guaranteeing consistency across all affected resources.

   This pattern can be further applied to object operations not defined
   in the core protocol or EPP, allowing easy and uniform extension of
   allowed operations.

   In order to minimise name collisions between process names and other
   kind of sub-resources, a distinct path segment shall be dedicated to
   processes, e.g. /processes/{process-name} or /operations/{operation-
   name}.

   The path segments shall be appended to the resource path to create
   full URI of such processing resource (e.g. /domains/{domain-
   name}/processes/renewal for domain renew operation).

   As discussed in Section 5.1.5 EPP check command may not be
   appropriate to be mapped directly to the HTTP uniform interface of
   the resource itself.  EPP check command will be therefore modelled as
   sub-resource such as /availability offering both HEAD operation for
   quick yes/no response and GET operation for more detailed response
   allowing for example to extend on the dataset provided (e.g. pricing
   information).

   This basic set of rules and guidelines will be further refined in the
   RPP specifications and give a universal toolset for extending RPP
   with new resources and commands.








Kowalik & Wullink        Expires 31 August 2026                [Page 17]

Internet-Draft            ietf-rpp-architecture            February 2026


5.1.7.  Server-Managed Resources

   RPP supports the definition of first-class resources whose state is
   managed exclusively by the server rather than provisioned by clients.
   These server-managed resources are read-only from the client's
   perspective, permitting only retrieval operations (GET, HEAD) through
   the uniform interface.  Modification operations (POST, PUT, PATCH,
   DELETE) are not available to clients for these resources.

   Server-managed resources are identified by URLs following the same
   addressing conventions as client-provisioned resources.  They
   participate fully in RPP's resource model, including content
   negotiation, caching, and representation formats.  The read-only
   nature of these resources is enforced by the server, which responds
   with appropriate HTTP status codes (e.g., 405 Method Not Allowed or
   403 Forbidden) if a client attempts a modification operation.

   Further aspects of server-managed resources, including examples and
   sub-resource relationships, are described in Section 5.3.5.

5.1.8.  HTTP response status codes

   In general RPP shall make use of HTTP response status codes to
   indicate general response status categories (e.g., 2xx success
   responses, 4xx for client errors, 5xx for server errors) [RFC7231] as
   opposed to responding always 200 if the request was understood even
   if the operation itself failed.  This allows clients and
   intermediaries to make first level of determination of the requests
   outcome based on the status code alone, without needing to parse the
   response body.

   RPP shall use as specific HTTP response status codes as possible,
   using generic codes like 400 Bad Request or 500 Internal Server Error
   only if no corresponding specific code exists (e.g. 404 for not
   existing resource or 401 for unauthenticated request).

   More specific RPP codes are elaborated in Section 5.1.16.

5.1.9.  Content negotiation for media types

   RPP supports content negotiation to allow clients to specify
   preferred media types for request and response payloads using the
   HTTP 'Accept' and 'Content-Type' headers [RFC7231].

   *  "application/rpp+json" as the primary media type.

   *  potential media type parameters for versioning, profiles, and
      other protocol elements.



Kowalik & Wullink        Expires 31 August 2026                [Page 18]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  Potential support for other media types defined in the Section 5.2

5.1.10.  Caching

   RPP shall benefit from HTTP standard caching mechanisms to enable
   standard components like proxies and caches to improve performance
   and reduce load on servers.  RPP shall define caching policies for
   different resources and operations, including cache-control headers
   and ETag support.

5.1.11.  Language negotiation for textual content

   RPP shall support language negotiation to enable clients to request
   responses in a preferred language using the HTTP 'Accept-Language'
   header [RFC7231].

   *  Server implementations MAY support multiple languages for textual
      content in responses to provide human-readable localised
      responses.

   *  The default language and mechanisms for indicating supported
      languages will be defined, preferably using HTTP methods, like
      OPTIONS or HEAD requests.

   *  "application/rpp+json" media type may support multi-language
      representations, especially for writing operations involving user
      provided content.  Other media types may have different mechanisms
      for language representation.

5.1.12.  Client Signalling for Response Verbosity

   RPP may utilise the HTTP Prefer header [RFC7240] with the "return"
   preference to allow clients to control the verbosity of responses.
   For example, clients not interested in full resource representations
   could use Prefer: return=minimal to request minimal responses,
   reducing payload sizes and improving efficiency or Prefer:
   return=representation to receive full representation of the object.
   The default behaviour, without the Prefer header, would be to return
   a full representation only for GET requests and a minimal resource
   representation in all other cases, similar to responses in EPP, and
   following the data minimisation principles.  For certain use-cases it
   might be convenient for a client to receive also dereferenced full or
   partial representation of related objects.  For example details about
   sponsoring client of domain name instead of just ID. "return"
   preference syntax alone is not sufficient for this purpose, therefore
   RPP would need to define custom preference and register it in "HTTP
   Preferences" IANA registry.




Kowalik & Wullink        Expires 31 August 2026                [Page 19]

Internet-Draft            ietf-rpp-architecture            February 2026


5.1.13.  Client Signalling for Request Validation

   RPP may utilise the HTTP Prefer header [RFC7240] for signalling the
   preference for either strict or lenient processing of requests.  This
   allows clients to indicate whether they prefer strict validation of
   message payloads and rejection of requests with unknown properties or
   a more lenient approach ignoring unknown properties that may allow
   for additional flexibility in processing.  The default behaviour,
   without the Prefer header, would be strict validation.

5.1.14.  Asynchronous Operation Processing

   The RPP architecture accommodates operations that are potentially
   long-running or cannot be completed synchronously due to their nature
   (e.g., acting on multiple objects, resource-intensive tasks, or
   processes involving manual steps).  This is achieved by leveraging
   standard HTTP mechanisms to provide an asynchronous interaction
   pattern.  This pattern allows a client to initiate an operation and
   receive an immediate acknowledgement, with the means to check the
   operation's status and retrieve its outcome at a later point.

   The typical interaction flow facilitated by the architecture is as
   follows: 1.  A client initiates an operation via an HTTP request. 2.
   For operations processed asynchronously, the server typically
   responds immediately with an appropriate HTTP response status code
   and an indication of a status resource where the client would be able
   to obtain result of the operation.  The resource may be dedicated to
   the specific performed operation, be a subresource of the resource
   being processed, or be a separate message queue resource with a
   stream of operation results. 3.  The server may also provide
   additional signalling in the response to indicate the expected time
   for completion or other relevant information using standard HTTP
   mechanisms. 4.  The representation of the status resource reflects
   the operation's progress.  Once the operation concludes, this
   representation indicates the final outcome, providing either the
   results directly, links to the results, or detailed error information
   in line with RPP's error reporting principles.  It shall remain up to
   protocol design for certain operation and server policy which
   granularity of status information shall be offered.  In some cases it
   might be sufficient to have one final message, in other cases
   intermediate statuses might be required.  The lifetime of these
   resources might also be differentiated.  Messages in the queue would
   exist until they are read out by the RPP client.  Other status
   resources might exist for a specific time defined by the server after
   the processing reached its final state.  Finally resources might
   virtually exist forever or require an explicit delete operation from
   the client.




Kowalik & Wullink        Expires 31 August 2026                [Page 20]

Internet-Draft            ietf-rpp-architecture            February 2026


   This architectural approach to asynchronous operations allows client
   applications to remain responsive and manage extended processing
   times effectively, contributing to the overall scalability and
   robustness of interactions within the RPP ecosystem.  Specific RPP
   operations intended for asynchronous execution will be designed to
   utilise this pattern.

5.1.15.  Service Messages

   RPP provides a mechanism for servers to communicate service messages
   to clients, offering a functional equivalent to the EPP Poll command
   described in [RFC5730].  Service messages may include notifications
   about events affecting client resources (such as transfer requests,
   expiration warnings, or administrative actions), system
   announcements, or other server-initiated communications.

   In order to enable effective and unambiguous processing of the
   messages, the data model of a message defines metadata fields with a
   type of a message and extension or a profile used to produce it.

   RPP defines message queue resources that clients can access to
   discover and retrieve pending service messages.  The baseline
   interaction pattern follows a read-first/acknowledge-delete approach:

   1.  The client queries the message queue resource to retrieve the
       first available message.

   2.  The client processes the message content.

   3.  The client explicitly acknowledges the message through a DELETE
       operation, removing it from the queue.  This step can optionally
       be optimised to execute together with step 1 for the following
       message.

   In order to assure idempotency and proper processing in case of
   concurrent clients, each service message carries a unique message id,
   which allows clients to assure the correct message is acknowledged
   and deleted in step 3.

   RPP offers separate queues per message type, so that clients may
   split the workload to several specialised readers, however a unified
   queue of all messages is offered for convenience and EPP
   compatibility.








Kowalik & Wullink        Expires 31 August 2026                [Page 21]

Internet-Draft            ietf-rpp-architecture            February 2026


   The baseline mechanism may be extended through message filtering,
   where clients may apply filters using query parameters when querying
   the message queue to retrieve only messages matching specific
   criteria.  This feature might be useful to peek messages related to a
   certain object without need to process the whole queue.

   The design of message partitioning in separate queues and filters
   must assure processing order of related or interdependent messages,
   so that the client can reconstruct a consistent state of an object at
   all times.

   Information about unread messages may be delivered as a custom HTTP
   header with each queue response.  Such header can be also added to
   other responses (for example with the first response after the queue
   state change or every n-th response or time based) in order to give a
   hint to the client about unread messages, however possible negative
   impact on server operation and performance shall be taken into
   account.

   The design of end points to retrieve/acknowledge/delete service
   messages shall assure further extensibility to optionally allow
   operation on multiple messages in a single request, reducing round
   trips for clients with many pending messages.

   The architecture does not address service message streaming or other
   push-based approaches to message delivery, however these solutions
   can be added at any time later without changes to the base mechanisms
   described above.

5.1.16.  RPP specific status codes and relation to HTTP response status
         codes

   RPP uses a dual-layer approach for signalling operation outcomes,
   leveraging both standard HTTP response status codes and RPP-specific
   status codes.  This allows for compatibility with generic HTTP
   components while providing detailed, application-level feedback for
   RPP clients.

   *  The HTTP response status code [RFC7231] must be used to convey the
      overall outcome of an operation.  Any HTTP-aware component, such
      as a proxy or monitoring tool, can determine if a request was
      successful (2xx), resulted in a client error (4xx), or a server
      error (5xx) by inspecting the HTTP response status code alone.

   *  RPP-specific status codes, transmitted in a dedicated HTTP header,
      must be used to provide granular, application-level information
      about the operation's result.




Kowalik & Wullink        Expires 31 August 2026                [Page 22]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  RPP responses must include both an HTTP response status code and
      an RPP-specific status code, however in some cases request
      handling may be terminated already on HTTP level, for example due
      malformed HTTP message, in such cases only HTTP response status
      code will be present.

   *  RPP-specific status codes should be mapped to the most
      semantically appropriate HTTP response status code.  For example,
      an RPP status code indicating "object already exists" during a
      creation attempt should map to HTTP 409 (Conflict), while a code
      for "object does not exist" during a lookup should map to HTTP 404
      (Not Found).  If no specific HTTP response status code is a good
      semantic fit, a generic code (e.g., 400 for a general client-side
      business rule failure, 200 for a successful operation with
      additional information) should be used.

   *  This mechanism applies to both successful and unsuccessful
      operations.  A successful response (e.g., HTTP 200 OK) may include
      an RPP-specific header to provide additional information, such as
      warnings, deprecation notices, or details about a partial success.

   *  In the case of an error, the response body should contain a
      machine-readable problem details document [RFC9457] to provide
      further information about the error.

   *  RPP status codes should be categorised as either temporary or
      permanent to guide client retry behaviour.

   *  RPP should also use other standardised HTTP signaling mechanisms
      where appropriate, for example for rate limiting.

5.1.17.  Transaction tracing and idempotency

   RPP shall support identification of requests and responses on both
   client side and server side with use of client provided identifiers
   and server provided identifiers.  This will allow for tracking of
   requests and responses in case of errors, and for idempotency of
   requests.

   Client provided identifier shall be returned in the corresponding
   synchronous response and shall be included in the asynchronous
   responses.  This identifier shall be also used as idempotency
   identifier to allow clients to retry requests without risk of
   duplicate processing.  The client provided identifier shall be unique
   for the client and the lifetime of the identifier shall be defined by
   the server, typically for a limited time after the request was
   processed.




Kowalik & Wullink        Expires 31 August 2026                [Page 23]

Internet-Draft            ietf-rpp-architecture            February 2026


   Server shall always generate own unique transaction identifier,
   regardless of nature of the transaction (reading or changing).

   The transmission of transaction identifiers should be defined outside
   of the Data Representation Layer (e.g. as HTTP Headers), to assure
   clear separation of resource representation from performed actions.
   If possible existing mechanisms of HTTP shall be employed.

5.1.18.  Message verification

   RPP may optionally support the creation and verification of digital
   signatures to provide an additional layer of protection by enabling
   the client and server to verify message integrity and authenticity.
   The mechanism for signing and verification of a message is described
   in [RFC9421].  Clients must provide their cryptographic public
   key(s), used for signing requests, to the RPP server operator via an
   out-of-band process.  The server, in turn, will publish its public
   keys, used for signing responses, through the RPP capabilities
   discovery mechanism.

5.1.19.  Protocol Versioning

   RPP will define a versioning schema for the protocol itself, the
   extensions and other protocol elements such as profiles as
   appropriate.  The versioning schema shall on one side allow for
   independent introduction of new features in a non-breaking manner on
   both client and server side, and on the other side allow the opposite
   party of the communication to determine if the version is compatible
   or not.  One of potential approaches having this property might be
   use of Semantic Versioning [SemVer], but also other versioning schema
   shall be possible.

   Signalling of the versions will be preferably realised using
   parameters of the media type.

5.1.20.  Profiles

   In real operational conditions different RPP server operators may
   have different requirements regarding set of protocol elements and
   their versions necessary to be supported by the client to enable
   reliable communication.  Such requirements may also be defined by
   external policies.  For this purpose RPP will define a concept of
   profiles, being identifiers translated into a certain minimum
   configuration of protocol version, extensions and their versions.
   The profiles themselves will be versioned in the same way as other
   protocol elements.  Commonly used profiles may be published in a
   dedicated IANA registry to promote reuse of profiles.  A client or
   server will use the IANA identifier for a profile to indicate support



Kowalik & Wullink        Expires 31 August 2026                [Page 24]

Internet-Draft            ietf-rpp-architecture            February 2026


   for the profile.

   RPP may define a machine-readable definition of profiles to allow
   automatic processing by the clients, but may also refer to other
   forms of profile specification.

   Signalling of the profiles will be preferably realised using
   parameters of the media type.

5.1.21.  Definition of special resources

   RPP may define special resources for specific purposes:

   *  Service Discovery endpoints to advertise protocol capabilities and
      supported features (see Section 5.1.22).

   *  Metadata endpoints to provide schema information or other
      protocol-level metadata, potentially including OpenAPI definitions
      for documentation and code generation.

5.1.22.  Service discovery mechanisms

   RPP defines mechanisms for service discovery, allowing clients to
   dynamically discover RPP service endpoints, capabilities, and
   operational policies.  This reduces coupling between clients and
   servers and enables clients to adapt to server configurations without
   hard-coded assumptions.  Service discovery is used to bootstrap the
   communication between client and server, its capabilities, and
   operational policies.

5.1.22.1.  Service location bootstrapping

   In order to discover the location of RPP services for a given TLD or
   other kind of registry RPP may employ publishing bootstrapping
   information in IANA registry backed with an API (similar to RDAP
   bootstrapping as per [RFC9224] or special DNS TXT resource records.

5.1.22.2.  Service discovery document

   The service discovery document is a machine-readable resource that
   describes a server's capabilities, supported features, and
   operational policies.  Clients retrieve this document to understand
   how to interact with the server and what behaviour to expect.  The
   document includes:

   *  Supported protocol versions, extensions, and available resource
      types.




Kowalik & Wullink        Expires 31 August 2026                [Page 25]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  Supported authentication methods and security requirements.

   *  IDN policies and handling conventions.

   *  Maintenance notices, informing clients about scheduled service
      unavailability.

   *  Data privacy policies, including information about data collection
      (what personal or sensitive data is collected and for what
      purposes), data retention (how long data is stored), and privacy
      practices (how data is protected and with whom it may be shared).

   *  URI templates [RFC6570] for advertised resource endpoints,
      allowing clients to navigate directly to known resources without
      additional server queries and without hard-coding URLs.

   *  Cryptographic key(s) used by the server for signing responses,
      which clients may use as an additional check for verification of
      response authenticity.

   *  Links to external resources related to the server or its
      operational context, such as release notes, change logs, or policy
      documents.

   By default the document will be published using well-known URIs
   [RFC8615] (e.g., /.well-known/rpp-capabilities) for retrieving
   service discovery documents.  In order to improve scalability it is
   worth considering to distribute discovery endpoints per resource type
   (e.g., /domains/.well-known/rpp-capabilities) instead of a single
   registry-wide endpoint.

5.1.22.3.  Discovery document freshness

   The server configuration is considered static between its
   reconfigurations and is not used for dynamic purposes such as load
   balancing.  RPP therefore defines a versioning mechanism for the
   service discovery document to allow clients to detect when the
   document has changed.  To minimise unnecessary re-fetching, both
   parties signal the version they are operating with: the client
   indicates the version of the discovery document it currently holds,
   and the server signals the current version in its responses.  This
   mutual version signalling allows the server to detect when a client
   is operating with a stale document and prompt it to retrieve an
   updated version.  Where a new version introduces breaking changes or
   deprecates features, the server may additionally warn the client in
   advance before the change takes effect.





Kowalik & Wullink        Expires 31 August 2026                [Page 26]

Internet-Draft            ietf-rpp-architecture            February 2026


5.1.23.  Scalability

   RPP leverages HTTP, enabling the use of standard web scalability
   techniques such as load balancing, horizontal scaling, and
   distributed caching.  Stateless interactions allow requests to be
   handled independently, facilitating distribution across multiple
   servers and rapid scaling in response to demand.  RPP shall enable by
   design existing web security and mitigation mechanisms to defend
   against attacks such as Denial of Service (DoS).

5.2.  Data Representation Layer

   This layer focuses on the data representation of RPP messages.  It
   defines the media type used to carry RPP data and supports various
   data representation formats.

5.2.1.  Data structure

   RPP will define the overall structure of the message payload carried
   by the chosen media type.  By default one data structure will be
   defined, however RPP should be able to support multiple data
   structures, especially for compatibility with EPP and other
   standards.

   *  *'RPP' Structure:* Defining a new, dedicated data structure
      specifically for RPP messages.  This would be the default in core
      specifications.

   Other future possibilities:

   *  *'EPP' Structure Adaptation:* Reusing or adapting to the existing
      EPP XML schemas, to maintain data model compatibility with EPP
      core objects and simplify mapping from EPP.

   *  *'JSContact' Structure Adaptation:* Adapting to the existing JSON
      representation for Contact Information [RFC9553], to maintain
      alignment with RDAP.

   *  *'VC' Structure Adaptation:* Adapting to existing Verifiable
      Credentials ([W3C-VC], [SD-JWT]) data structures, especially for
      representing identity or authorisation information, allowing for
      integration with external identity systems.

5.2.2.  Data format

   The primary format for RPP data representations shall be JSON,
   however RPP should be able to be extended to support other formats
   like XML, JWT, JWT-SD or CBOR.



Kowalik & Wullink        Expires 31 August 2026                [Page 27]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  *JSON:* Standard JSON format [RFC8259].

   *  *XML:* eXtensible Markup Language [XML] (considered for potential
      compatibility with EPP).

   *  *JWT:* JSON data encapsulated within a JSON Web Token [RFC7519]
      for potential use-cases when verifiable data consistency is
      required

   *  *JWT-SD:* JSON data with Selective Disclosure using JWTs [RFC9901]
      for minimisation of exposed data.

   *  *CBOR:* Concise Binary Object Representation for specific use
      cases requiring compact binary encoding [RFC8949].

   Some data formats can be optionally represented in other
   encapsulations, for example JSON data can be represented also in JWT
   or CBOR.  Change of encapsulation shall not affect the data
   structure.  This might be beneficial if RPP is to be extended to
   support different data formats in the future that only require
   additional properties provided by encapsulation, like signing,
   encryption or binary representation.

5.2.3.  Data Validation

   Data structures and formats will be described using a schema
   language, such as JSON Schema, OpenAPI, CDDL or other appropriate
   stable and open standard for JSON data structures.  It will enable
   data validation to be performed by both client and servers on
   received requests and responses.  For example, JSON Schema can define
   the expected structure of a domain object, including required fields
   and data types, allowing clients to validate their requests before
   sending them and servers to ensure incoming data conforms to the
   expected format.  The schemas must support both strict and lenient
   processing of requests and responses and support protocol
   extensibility.

5.2.4.  Media Type definition

   Together data structure and data format would define the whole media
   type.  So "application/rpp+json" would be the primary media type with
   "rpp" payloads in plain json format. "application/epp+xml" would be
   epp payload as per [RFC5730].








Kowalik & Wullink        Expires 31 August 2026                [Page 28]

Internet-Draft            ietf-rpp-architecture            February 2026


5.2.5.  Optionality

   The result of a RPP operation may result in an empty HTTP message
   body when mapped to a representation, for example a check for
   existence is allowed return only HTTP and RPP headers to indicate the
   result of the executed operation.

5.3.  Resource Definition Layer

   Each resource type, no matter if on a top level, being an independent
   provisioning object, or a subresource, being a part of another
   resource, shall be well defined including data elements and possible
   operations.  A resource definition shall on the first level of
   abstraction be composable out of data elements, without any reference
   to the media type or representation.  This will allow for easy
   extensibility and compatibility with different media types.

   All resource types shall be defined in IANA registry in a way that
   allows fully automated processing of the resource definition,
   including data elements, operations and media type representation.

5.3.1.  Data Elements

   This part defines logical data elements for each resource type, which
   can also be re-used across resource types.  It is abstracted from the
   actual transport and media type, focusing on the structure and
   constraints of data elements.  Data element definition includes:

   *  Identification of logical data units (e.g. a stable identifier of
      a data element, which is independent of the representation)

   *  Definition of logical data units (e.g., domain name, contact
      details)

   *  Format and schema for primitive data elements or reference to
      other resource type definitions

   *  Definition of container elements, which are logical groupings that
      can encapsulate zero or more data elements or other containers.
      Container types include ordered lists (e.g., a sequence of
      nameservers) and maps (e.g., key-value pairs for extension data).
      The representation of container elements in specific data formats
      is defined by the mapping layer.

   *  Constraints on data elements (e.g., data type, length, allowed
      values)

   *  Mechanisms for extensibility, if applicable



Kowalik & Wullink        Expires 31 August 2026                [Page 29]

Internet-Draft            ietf-rpp-architecture            February 2026


   Data elements shall be defined in IANA registry in a way that allows
   for automated processing of the data element definition, including
   constraints and references to other data elements.

5.3.1.1.  Required and Optional Data Elements

   RPP Core specifications define the data elements that are required
   for the technical provisioning and maintenance of objects as required
   at the protocol level.  Other defined data elements are optional at
   the protocol level.

   Servers may designate any protocol-optional data element as mandatory
   according to their local server policy.  Such server-specific
   requirements are communicated to clients through profile definitions
   or service discovery mechanisms.

5.3.2.  Relationships

   Resource types can define explicit relationships (links) to other
   resource types, supporting flexible cardinality-including one-to-one,
   one-to-many, and many-to-many associations.  This enables robust
   modelling, navigation, and management of complex, interconnected
   resources within RPP.  A relationship must also be able to define its
   own properties or attributes, such as type of relationship or other
   kind of metadata assigned to the relation link itself rather than an
   object on any side of relation.

5.3.3.  Mapping

   This layer defines the mapping of Data Elements onto the Data
   Representation Layer.  For example in case of "application/rpp+json"
   media type, the mapping layer would define how the logical data units
   are represented in JSON format.

   This additional level of indirection would allow usage of data
   formats defined outside of rpp specifications - for example usage of
   Verifiable Credentials or Verifiable Presentations as first class
   resource types for contacts in RPP, and mapping appropriate data
   elements.

   The mapping layer shall be defined in IANA registry in a way that
   allows for automated processing of the mapping definition, including
   reading and writing operations.  Mechanisms, such as defined for
   JavaScript Object Notation (JSON) Patch [RFC6902], may be used to
   define the mapping.






Kowalik & Wullink        Expires 31 August 2026                [Page 30]

Internet-Draft            ietf-rpp-architecture            February 2026


5.3.4.  Operations

   Each resource type shall define operations possible on this resource
   type.  This may encompass any of the mechanisms defined on the HTTP
   transport layer.

   Operations shall be defined in IANA registry in a way that allows for
   automated processing of the operation definition, including
   constraints and references to other resource types.

5.3.5.  Server-Managed Resource Types

   As mentioned in Section 5.1.7, RPP supports server-managed resources
   as first-class resource types.  These resources are defined using the
   same mechanisms as client-provisioned resources, including data
   elements, mappings, and IANA registry entries.  The distinction lies
   in the permitted operations: server-managed resource types restrict
   operations to read-only access (GET, HEAD).

   Examples of server-managed resource types include:

   *  Registry policy information (e.g., supported TLDs, pricing,
      registration rules)

   *  Server operational status and health information

   *  Statistics

   Server-managed resources may expose logically associated information
   as sub-resources.

   A special class of server managed resources would represent
   provisioning objects, which cannot be modified by any external
   client, but rather are managed by server operator.  From the external
   client view those resources would be read-only, however the server
   might actually implement modifying operations to those objects
   available only to internal clients and tools, controlled by
   authorisation mechanisms.

5.3.6.  Data privacy

   RPP request and response representations may contain personal data or
   other sensitive information subject to privacy regulations.  The
   architecture incorporates mechanisms that enable implementations to
   adhere to data privacy principles such as data minimisation and
   purpose limitation.





Kowalik & Wullink        Expires 31 August 2026                [Page 31]

Internet-Draft            ietf-rpp-architecture            February 2026


   Data minimisation is supported through the protocol's design
   principle that only strictly necessary data elements are required at
   the protocol level (see Section 5.3.1).  Servers may further
   constrain which elements are required through profile definitions.
   The Prefer header mechanism (see Section 5.1.21) allows clients to
   request minimal representations, and Fine-Grained Authorisation (see
   Section 5.1.3.2) and Object level authorisation (see Section 5.1.3.6)
   enable servers to return only the data a client is authorised to
   access.

   Purpose limitation is supported through multiple mechanisms.  Data
   element definitions may include purpose attributes, indicating the
   specific processing purposes for which each element is intended.
   Authorisation scopes (see Section 5.1.2) can be defined to restrict
   access to data elements based on their declared purpose, ensuring
   that clients only receive data relevant to their authorised use.  The
   service discovery document (see Section 5.1.22) advertises data
   collection purposes, allowing clients to understand how their data
   will be used and retained before submission.

5.4.  Extension mechanisms

   The RPP architecture is designed to be extensible, allowing for the
   addition of new resource types, data elements, and operations without
   breaking existing implementations while maintaining interoperability
   and stability.  This enables RPP to integrate with emerging
   technologies and support a wide range of provisioning scenarios.

5.4.1.  Layered Extensibility

   The layered design ensures that each architectural layer (HTTP
   Transport, Data Representation, Resource Definition) is defined
   independently, allowing new features or technologies to be introduced
   at one layer without impacting others.  This separation enables
   focused extension of specific protocol aspects and preserves overall
   coherence.

5.4.2.  Protocol Element Extension

   Extensions may introduce new protocol elements at various levels of
   granularity:

   *  New resource types and server-managed resource types with their
      complete definitions

   *  Additional data elements that can be incorporated into existing or
      new resource types




Kowalik & Wullink        Expires 31 August 2026                [Page 32]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  New operations on existing resources, including process sub-
      resources

   *  Additional parameters for existing operations

   *  Additional result information in operation responses

   *  New RPP status codes with their mappings to HTTP response status
      codes

   *  New HTTP headers for conveying RPP-specific data structures or
      control signals

5.4.3.  IANA Registry-Based Discovery

   Resource types, data elements, mappings, and operations are
   registered in IANA registries using machine-readable formats.  This
   enables automated processing, discovery, and extension of protocol
   elements without requiring changes to the core specifications.
   Extensions must be registered with IANA to facilitate standardisation
   and reuse.  These registration requirements are fine-grained,
   applying independently to protocol elements such as resource types,
   data elements, operations, and status codes.  This approach promotes
   consistency and interoperability, avoids fragmentation from
   conflicting definitions, and allows protocol elements to evolve
   independently.

5.4.4.  Compatibility and Profiles

   Compatibility profiles can be defined to support subsets of RPP for
   specific use cases, such as EPP compatibility profiles that enable
   gradual migration or interoperability scenarios.  Service discovery
   endpoints and content negotiation mechanisms allow clients and
   servers to dynamically discover and utilise new capabilities,
   resource types, and representations as they are introduced.

5.4.5.  Name Management and Collision Avoidance

   RPP extensions MUST define unique names for all extension elements to
   prevent conflicts with other extensions and with core protocol
   elements.  These names are used consistently in resource identifiers,
   data element identifiers, and URL path segments.

   Standardised RPP extensions MUST register their names in a dedicated
   IANA registry for RPP extensions to ensure global uniqueness and
   avoid collisions.  Private (non-standardised) extensions are also
   required to use unique names, but are not required to register with
   IANA.  This allows private extensions to be developed and used within



Kowalik & Wullink        Expires 31 August 2026                [Page 33]

Internet-Draft            ietf-rpp-architecture            February 2026


   specific implementations or organisations without impacting the
   global RPP ecosystem.  Private extensions should use names that are
   unlikely to conflict with other extensions or with RPP core elements,
   for example by using reverse domain notation as a prefix (e.g.,
   org.example.rpp).

   This naming mechanism ensures that new resource types, data elements,
   and operations can be introduced independently and safely, supporting
   the extensibility goals of the RPP architecture while maintaining
   interoperability and clarity across implementations.

5.4.6.  Extension Security

   Extensions operate within the same security architecture as the core
   protocol.  Security, authentication, and authorisation mechanisms
   defined at the HTTP Transport Layer (see Section 5.1.2) apply
   uniformly to both core protocol operations and all extensions.  This
   "security by design" approach is aimed to ensure that extensions
   cannot bypass or weaken the security posture established by the core
   protocol.  Extensions must not introduce new authentication or
   authorisation mechanisms that circumvent or conflict with those
   defined by the core specifications.

5.4.7.  Extension Review

   Before any extension is accepted by IANA, a review by an RPP expert
   must be performed.  This review includes verification that the
   extension does not violate any of the RPP security considerations and
   that it correctly integrates with the protocol's security framework.
   The complete review criteria will be included in the "IANA
   Considerations" section of any document describing RPP extension
   mechanisms, according to the BCP described in [RFC8126].

6.  IANA Considerations

   This document defines the architecture for the RPP and requires no
   actions by IANA.

   All references to potential IANA registrations in this document, such
   as media types, extension registries, or other protocol artefacts,
   are strictly informational.  They describe design considerations and
   anticipated future needs of the RPP protocol.  Any actual IANA
   actions resulting from the RPP protocol will be requested in
   standards-track protocol specification documents that define the
   concrete protocol elements.

7.  Change History




Kowalik & Wullink        Expires 31 August 2026                [Page 34]

Internet-Draft            ietf-rpp-architecture            February 2026


7.1.  -00 to -01

   *  Extension Mechanisms

      -  Refactoring of Extension mechanisms Section and addition of
         extensibility with transient request parameters and responses
         (Issues #94 and #95)

      -  Added HTTP Headers to the "extension-mechanisms" section (Issue
         #93).

      -  Added Extension Security and Extension Review Sections to
         Section 5.4 (Issue #91).

   *  Service Discovery & Profiles

      -  Added data privacy to Service discovery mechanisms and new
         "Data privacy" section.  Refactored the whole section
         Section 5.1.22 (Issue #100).

      -  Added Advertising of maintenance notices to "Service Discovery"
         section.  (Issue #88)

      -  Added text about compatibility profiles to "Profiles" section.
         (Issue #29)

   *  Collections, Bulk Operations & Filtering

      -  Added Section Collection Representation for API-level
         collection retrieval and expanded container element description
         in Data Elements Section.  (Issue #85)

      -  Extended Collection Representation to clarify that bulk
         operations, listing, and filtering are optional and must not be
         mandated where they negatively impact scalability or
         performance (Issue #41).

   *  Security & Authentication*

      -  Added "additional measures to verify the client" to
         Section 5.1.3.4 (Issue #76).

      -  Added TLS mandatory to Section 5.1.1 (Issue #78).

      -  Create "Credential management" section for updating credentials
         using an extension.





Kowalik & Wullink        Expires 31 August 2026                [Page 35]

Internet-Draft            ietf-rpp-architecture            February 2026


      -  Added Section Section 5.1.3.5 for credential and token
         revocation/replacement mechanisms (Issue #79).

      -  Added text about signing messages in the "Message verification"
         section.  (Issue #33)

      -  Added reference to RFC9154 in the "Object level authorisation"
         section.  (Issue #89)

   *  HTTP Layer

      -  Added "Canonical Addressing" section (Issue #81)

      -  Added "Optionality" section to explicitly allow empty HTTP
         message body in a response (Issue #97).

      -  Fixed inconsistent usage of HTTP status codes (Issue #108).

   *  Resource Definition & Data Model

      -  Added a "Relationships" section to describe resource type
         relationships.  (Issue #83)

      -  Added Section Required and Optional Data Elements to Data
         Elements to explicitly address protocol-level vs. server-
         policy-level data element requirements (Requirement R4.3).

      -  Added Server-Managed Resources Section to HTTP Transport Layer
         Details and Server-Managed Resource Types Section to Resource
         Definition Layer to define read-only server-managed resources
         (Issue #84).

      -  Explicitly state that all parties involved in a process are
         allowed to retrieve the process status.  (Issue #98)

      -  Added Section Section 5.1.15 to describe poll message
         equivalent (Issue #87).

   *  Protocol Behaviour

      -  Changed default validation from lenient to strict.  (Issue #82)

      -  Added "Scalability" section.  (Issue #92)

   *  Editorial & Terminology

      -  Added IDN to "Terminology" and "Service discovery mechanisms"
         sections



Kowalik & Wullink        Expires 31 August 2026                [Page 36]

Internet-Draft            ietf-rpp-architecture            February 2026


      -  Added boilerplate IANA Considerations section

      -  Editorial: updated document references

7.2.  -03 to draft-ietf-rpp-architecture-00

   *  No changes.  Document adopted by RPP WG.

7.3.  -02 to -03

   *  split into HTTP built-ins and custom RPP in Section 4.2.1.
      Reorganised Section 5.1 to reflect that and added/rewritten some
      parts to cover all aspects.

   *  Clarified the relationship and mapping between HTTP response
      status codes and RPP-specific status codes in Section 5.1.16.

   *  Added paragraph on promotion of standard extensions to
      Section 5.4.

   *  Fixed broken references to non-RFC documents

   *  Explicitly stated that RPP SHOULD support client_id/password
      authentication for EPP compatibility in Section 5.1.2.

7.4.  -01 to -02

   *  Added responses must contain links to relevant object to
      Section 5.1.4

   *  Added round trip minimisation principle to Section 5.1.22

   *  Added description of lenient versus strict request validation to
      Section 4.2.3.

   *  Added description of asynchronous handling to Section 4.2.1 and
      Section 5.1.

   *  Added Operation Singularity to Section 4.1.

   *  Added Versioning chapter to Section 5.1.

   *  Added Profiles chapter to Section 5.1.

   *  Added Security section to Section 5.1.2.

   *  Added Relationship between clients and authentication credentials
      to Section 5.1.2.



Kowalik & Wullink        Expires 31 August 2026                [Page 37]

Internet-Draft            ietf-rpp-architecture            February 2026


   *  Add Data Validation (Section 5.2.3) section with schema language
      support for RPP to Section 5.2

   *  Added Name Management and Collision Avoidance section to
      Section 5.4.

   *  Added Section about dereferenced related object representation to
      Section 5.1.21.

7.5.  -00 to -01

   *  Removed requirements and replaced with a reference to RPP WG

   *  Encapsulation removed as a primary extension point and part of
      architecture

   *  Added reference to JSContact as a possible contact representation

   *  Added HEAD verb to basic operations

   *  Updated RPP specific status codes and relation to HTTP response
      status codes

   *  Added Extension mechanisms section to Protocol Details

8.  References

8.1.  Normative References

   [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
              for HTTP APIs", IETF, DOI 10.17487/RFC9457, RFC 9457, July
              2023, <https://www.rfc-editor.org/info/rfc9457>.

   [RFC9110]  Fielding, R., Nottingham, M., and J. Reschke, "HTTP
              Semantics", IETF, DOI 10.17487/RFC9110, BCP 97, RFC 9110,
              June 2022, <https://www.rfc-editor.org/info/rfc9110>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", IETF, DOI 10.17487/RFC8446, RFC 8446, August
              2018, <https://www.rfc-editor.org/info/rfc8446>.

8.2.  Informational References

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              IETF, DOI 10.17487/RFC5730, BCP 69, RFC 5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.





Kowalik & Wullink        Expires 31 August 2026                [Page 38]

Internet-Draft            ietf-rpp-architecture            February 2026


   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", IETF, DOI 10.17487/RFC5731, BCP 69,
              RFC 5731, August 2009,
              <https://www.rfc-editor.org/info/rfc5731>.

   [RFC5732]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", IETF, DOI 10.17487/RFC5732, BCP 69,
              RFC 5732, August 2009,
              <https://www.rfc-editor.org/info/rfc5732>.

   [RFC5733]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", IETF, DOI 10.17487/RFC5733, BCP 69,
              RFC 5733, August 2009,
              <https://www.rfc-editor.org/info/rfc5733>.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", IETF,
              DOI 10.17487/RFC7231, RFC 7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7240]  Snell, J., "Prefer Header for HTTP", IETF,
              DOI 10.17487/RFC7240, RFC 7240, June 2014,
              <https://www.rfc-editor.org/info/rfc7240>.

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", IETF, DOI 10.17487/RFC8259, BCP 90,
              RFC 8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8288]  Nottingham, M., "Web Linking", IETF, DOI 10.17487/RFC8288,
              RFC 8288, October 2017,
              <https://www.rfc-editor.org/info/rfc8288>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", IETF,
              DOI 10.17487/RFC6570, RFC 6570, March 2012,
              <https://www.rfc-editor.org/info/rfc6570>.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", IETF,
              DOI 10.17487/RFC6749, RFC 6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", IETF,
              DOI 10.17487/RFC6750, RFC 6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.





Kowalik & Wullink        Expires 31 August 2026                [Page 39]

Internet-Draft            ietf-rpp-architecture            February 2026


   [RFC7009]  Dronia, S., Scurtescu, M., and T. Lodderstedt, "OAuth 2.0
              Token Revocation", IETF, DOI 10.17487/RFC7009, RFC 7009,
              August 2013, <https://www.rfc-editor.org/info/rfc7009>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", IETF, DOI 10.17487/RFC7519, RFC 7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", IETF, DOI 10.17487/RFC9082,
              BCP 95, RFC 9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

   [RFC6902]  Bryan, P. and M. Nottingham, "JavaScript Object Notation
              (JSON) Patch", IETF, DOI 10.17487/RFC6902, RFC 6902, April
              2013, <https://www.rfc-editor.org/info/rfc6902>.

   [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", IETF, DOI 10.17487/RFC9396,
              RFC 9396, May 2023,
              <https://www.rfc-editor.org/info/rfc9396>.

   [RFC9205]  Nottingham, M., "Building Protocols with HTTP", IETF,
              DOI 10.17487/RFC9205, BCP 56, RFC 9205, June 2022,
              <https://www.rfc-editor.org/info/rfc9205>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", IETF, DOI 10.17487/RFC8949,
              BCP 94, RFC 8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC9553]  Stepanek, R. and M. Loffredo, "JSContact: A JSON
              Representation of Contact Data", IETF,
              DOI 10.17487/RFC9553, RFC 9553, May 2024,
              <https://www.rfc-editor.org/info/rfc9553>.

   [RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",
              IETF, DOI 10.17487/RFC7617, RFC 7617, September 2015,
              <https://www.rfc-editor.org/info/rfc7617>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", IETF,
              DOI 10.17487/RFC8126, BCP 26, RFC 8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.







Kowalik & Wullink        Expires 31 August 2026                [Page 40]

Internet-Draft            ietf-rpp-architecture            February 2026


   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              IETF, DOI 10.17487/RFC5890, RFC 5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", IETF, DOI 10.17487/RFC8615, RFC 8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC9224]  Blanchet, M., "Finding the Authoritative Registration Data
              Access Protocol (RDAP) Service", IETF,
              DOI 10.17487/RFC9224, BCP 95, RFC 9224, March 2022,
              <https://www.rfc-editor.org/info/rfc9224>.

   [RFC9901]  Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JSON Web Tokens", IETF,
              DOI 10.17487/RFC9901, RFC 9901, November 2025,
              <https://www.rfc-editor.org/info/rfc9901>.

   [RFC9154]  Gould, J. and R. Wilhelm, "Extensible Provisioning
              Protocol (EPP) Secure Authorization Information for
              Transfer", IETF, DOI 10.17487/RFC9154, RFC 9154, December
              2021, <https://www.rfc-editor.org/info/rfc9154>.

   [RFC9421]  Sporny, M., Backman, A., and J. Richer, "HTTP Message
              Signatures", IETF, DOI 10.17487/RFC9421, RFC 9421,
              February 2024, <https://www.rfc-editor.org/info/rfc9421>.

   [SD-JWT]   Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
              Verifiable Credentials (SD-JWT VC)", November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              sd-jwt-vc-13>.

   [RPPReq]   Wullink, M. and P. Kowalik, "RESTful Provisioning Protocol
              (RPP) - Requirements", December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rpp-
              requirements-03>.

   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", REC-xml-20081126, November 2008,
              <https://www.w3.org/TR/2008/REC-xml-20081126/>.

   [SemVer]   "Semantic Versioning 2.0.0", Misc SemVer 2.0.0,
              <https://semver.org/spec/v2.0.0.html>.






Kowalik & Wullink        Expires 31 August 2026                [Page 41]

Internet-Draft            ietf-rpp-architecture            February 2026


   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures",
              Doctoral Dissertation University of California, Irvine,
              September 2000,
              <http://roy.gbiv.com/pubs/dissertation/top.htm>.

   [OpenAPI]  "OpenAPI Specification", Misc OpenAPI,
              <https://swagger.io/specification/>.

   [W3C-VC]   Sporny, M., Longley, D., Chadwick, D., Herman, I., Sporny,
              M., Thibodeau, T., Herman, I., Cohen, G., and M. Jones,
              "Verifiable Credentials Data Model v2.0", vc-data-model-
              2.0, <https://www.w3.org/TR/vc-data-model-2.0/>.

Authors' Addresses

   P Kowalik
   DENIC eG
   Theodor-Stern-Kai 1
   Frankfurt am Main
   Germany
   Email: pawel.kowalik@denic.de
   URI:   https://denic.de


   M Wullink
   SIDN Labs
   Netherlands
   Email: maarten.wullink@sidn.nl
   URI:   https://sidn.nl/





















Kowalik & Wullink        Expires 31 August 2026                [Page 42]
