Secure Delegation Management for RESTful Provisioning Protocol (RPP)
draft-wullink-rpp-oauth2-delegation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Maarten Wullink , Paweł Kowalik | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | rpp at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wullink-rpp-oauth2-delegation-00
Network Working Group M. Wullink
Internet-Draft SIDN Labs
Intended status: Standards Track P. Kowalik
Expires: 7 January 2027 DENIC
6 July 2026
Secure Delegation Management for RESTful Provisioning Protocol (RPP)
draft-wullink-rpp-oauth2-delegation-00
Abstract
This document describes how OAuth 2.0 [RFC6749] enables a third
party, such as a DNS Operator, to manage delegation (name server)
details for a domain name on behalf of the registrant using the
RESTful Provisioning Protocol (RPP). It extends the RPP OAuth 2.0
authorization model defined in [I-D.wullink-rpp-oauth2] with
mechanisms specific to third-party delegation management via RPP
[I-D.ietf-rpp-core].
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wullink & Kowalik Expires 7 January 2027 [Page 1]
Internet-Draft Secure Delegation Management for RPP July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Authorization Request Details . . . . . . . . . . . . . . . . 5
6. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Delegation Management Flow . . . . . . . . . . . . . . . . . 8
10. Data Objects . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Internationalization Considerations . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
15. Change History . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13
16. Normative References . . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
*NOTE:* This is an early draft of how third-party delegation
management could work in RPP. It is provided to give an idea of the
possible delegation flow and to facilitate discussion. This document
is expected to be significantly revised and updated as the delegation
management flow and the security mechanisms are further developed and
refined.
In the Domain Name System, delegation refers to the assignment of
name servers responsible for a DNS zone. The registry holds
authoritative delegation data, specifically the name server (NS)
records and associated glue records for each domain name in its
database. Ordinarily, only the sponsoring registrar, acting on
behalf of the registrant, may update this data via the RPP API.
Wullink & Kowalik Expires 7 January 2027 [Page 2]
Internet-Draft Secure Delegation Management for RPP July 2026
An increasingly common operational pattern is for a registrant to
host its DNS with a dedicated DNS Operator that is not the sponsoring
registrar. When the registrant wants the DNS Operator to manage its
delegation settings, it is inconvenient and error-prone to require
the registrant to relay every change through the registrar or to
configure it manually using registrar-provided tools. Instead, a
possible solution is for the registrant to grant the DNS Operator
limited, revocable authority to update delegation data directly at
the registry using the RPP API.
This document defines a mechanism based on OAuth 2.0 federation that
enables this pattern securely and without any bilateral arrangement
between the DNS Operator and the registrar. The registrant
authenticates at the registrar's Authorization Server (AS) and grants
explicit, domain-scoped consent for the DNS Operator to manage
delegation data. The registrar's AS issues a signed access token
that the DNS Operator presents to the registry when submitting an RPP
domain update request.
2. Terminology
In this document the following terminology is used.
URL - A Uniform Resource Locator as defined in [RFC3986].
Resource - An object having a type, data, and possible relationship
to other resources, identified by a URL.
RPP server - An HTTP server responsible for processing requests and
returning results in any supported media type.
JWT - JSON Web Token as defined in [RFC7519].
Registrant - The holder of a registered domain name, who has an
account at the sponsoring registrar.
Registrar - The accredited sponsoring registrar for a domain name.
The registrar operates an Authorization Server and maintains
registrant accounts.
Registry - The authoritative operator of the top-level domain name,
operating the RPP server. The registry stores delegation data and
validates access tokens.
DNS Operator - A third party (not the registrar) that manages DNS
zones on behalf of registrants. The registrant has an account at the
DNS Operator. The DNS Operator uses the RPP API to update delegation
data at the registry.
Wullink & Kowalik Expires 7 January 2027 [Page 3]
Internet-Draft Secure Delegation Management for RPP July 2026
Authorization Server (AS) - An OAuth 2.0 authorization server,
operated by the registrar, that authenticates registrants and issues
access tokens authorizing third parties to act on their behalf.
3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
In examples, indentation and white space are provided only to
illustrate element relationships and are not REQUIRED features of the
protocol.
All example requests assume an RPP server using HTTP version 2 is
listening on the standard HTTPS port on host rpp.example. An
authorization token has been provided by an out-of-band process and
MUST be used by the client to authenticate each request.
4. Use Case
A registrant has registered foo.example through Registrar A and has
also signed up with DNS Operator B to host the DNS zones for
foo.example. The registrant wants DNS Operator B to be able to
update the name servers for foo.example in the registry database
without having to route every change through Registrar A.
The desired outcome is:
1. DNS Operator B can update delegation data (name servers and glue
records) for foo.example at the registry directly.
2. The authority is scoped to delegation management only, e.g. DNS
Operator B cannot modify registrant contact data, initiate
transfers, or perform any other operation.
3. The authority is granted explicitly by the registrant via an
interactive OAuth 2.0 flow at Registrar A's AS.
4. The registry can verify the authority independently, without
contacting Registrar A at request time.
5. The authority can be revoked by the registrant at any time, at
which point the registry will no longer accept tokens issued for
DNS Operator B.
Wullink & Kowalik Expires 7 January 2027 [Page 4]
Internet-Draft Secure Delegation Management for RPP July 2026
5. Authorization Request Details
OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] extends the
standard OAuth 2.0 authorization request with an
authorization_details parameter that carries a structured JSON object
describing precisely what the client is requesting authorization for.
Unlike scopes, which are coarse-grained string tokens,
authorization_details allows the request to include typed, fine-
grained authorization data, such as the specific domain name whose
delegation data is to be managed. The AS can present this
information to the registrant in a meaningful consent screen.
For the delegation management flow, the DNS Operator includes an
authorization_details object of type delegation in the authorization
request to the registrar's AS. The registrant sees exactly which
domain name they are consenting to allow the DNS Operator to manage.
The AS MUST echo the authorization_details object back as a claim in
the issued JWT, giving the registry verifiable, tamper-proof evidence
of what was authorized and for which domain name.
The type field MUST be set to delegation. Table Table 1 lists the
RAR fields defined for RPP delegation management.
+===================+========+=============+========================+
| Field | Type | Requirement | Description |
+===================+========+=============+========================+
| type | String | REQUIRED | MUST be delegation. |
+-------------------+--------+-------------+------------------------+
| object_type | String | REQUIRED | The RPP object type |
| | | | whose delegation data |
| | | | is to be managed. |
| | | | MUST be domain. |
+-------------------+--------+-------------+------------------------+
| object_identifier | String | REQUIRED | The unique identifier |
| | | | of the specific |
| | | | domain name whose |
| | | | delegation data is to |
| | | | be managed (e.g., |
| | | | foo.example). |
+-------------------+--------+-------------+------------------------+
Table 1: RPP Delegation Authorization, RAR authorization_details
object ([RFC9396])
Example RAR authorization_details value for managing delegation of
foo.example:
Wullink & Kowalik Expires 7 January 2027 [Page 5]
Internet-Draft Secure Delegation Management for RPP July 2026
[{
"type": "delegation",
"object_type": "domain",
"object_identifier": "foo.example"
}]
The registrar's AS MUST echo the authorization_details back as a
claim in the issued JWT. The registry MUST validate the
authorization_details claim in the token and MUST verify that
object_type and object_identifier match the domain name whose
delegation data is being updated.
When the registrar's AS does not support RAR ([RFC9396]), the
specific object being managed MUST be conveyed via the rpp_op_type,
rpp_object_type and rpp_object_identifier claims rather than encoded
in the authorization_details claim. The rpp_op_type claim MUST be
set to delegation. The rpp_object_type claim MUST be set to the RPP
object type being managed, for delegation type this MUST be domain.
The rpp_object_identifier claim MUST be set to the specific domain
name being managed (e.g., foo.example). The registry MUST validate
that these claim values match the domain name being managed.
6. Scopes
RPP OAuth 2.0 scopes are defined in [I-D.wullink-rpp-oauth2].
Delegation management introduces new delegation-specific scopes.
These scopes grant the bearer the right to read or update delegation
data (name servers and glue records) for a specific domain name, as
further constrained by the authorization_details claim.
Table Table 2 defines the new OAuth 2.0 scopes for Delegation
Management. Each scope grants a specific set of permissions on the
RPP domain name resource. The registry MUST enforce that the access
token presented in a delegation update request contains the
appropriate scopes for the requested operation.
+===================+=============+========================+
| Scope | Data Object | Operations Granted |
+===================+=============+========================+
| delegation:read | Domain Name | Read delegation data |
+-------------------+-------------+------------------------+
| delegation:update | Domain Name | Update delegation data |
+-------------------+-------------+------------------------+
Table 2: RPP OAuth 2.0 Scopes for Delegation Management
Wullink & Kowalik Expires 7 January 2027 [Page 6]
Internet-Draft Secure Delegation Management for RPP July 2026
7. Claims
The delegation management flow uses the same RPP-specific claims
defined in [I-D.wullink-rpp-oauth2]. No new claims are introduced
for delegation management.
8. Trust Model
The delegation management mechanism uses the registry as the central
trust anchor, operating as a hub-and-spoke topology. Registrars
establish a trust relationship with the registry during
accreditation. DNS Operators MUST also be pre-registered with the
registry in order to obtain access to the RPP API. No bilateral
arrangement between the DNS Operator and the registrar is required;
all delegation authority flows through the registrant's explicit
consent at the registrar's AS.
*Registry as trust anchor.* As part of registrar onboarding, each
registrar that operates its own AS (i.e., maintains registrant
accounts) MUST register its AS metadata with the registry. This
includes at minimum:
* The AS's authorization endpoint URI, used by the DNS Operator to
construct the consent redirect.
* The AS's JWKS endpoint URI or the public key material itself, used
by the registry to validate tokens issued by that AS.
* ...
The registry stores this metadata as part of the registrar's profile
and makes it available to approved DNS operators as part of the
delegation update flow.
*Token validation without bilateral trust.* When the registry
receives a delegation update request carrying a JWT issued by the
registrar's AS, it validates the token locally using the registrar's
AS public key that was registered at onboarding. No runtime call to
the registrar or its AS is required. The registry already trusts
that public key because it was registered through the accreditation
process.
Wullink & Kowalik Expires 7 January 2027 [Page 7]
Internet-Draft Secure Delegation Management for RPP July 2026
*DNS Operator.* The DNS Operator MUST be pre-registered with the
registry to gain access to the RPP API. This pre-registration grants
the DNS Operator the credentials necessary to query the RPP registrar
info endpoint (to look up the sponsoring registrar's AS URI for a
given domain) and to submit delegation update requests on behalf of a
registrant. The DNS Operator does not require any pre-existing
relationship with the registrar; the only registrar-side requirement
is that the registrar's AS accepts the DNS Operator's redirect_uri as
a valid OAuth 2.0 client redirect URI.
*Security properties.* This model provides the following guarantees:
* A rogue DNS Operator cannot forge a delegation token that the
registry will accept, because only the legitimate registrar's AS
public key (registered at onboarding) can produce a valid
signature.
* The DNS Operator cannot forge registrant consent, because the
token is issued by the registrar's AS after the registrant has
authenticated and approved the scope.
* The registry controls the set of trusted ASs by controlling which
registrar AS metadata it accepts at onboarding.
* DNS Operators need no knowledge of registrar internals beyond what
the registry exposes via the discovery endpoint. DNS Operators do
require pre-registration with the registry to access the RPP API,
but require no bilateral arrangement with any individual
registrar.
* Tokens are scoped to a single domain name and a specific set of
actions, limiting the impact of a compromised token.
9. Delegation Management Flow
The delegation management flow uses the OAuth 2.0 Authorization Code
grant Section 4.1 to obtain explicit, domain-scoped registrant
consent directly from the registrar's AS. The primary method for
conveying the authorization scope is Rich Authorization Requests
(RAR) [RFC9396].
Before redirecting the registrant, the DNS Operator MUST first query
the registry's discovery endpoint to resolve the sponsoring
registrar's AS authorization URI for the domain name. The sponsoring
registrar is identified from the domain name's current registrar data
in the registry.
The authorization request MUST convey the specific domain name and
the set of requested actions so that the registrar's AS can present
the registrant with an accurate consent screen.
Wullink & Kowalik Expires 7 January 2027 [Page 8]
Internet-Draft Secure Delegation Management for RPP July 2026
The following diagram illustrates the complete delegation management
flow:
Client DNS Operator Registry Registrar
(Registrant) (Trust Anchor) AS
| | | |
: --- Onboarding ---------------------------------- :
| | | |
| | 1. Register | |
| | DNS Operator | |
| | account | |
| +--------------->| |
| | | |
| | 2. Account | |
| | credentials | |
| | returned | |
| |<---------------| |
| | | |
| | | 3. Register AS |
| | | URI + JWKS pubkey|
| | |<-----------------|
| | | |
: --- Delegation management time ------------------- :
| | | |
| 4. Request | | |
| delegation | | |
| mgmt for | | |
| foo.example | | |
+-------------->| | |
| | | |
| | 5. Discover | |
| | Reg. AS URI | |
| | for domain | |
| +--------------->| |
| | | |
| | 6. AS URI | |
| | returned | |
| |<---------------| |
| | | |
| 7. Redirect | | |
| to Registrar | | |
| AS | | |
|<--------------| | |
| | | |
| 8. Auth & | | |
| approve | | |
| delegation | | |
| scope | | |
Wullink & Kowalik Expires 7 January 2027 [Page 9]
Internet-Draft Secure Delegation Management for RPP July 2026
+-------------------------------------------------->|
| | | |
| 9. Auth code | | |
| + redirect to | | |
| DNS Op | | |
| callback URI | | |
|<--------------------------------------------------|
| | | |
| 10. Follow | | |
| redirect | | |
| (auth code | | |
| delivered) | | |
+-------------->| | |
| | | |
| | 11. Exchange | |
| | auth code for | |
| | access token | |
| | (back-channel) | |
| +---------------------------------->|
| | | |
| | 12. JWT signed | |
| | by Registrar AS| |
| |<----------------------------------|
| | | |
| | 13. Delegation | |
| | update request | |
| | + Bearer JWT | |
| +--------------->| |
| | | |
| | | 14. Validate JWT |
| | | using cached Reg.|
| | | JWKS pubkey |
| | | (no runtime call)|
| | | |
| | | 15. Notify |
| | 16. Update. | Registrar |
| | result |----------------->|
| |<---------------| |
| | | |
| 17. Delegation| | |
| update | | |
| confirmed | | |
|<--------------| | |
| | | |
Figure 1: RPP Delegation Trust Model — Onboarding, Discovery, and
Token Flow
Wullink & Kowalik Expires 7 January 2027 [Page 10]
Internet-Draft Secure Delegation Management for RPP July 2026
The steps in the diagram are as follows:
1. During DNS Operator onboarding, the DNS Operator registers an
account with the registry to obtain API credentials. The
registry grants the DNS Operator access to the RPP API endpoints
needed for delegation management, including the registrar
discovery endpoint and the delegation update endpoint.
2. The registry returns the API credentials to the DNS Operator.
3. During registrar onboarding, the registrar registers its AS
authorization endpoint URI and JWKS public key material with the
registry. The registry stores this as part of the registrar's
profile.
4. The registrant asks the DNS Operator to manage delegation data
for foo.example.
5. The DNS Operator queries the registry's RPP registrar info
endpoint, providing the domain name, to look up the sponsoring
registrar's AS authorization URI.
6. The registry returns the sponsoring registrar's AS authorization
URI. If no AS URI is registered for the sponsoring registrar,
the delegation management flow cannot proceed and the DNS
Operator MUST inform the registrant that the registrar does not
support this mechanism.
7. The DNS Operator redirects the registrant's browser to the
registrar's AS with an authorization request that includes an
authorization_details parameter of type delegation with
object_type: "domain", object_identifier: "foo.example" (RAR,
[RFC9396]). The DNS Operator's callback URI MUST be included as
the OAuth 2.0 redirect_uri.
8. The registrant authenticates at the registrar's AS and approves
the delegation scope.
9. The registrar's AS issues an authorization code and redirects
the registrant's browser back to the DNS Operator's registered
callback URI.
10. The registrant's browser follows the redirect, delivering the
authorization code to the DNS Operator's callback endpoint.
11. The DNS Operator exchanges the authorization code for an access
token at the registrar's AS token endpoint (back-channel,
Authorization Code grant Section 4.1).
12. The registrar's AS validates the code and issues a signed JWT
access token ([RFC9068]) containing an authorization_details
claim that echoes the received authorization_details claim.
13. The DNS Operator submits the delegation update request to the
registry RPP API, including the JWT as a Bearer token in the
Authorization header. The request targets the delegation sub-
resource of the domain name (e.g., PATCH /domains/foo.example/
delegation).
Wullink & Kowalik Expires 7 January 2027 [Page 11]
Internet-Draft Secure Delegation Management for RPP July 2026
14. The registry validates the JWT locally using the sponsoring
registrar's AS public key (obtained via OAuth 2.0 Authorization
Server Metadata [RFC8414]). No live call to the registrar is
required. The registry MUST verify that the
authorization_details claim contains an object_identifier that
matches the domain name in the request.
15. Notify the registrar of the delegation update, so that the
registrar can reflect the change in its own systems and provide
accurate information to the registrant.
16. The registry updates the delegation data (name servers and any
associated glue records) for foo.example and returns the result
to the DNS Operator.
17. The DNS Operator confirms the completed delegation update to the
registrant.
10. Data Objects
The RPP Data Object Catalog is extended to include each registrar's
AS metadata.
* Auth Server Metadata Object: This object describes the
authorization_server for each registrar that operates its own AS.
It contains the metadata necessary for a DNS Operator to interact
with the registrar's AS, including the authorization endpoint URI
and JWKS URI or public key material.
*TODO* Add model of the actual data objects for delegation
management, e.g. the delegation sub-resource of the domain name
object, and the expected request and response formats for delegation
update requests.
TODO
11. Endpoints
The Secure Delegation Management mechanism relies on the following
RPP endpoints:
* Registrar info endpoint: returns the sponsoring registrar's AS
authorization URI for a given domain name. Used by the DNS
Operator to determine where to redirect the registrant.
* Delegation sub-resource endpoint (e.g., PATCH
/domains/{domainId}/delegation).
TODO
Wullink & Kowalik Expires 7 January 2027 [Page 12]
Internet-Draft Secure Delegation Management for RPP July 2026
12. IANA Considerations
TODO
13. Internationalization Considerations
TODO
14. Security Considerations
*Token scope.* Tokens issued in this flow are scoped to a single
domain name and to the specific set of actions granted by the
registrant. The registry MUST reject tokens that do not contain an
authorization_details object whose object_identifier exactly matches
the domain name in the request URL.
*Token lifetime.* Access tokens for delegation management MAY have a
longer lifetime than tokens used for single-use operations such as
object transfers, since they may be used for repeated updates.
However, token lifetime MUST be bounded. Registrar ASs SHOULD issue
tokens with a lifetime appropriate for the expected operational
pattern, and MUST support token revocation.
*Revocation.* Registrars MUST support token revocation ([RFC7009]) so
that registrants can revoke a DNS Operator's access at any time. The
registry MUST check token revocation status before processing
delegation update requests if the registrar's AS publishes a
revocation endpoint.
*Consent granularity.* The RAR authorization_details object allows
the registrant to see exactly which domain name and which actions
they are consenting to. Registrar ASs MUST surface this information
clearly on the consent screen.
15. Change History
15.1. Version 00
* Created initial draft with core concepts and delegation management
flow.
16. Normative References
Wullink & Kowalik Expires 7 January 2027 [Page 13]
Internet-Draft Secure Delegation Management for RPP July 2026
[I-D.ietf-rpp-core]
Wullink, M. and P. Kowalik, "RESTful Provisioning Protocol
(RPP)", Work in Progress, Internet-Draft, draft-ietf-rpp-
core-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rpp-
core-00>.
[I-D.wullink-rpp-oauth2]
Wullink, M. and P. Kowalik, "OAuth 2.0 for RESTful
Provisioning Protocol (RPP)", Work in Progress, Internet-
Draft, draft-wullink-rpp-oauth2-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-wullink-rpp-
oauth2-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
Wullink & Kowalik Expires 7 January 2027 [Page 14]
Internet-Draft Secure Delegation Management for RPP July 2026
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
Acknowledgements
TODO
Authors' Addresses
Maarten Wullink
SIDN Labs
Email: maarten.wullink@sidn.nl
URI: https://sidn.nl/
Pawel Kowalik
DENIC
Email: pawel.kowalik@denic.de
URI: https://denic.de/
Wullink & Kowalik Expires 7 January 2027 [Page 15]