draft-ietf-regext-rdap-openid-12.txt   draft-ietf-regext-rdap-openid-13.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track 23 March 2022 Intended status: Standards Track 18 May 2022
Expires: 24 September 2022 Expires: 19 November 2022
Federated Authentication for the Registration Data Access Protocol Federated Authentication for the Registration Data Access Protocol
(RDAP) using OpenID Connect (RDAP) using OpenID Connect
draft-ietf-regext-rdap-openid-12 draft-ietf-regext-rdap-openid-13
Abstract Abstract
The Registration Data Access Protocol (RDAP) provides "RESTful" web The Registration Data Access Protocol (RDAP) provides "RESTful" web
services to retrieve registration metadata from domain name and services to retrieve registration metadata from domain name and
regional internet registries. RDAP allows a server to make access regional internet registries. RDAP allows a server to make access
control decisions based on client identity, and as such it includes control decisions based on client identity, and as such it includes
support for client identification features provided by the Hypertext support for client identification features provided by the Hypertext
Transfer Protocol (HTTP). Identification methods that require Transfer Protocol (HTTP). Identification methods that require
clients to obtain and manage credentials from every RDAP server clients to obtain and manage credentials from every RDAP server
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 September 2022. This Internet-Draft will expire on 19 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3. RDAP Authentication and Authorization Steps . . . . . 6 3.1.3. RDAP Authentication and Authorization Steps . . . . . 6
3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 7 3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 7
3.1.3.2. Authentication Request . . . . . . . . . . . . . 7 3.1.3.2. Authentication Request . . . . . . . . . . . . . 7
3.1.3.3. End-User Authorization . . . . . . . . . . . . . 8 3.1.3.3. End-User Authorization . . . . . . . . . . . . . 8
3.1.3.4. Authorization Response and Validation . . . . . . 8 3.1.3.4. Authorization Response and Validation . . . . . . 8
3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 8 3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 8
3.1.3.6. Delivery of User Information . . . . . . . . . . 8 3.1.3.6. Delivery of User Information . . . . . . . . . . 8
3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 9 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 9
3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 9 3.1.4.1. Stated Purposes . . . . . . . . . . . . . . . . . 9
3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
4.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 11 4.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Session . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Session . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Device Info . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. Device Info . . . . . . . . . . . . . . . . . . . . . 12
4.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. OpenID Connect Configuration . . . . . . . . . . . . 13
4.2.1. Clients with Limited User Interfaces . . . . . . . . 15 4.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15 4.2.1. End-User Identifier . . . . . . . . . . . . . . . . . 14
4.2.1.2. UI-constrained Client Login Polling . . . . . . . 17 4.2.2. OP Issuer Identifier . . . . . . . . . . . . . . . . 15
4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Login Response . . . . . . . . . . . . . . . . . . . 15
4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18 4.2.4. Clients with Limited User Interfaces . . . . . . . . 17
4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20 4.2.4.1. UI-constrained Client Login . . . . . . . . . . . 17
4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21 4.2.4.2. UI-constrained Client Login Polling . . . . . . . 19
5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. RDAP Query Parameters . . . . . . . . . . . . . . . . . . 19
6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21 4.3.1. RDAP Query Purpose . . . . . . . . . . . . . . . . . 20
7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22 4.3.2. RDAP Do Not Track . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 4.4. Session Status . . . . . . . . . . . . . . . . . . . . . 20
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22 4.5. Session Refresh . . . . . . . . . . . . . . . . . . . . . 22
8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23 4.6. Client Logout . . . . . . . . . . . . . . . . . . . . . . 23
8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23 4.7. Parameter Processing . . . . . . . . . . . . . . . . . . 25
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 27 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 25
9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 27 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 26
9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 26
10.1. Authentication and Access Control . . . . . . . . . . . 29 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 31 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Authentication and Access Control . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The Registration Data Access Protocol (RDAP) provides "RESTful" web The Registration Data Access Protocol (RDAP) provides "RESTful" web
services to retrieve registration metadata from domain name and services to retrieve registration metadata from domain name and
regional internet registries. RDAP allows a server to make access regional internet registries. RDAP allows a server to make access
control decisions based on client identity, and as such it includes control decisions based on client identity, and as such it includes
support for client identification features provided by the Hypertext support for client identification features provided by the Hypertext
Transfer Protocol (HTTP) [RFC7230]. Transfer Protocol (HTTP) [RFC7230].
skipping to change at page 6, line 6 skipping to change at page 6, line 6
an OpenID Connect Core Relying Party (RP). Additional terms from an OpenID Connect Core Relying Party (RP). Additional terms from
Section 1.2 of the OpenID Connect Core specification are incorporated Section 1.2 of the OpenID Connect Core specification are incorporated
by reference. by reference.
3.1.2. Overview 3.1.2. Overview
At a high level, RDAP authentication of a browser-like client using At a high level, RDAP authentication of a browser-like client using
OpenID Connect requires completion of the following steps: OpenID Connect requires completion of the following steps:
1. An RDAP client sends an RDAP "help" query to an RDAP server to 1. An RDAP client sends an RDAP "help" query to an RDAP server to
determine the type of OpenID Authorization Server that's used by determine the type and capabilities of the OpenID Authorization
the RDAP server. This information is returned in the Servers that are used by the RDAP server. This information is
rdapConformance section of the response. A value of returned in the rdapConformance section of the response. A
"rdap_openidc_local_level_0" indicates that the server uses a value of "roidc1" indicates support for the extension described
local Authorization Server. A value of in this specification. If one or more remote Authorization
"rdap_openidc_remote_level_0" indicates that the server uses a Servers are supported, the RDAP client SHOULD evaluate the
remote Authorization Server. additional information described in Section 4.1.3 in order to
discover the capabilties of the RDAP server and optionally
obtain the set of supported OPs.
2. An RDAP client (acting as an OpenID End-User) sends an RDAP 2. An RDAP client (acting as an OpenID End-User) sends an RDAP
"login" request to an RDAP server as described in Section 4.2. "login" request to an RDAP server as described in Section 4.2.
3. The RDAP server (acting as an OpenID Relying Party (RP)) 3. The RDAP server (acting as an OpenID Relying Party (RP))
prepares an Authentication Request containing the desired prepares an Authentication Request containing the desired
request parameters. request parameters.
4. The RDAP server sends the RDAP client and Authentication Request 4. The RDAP server sends the RDAP client and Authentication Request
to an Authorization Server operated by an OpenID Provider (OP) to an Authorization Server operated by an OpenID Provider (OP)
using an HTTP redirect. using an HTTP redirect.
5. The Authorization Server authenticates the End-User. 5. The Authorization Server authenticates the End-User.
6. The Authorization Server obtains End-User consent/authorization. 6. The Authorization Server obtains End-User consent/authorization.
skipping to change at page 6, line 40 skipping to change at page 6, line 42
associated with the End-User's identity. associated with the End-User's identity.
The RDAP server can then make identification, authorization, and The RDAP server can then make identification, authorization, and
access control decisions based on End-User identity information and access control decisions based on End-User identity information and
local policies. Note that OpenID Connect describes different process local policies. Note that OpenID Connect describes different process
flows for other types of clients, such as script-based or command flows for other types of clients, such as script-based or command
line clients. line clients.
3.1.3. RDAP Authentication and Authorization Steps 3.1.3. RDAP Authentication and Authorization Steps
End-Users MUST possess an identifier (an OpenID) issued by an OP to End-Users MAY present an identifier (an OpenID) issued by an OP to
use OpenID Connect with RDAP. An OP SHOULD include support for the use OpenID Connect with RDAP. If the RDAP server supports a default
claims described in Section 3.1.4 to provide additional information Authorization Server or End-User identifier discovery is not
needed for RDAP End-User authorization. OpenID Connect requires RPs supported, the End-User identifier MAY be omitted. An OP SHOULD
to register with OPs to use OpenID Connect services for an End-User. include support for the claims described in Section 3.1.4 to provide
The registration process is often completed using out-of-band additional information needed for RDAP End-User authorization.
methods, but it is also possible to use the automated method OpenID Connect requires RPs to register with OPs to use OpenID
described by the "OpenID Connect Dynamic Client Registration" Connect services for an End-User. The registration process is often
protocol [OIDCR]. The parties involved can use any method that is completed using out-of-band methods, but it is also possible to use
mutually acceptable. the automated method described by the "OpenID Connect Dynamic Client
Registration" protocol [OIDCR]. The parties involved can use any
method that is mutually acceptable.
3.1.3.1. Provider Discovery 3.1.3.1. Provider Discovery
An RDAP server/RP needs to be able to map an End-User's identifier to An RDAP server/RP needs to be able to map an End-User's identifier to
an OP. This can be accomplished using the OPTIONAL "OpenID Connect an OP. This can be accomplished using the OPTIONAL "OpenID Connect
Discovery" protocol [OIDCD], but that protocol is not widely Discovery" protocol [OIDCD], but that protocol is not widely
implemented. Out-of-band methods are also possible and can be more implemented. Out-of-band methods are also possible and can be more
dependable. For example, an RP can support a limited number of OPs dependable. For example, an RP can support a limited number of OPs
and maintain internal associations of those identifiers with the OPs and maintain internal associations of those identifiers with the OPs
that issued them. An RP can also ask an End-User to identify the OP that issued them.
that issued their identifier as part of an RDAP query workflow. In
this case, the RP will need to maintain state for the association Alternatively, if mapping of an End-User's identifier is not
between the user's identifier and the OP in order to process later possible, or not supported by the RDAP server, the RDAP server SHOULD
queries that rely on passing the access token and user identifier as support explicit specification of a remote OP by the RDAP client in
authorization parameters. An RP MAY use any provider discovery the form of a query parameter as described in Section 4.2.2. An RDAP
approach that is suitable for its operating environment. server SHOULD provide information about its capabilities and
supported OPs in the "help" query response in the
"openidcConfiguration" data structure described in Section 4.1.3.
An RP can also ask an End-User to identify the OP that issued their
identifier as part of an RDAP query workflow. In this case, the RP
will need to maintain state for the association between the user's
identifier and the OP in order to process later queries that rely on
passing the access token and user identifier as authorization
parameters. An RDAP server MUST support at least one of these
methods of OP discovery.
3.1.3.2. Authentication Request 3.1.3.2. Authentication Request
Once the OP is known, an RP MUST form an Authentication Request and Once the OP is known, an RP MUST form an Authentication Request and
send it to the OP as described in Section 3 of the OpenID Connect send it to the OP as described in Section 3 of the OpenID Connect
Core protocol [OIDCC]. The authentication path followed Core protocol [OIDCC]. The authentication path followed
(authorization, implicit, or hybrid) will depend on the (authorization, implicit, or hybrid) will depend on the
Authentication Request response_type set by the RP. The remainder of Authentication Request response_type set by the RP. The remainder of
the processing steps described here assume that the Authorization the processing steps described here assume that the Authorization
Code Flow is being used by setting "response_type=code" in the Code Flow is being used by setting "response_type=code" in the
skipping to change at page 7, line 47 skipping to change at page 8, line 10
Hybrid Flow (described in Section 3.3 of the OpenID Connect Core Hybrid Flow (described in Section 3.3 of the OpenID Connect Core
protocol) combines elements of the Authorization and Implicit Flows protocol) combines elements of the Authorization and Implicit Flows
by returning some tokens from the Authorization Endpoint and others by returning some tokens from the Authorization Endpoint and others
from the Token Endpoint. from the Token Endpoint.
An Authentication Request can contain several parameters. REQUIRED An Authentication Request can contain several parameters. REQUIRED
parameters are specified in Section 3.1.2.1 of the OpenID Connect parameters are specified in Section 3.1.2.1 of the OpenID Connect
Core protocol [OIDCC]. Apart from these parameters, it is Core protocol [OIDCC]. Apart from these parameters, it is
RECOMMENDED that the RP include the optional "login_hint" parameter RECOMMENDED that the RP include the optional "login_hint" parameter
in the request, with the value being that of the "id" query parameter in the request, with the value being that of the "id" query parameter
of the End-User's RDAP "login" request. Passing the "login_hint" of the End-User's RDAP "login" request, if provided. Passing the
parameter allows a client to pre-fill login form information, so "login_hint" parameter allows a client to pre-fill login form
logging in can be more convenient for users. Other parameters MAY be information, so logging in can be more convenient for users. Other
included. parameters MAY be included.
The OP receives the Authentication Request and attempts to validate The OP receives the Authentication Request and attempts to validate
it as described in Section 3.1.2.2 of the OpenID Connect Core it as described in Section 3.1.2.2 of the OpenID Connect Core
protocol [OIDCC]. If the request is valid, the OP attempts to protocol [OIDCC]. If the request is valid, the OP attempts to
authenticate the End-User as described in Section 3.1.2.3 of the authenticate the End-User as described in Section 3.1.2.3 of the
OpenID Connect Core protocol [OIDCC]. The OP returns an error OpenID Connect Core protocol [OIDCC]. The OP returns an error
response if the request is not valid or if any error is encountered. response if the request is not valid or if any error is encountered.
3.1.3.3. End-User Authorization 3.1.3.3. End-User Authorization
skipping to change at page 9, line 15 skipping to change at page 9, line 18
3.1.4. Specialized Claims for RDAP 3.1.4. Specialized Claims for RDAP
OpenID Connect claims are pieces of information used to make OpenID Connect claims are pieces of information used to make
assertions about an entity. Section 5 of the OpenID Connect Core assertions about an entity. Section 5 of the OpenID Connect Core
protocol [OIDCC] describes a set of standard claims that can be used protocol [OIDCC] describes a set of standard claims that can be used
to identify a person. Section 5.1.2 notes that additional claims MAY to identify a person. Section 5.1.2 notes that additional claims MAY
be used, and it describes a method to create them. The set of claims be used, and it describes a method to create them. The set of claims
that are specific to RDAP are associated with an OAuth scope request that are specific to RDAP are associated with an OAuth scope request
parameter value (see Section 3.3 of RFC 6749 ([RFC6749])) of "rdap". parameter value (see Section 3.3 of RFC 6749 ([RFC6749])) of "rdap".
3.1.4.1. Stated Purpose 3.1.4.1. Stated Purposes
There are communities of RDAP users and operators who wish to make There are communities of RDAP users and operators who wish to make
and validate claims about a user's "need to know" when it comes to and validate claims about a user's "need to know" when it comes to
requesting access to a resource. For example, a law enforcement requesting access to a resource. For example, a law enforcement
agent or a trademark attorney may wish to be able to assert that they agent or a trademark attorney may wish to be able to assert that they
have a legal right to access a protected resource, and a server have a legal right to access a protected resource, and a server
operator will need to be able to receive and validate that claim. operator will need to be able to receive and validate that claim.
These needs can be met by defining and using an additional "purpose" These needs can be met by defining and using an additional
claim. "rdap_allowed_purposes" claim.
The "purpose" claim identifies the purpose for which access to a The "rdap_allowed_purposes" claim identifies the purposes for which
protected resource is being requested. Use of the "purpose" claim is access to a protected resource can be requested by an End-User. Use
OPTIONAL; processing of this claim is subject to server acceptance of of the "rdap_allowed_purposes" claim is OPTIONAL; processing of this
the purpose and successful authentication of the End-User. claim is subject to server acceptance of the purposes, the trust
Unrecognized purpose values MUST be ignored and the associated query level assigned to this claim by the server, and successful
MUST be processed as if the unrecognized purpose value was not authentication of the End-User. Unrecognized purpose values MUST be
present at all. ignored and the associated query MUST be processed as if the
unrecognized purpose value was not present at all.
The "purpose" value is a case-sensitive string containing a The "rdap_allowed_purposes" claim is represented as an array of case-
StringOrURI value as specified in Section 2 of the JSON Web Token sensitive StringOrURI values as specified in Section 2 of the JSON
(JWT) specification ([RFC7519]). An example: Web Token (JWT) specification ([RFC7519]). An example:
{"purpose" : "domainNameControl"} "rdap_allowed_purposes": ["domainNameControl","dnsTransparency"]
Purpose values are themselves registered with IANA. Each entry in Individual purpose values are registered with IANA. Each entry in
the registry contains the following fields: the registry contains the following fields:
Value: the purpose string value being registered. Value strings can Value: the purpose string value being registered. Value strings can
contain upper case characters from "A" to "Z", lower case ASCII contain upper case characters from "A" to "Z", lower case ASCII
characters from "a" to "z", and the underscore ("_") character. characters from "a" to "z", and the underscore ("_") character.
Value strings contain at least one character and no more than 64 Value strings contain at least one character and no more than 64
characters. characters.
Description: a one- or two-sentence description of the meaning of the Description: a one- or two-sentence description of the meaning of the
purpose value, how it might be used, and/or how it should be purpose value, how it might be used, and/or how it should be
skipping to change at page 10, line 24 skipping to change at page 10, line 28
There are also communities of RDAP users and operators who wish to There are also communities of RDAP users and operators who wish to
make and validate claims about a user's wish to not have their make and validate claims about a user's wish to not have their
queries logged, tracked, or recorded. For example, a law enforcement queries logged, tracked, or recorded. For example, a law enforcement
agent may wish to be able to assert that their queries are part of a agent may wish to be able to assert that their queries are part of a
criminal investigation and should not be tracked due to a risk of criminal investigation and should not be tracked due to a risk of
query exposure compromising the investigation, and a server operator query exposure compromising the investigation, and a server operator
will need to be able to receive and validate that claim. These needs will need to be able to receive and validate that claim. These needs
can be met by defining and using an additional "do not track" claim. can be met by defining and using an additional "do not track" claim.
The "do not track" ("dnt") claim can be used to identify an End-User The "do not track" ("rdap_dnt_allowed") claim can be used to identify
that is authorized to perform queries without the End-User's an End-User that is authorized to perform queries without the End-
association with those queries being logged, tracked, or recorded by User's association with those queries being logged, tracked, or
the server. Client use of the "dnt" claim is OPTIONAL. Server recorded by the server. Client use of the "rdap_dnt_allowed" claim
operators MUST NOT log, track, or record any association of the query is OPTIONAL. Server operators MUST NOT log, track, or record any
and the End-User's identity if the End-User is successfully association of the query and the End-User's identity if the End-User
identified and authorized, the "dnt" claim is present, the value of is successfully identified and authorized, the "rdap_dnt_allowed"
the claim is "true", and accepting the claim complies with local claim is present, the value of the claim is "true", and accepting the
regulations regarding logging and tracking. claim complies with local regulations regarding logging and tracking.
The "dnt" value is represented as a JSON boolean literal. An The "rdap_dnt_allowed" value is represented as a JSON boolean
example: literal. An example:
{"dnt" : true} rdap_dnt_allowed: true
No special query tracking processing is required if this claim is not No special query tracking processing is required if this claim is not
present or if the value of the claim is "false". Use of this claim present or if the value of the claim is "false". Use of this claim
MUST be limited to End-Users who are granted "do not track" MUST be limited to End-Users who are granted "do not track"
privileges in accordance with service policies and regulations. privileges in accordance with service policies and regulations.
Specification of these policies and regulations is beyond the scope Specification of these policies and regulations is beyond the scope
of this document. of this document.
4. Protocol Parameters 4. Protocol Parameters
This specification adds the following protocol parameters to RDAP: This specification adds the following protocol parameters to RDAP:
1. Data structures to return information that describes an 1. Data structures to return information that describes an
established session and the information needed to establish a established session, the information needed to establish a
session for a UI-constrained device. session for a UI-constrained device, and the RDAP server's OpenID
Connect extension configuration.
2. A query parameter to request authentication for a specific End- 2. A query parameter to request authentication for a specific End-
User identity. User identity.
3. Path segments to start, stop, refresh, and determine the status 3. A query parameter to identify the purpose of the query.
4. A query parameter to request that the server not log or otherwise
record information about the identity associated with a query.
5. Path segments to start, stop, refresh, and determine the status
of an authenticated session for a specific End-User identity. of an authenticated session for a specific End-User identity.
4.1. Data Structures 4.1. Data Structures
This specification describes two new data structures that are used to This specification describes three new data structures that are used
return information to a client: a "session" data structure that to return information to a client: a "roidc1_session" data structure
contains information that describes an established session, and a that contains information that describes an established session, a
"deviceInfo" data structure that contains information that describes "roidc1_deviceInfo" data structure that contains information that
an active attempt to establish a session on a UI-constrained device. describes an active attempt to establish a session on a UI-
constrained device, and a "roidc1_openidcConfiguration" data
structure that describes the OpenID Connect configuration and related
extension features supported by the RDAP server.
4.1.1. Session 4.1.1. Session
The "session" data structure is an object that contains two sub- The "roidc1_session" data structure is an object that contains two
objects: sub-objects:
1. A "userClaims" object that contains the set of claims associated 1. A "userClaims" object that contains the set of claims associated
with the End-User's identity as used/requested by the RDAP server with the End-User's identity as used/requested by the RDAP server
to make access control decisions. The set of possible values is to make access control decisions. The set of possible values is
determined by OP policy. determined by OP policy.
2. A "sessionInfo" object that contains two members: 2. A "sessionInfo" object that contains two members:
a. "tokenExpiration": an integer value that represents the a. "tokenExpiration": an integer value that represents the
number of seconds from the current time for which the Access number of seconds from the current time for which the Access
Token remains valid, and Token remains valid, and
b. "tokenRefresh": A boolean value that indicates if the OP b. "tokenRefresh": A boolean value that indicates if the OP
supports refresh tokens. As described in RFC 6749 [RFC6749], supports refresh tokens. As described in RFC 6749 [RFC6749],
support for refresh tokens is OPTIONAL. support for refresh tokens is OPTIONAL.
An example of a "session" data structure: An example of a "roidc1_session" data structure:
"session": { "roidc1_session": {
"userClaims": { "userClaims": {
"sub": "103892603076825016132", "sub": "103892603076825016132",
"name": "User Person", "name": "User Person",
"given_name": "User", "given_name": "User",
"family_name": "Person", "family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c", "picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com", "email": "user@example.com",
"email_verified": true, "email_verified": true,
"locale": "en", "locale": "en",
"purpose": "domainNameControl", "rdap_allowed_purposes": [
"dnt": false "domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
}, },
"sessionInfo": { "sessionInfo": {
"tokenExpiration": 3599, "tokenExpiration": 3599,
"tokenRefresh": true "tokenRefresh": true
} }
} }
Figure 1 Figure 1
4.1.2. Device Info 4.1.2. Device Info
The flow described in Section 3.1.3 requires an End-User to interact The flow described in Section 3.1.3 requires an End-User to interact
with a server using a user interface that can process HTTP. This with a server using a user interface that can process HTTP. This
will not work well in situations where the client is automated or an will not work well in situations where the client is automated or an
End-User is using a command line user interface such as curl End-User is using a command line user interface such as curl
(http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/). (http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/).
This limitation can be addressed using a web browser on a second This limitation can be addressed using a web browser on a second
device. The information that needs to be entered using the web device. The information that needs to be entered using the web
browser is contained in the "deviceInfo" data structure. browser is contained in the "roidc1_deviceInfo" data structure.
The "deviceInfo" data structure is an object that contains three The "roidc1_deviceInfo" data structure is an object that contains
members: three members:
1. "verification_url": the URL that the End-User needs to visit 1. "verification_url": the URL that the End-User needs to visit
using the web browser, using the web browser,
2. "user_code": the string value that the End-User needs to enter on 2. "user_code": the string value that the End-User needs to enter on
the form presented in the web browser, and the form presented in the web browser, and
3. "expires_in": an integer value that represents the number of 3. "expires_in": an integer value that represents the number of
seconds after which the opportunity to visit the URL and enter seconds after which the opportunity to visit the URL and enter
the user_code will expire. the user_code will expire.
An example of a "deviceInfo" data structure: An example of a "roidc1_deviceInfo" data structure:
"deviceInfo": { "roidc1_deviceInfo": {
"verification_url": "https://www.example.com/device", "verification_url": "https://www.example.com/device",
"user_code": "NJJQ-GJFC", "user_code": "NJJQ-GJFC",
"expires_in": "1800" "expires_in": "1800"
} }
Figure 2 Figure 2
4.1.3. OpenID Connect Configuration
The "roidc1_openidcConfiguration" data structure is an object with
the following members:
1. "dntSupported": (MANDATORY) a boolean value that describes RDAP
server support for the "roidc1_dnt" query parameter (see
Section 4.3.2).
2. "endUserIdentifierDiscoverySupported": (OPTIONAL) a boolean value
that describes RDAP server support for discovery of End-User
identifiers. The default value is "true".
3. "issuerIdentifierSupported": (OPTIONAL) a boolean value that
describes RDAP server support for explicit client specification
of an Issuer Identifier. The default value is "true".
4. "openidcProviders": (OPTIONAL) a list of objects with the
following members that describes the set of OPs that are
supported by the RDAP server. This data is RECOMMENDED if the
value of issuerIdentifierSupported is "true":
a. "iss": (MANDATORY) a string value equal to Issuer Identifier
of the OP as per OpenID Connect Core specification [OIDCC]
b. "name": (MANDATORY) a string value representing the human-
friendly name of the OP.
c. "default": (OPTIONAL) a boolean value that describes RDAP
server support for an OPTIONAL default OP that will be used
when a client omits the "roidc1_id" and "roidc1_iss" query
parameters from a "roidc1_session/login" request. Only one
member of this set can be identified as the default OP by
setting a value of "true". The default value is "false".
An example of a "roidc1_openidcConfiguration" data structure:
"roidc1_openidcConfiguration": {
"dntSupported": false,
"endUserIdentifierDiscoverySupported": true,
"issuerIdentifierSupported": true,
"openidcProviders":
[
{
"iss": "https://idp.example.com",
"name": "Example IDP"
},
{
"iss": "https://accounts.example.net",
"name": "Login with EXAMPLE"
},
{
"iss": "https://auth.nic.example/auth/realms/rdap",
"name": "Default OP for the Example RDAP server",
"default": "true"
}
]
}
Figure 3
4.2. Client Login 4.2. Client Login
Client authentication is requested by sending a "session/login" Client authentication is requested by sending a "roidc1_session/
request to an RDAP server. If the RDAP server supports only remote login" request to an RDAP server. If the RDAP server supports only
Authorization Servers, the "session/login" request MUST include an remote Authorization Servers, the "roidc1_session/login" request MUST
End-User identifier that's delivered using one of two methods: by include at least one of an End-User Identifier or an OP Issuer
Identifier.
4.2.1. End-User Identifier
The End-User identifier is delivered using one of two methods: by
adding a query component to an RDAP request URI using the syntax adding a query component to an RDAP request URI using the syntax
described in Section 3.4 of RFC 3986 [RFC3986], or by including an described in Section 3.4 of RFC 3986 [RFC3986], or by including an
HTTP authorization header for the Basic authentication scheme as HTTP authorization header for the Basic authentication scheme as
described in RFC 7617 [RFC7617]. Clients can use either of these described in RFC 7617 [RFC7617]. Clients can use either of these
methods to deliver the End-User identifier to a server that supports methods to deliver the End-User identifier to a server that supports
remote Authorization Servers. Servers that support remote remote Authorization Servers and End-User identifier discovery.
Authorization Servers MUST accept both methods. If the RDAP server Servers that support remote Authorization Servers and End-User
supports a local Authorization Server, the End-User identifier MAY be identifier discovery MUST accept both methods. If the RDAP server
omitted. supports a default Authorization Server or End-User identifier
discovery is not supported, the End-User identifier MAY be omitted.
The query used to request client authentication is represented as an The query used to request client authentication is represented as an
OPTIONAL "key=value" pair using a key value of "id" and a value OPTIONAL "key=value" pair using a key value of "roidc1_id" and a
component that contains the client identifier issued by an OP. An value component that contains the client identifier issued by an OP.
example for client identifier "user.idp.example": An example for client identifier "user.idp.example":
https://example.com/rdap/session/login?id=user.idp.example https://example.com/rdap/roidc1_session/
login?roidc1_id=user.idp.example
The authorization header for the Basic authentication scheme contains The authorization header for the Basic authentication scheme contains
a Base64-encoded representation of the client identifier issued by an a Base64-encoded representation of the client identifier issued by an
OP. No password is provided. An example for client identifier OP. No password is provided. An example for client identifier
"user.idp.example": "user.idp.example":
https://example.com/rdap/session/login https://example.com/rdap/roidc1_session/login
Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ== Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==
An example for use with a local Authorization Server: An example for use with a default Authorization Server:
https://example.com/rdap/session/login https://example.com/rdap/roidc1_session/login
The response to this request MUST use the response structures
4.2.2. OP Issuer Identifier
The OP's Issuer Identifier is delivered by adding a query component
to an RDAP request URI using the syntax described in Section 3.4 of
RFC 3986 [RFC3986]. If the RDAP server supports a default
Authorization Server, the Issuer Identifier MAY be omitted.
The query used to request client authentication is represented as an
OPTIONAL "key=value" pair using a key value of "roidc1_iss" and a
value component that contains the Issuer Identifier associated with
an OP. An RDAP server MAY accept Issuer Identifiers not specified in
the "roidc1_openidcConfiguration" data structure and MAY also decide
to accept specific Issuer Identifiers only from specific clients.
An example for Issuer Identifier "https://idp.example.com":
https://example.com/rdap/roidc1_session/
login?roidc1_iss=https%3A%2F%2Fidp.example.com
4.2.3. Login Response
The response to the login request MUST use the response structures
specified in RFC 9083 [RFC9083]. In addition, the response MUST specified in RFC 9083 [RFC9083]. In addition, the response MUST
include an indication of the requested operation's success or failure include an indication of the requested operation's success or failure
in the "notices" data structure (including the client identifier), in the "notices" data structure (including the client identifier),
and, if successful, a "session" data structure. and, if successful, a "roidc1_session" data structure.
An example of a successful "session/login" response: An example of a successful "roidc1_session/login" response:
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_openidc_remote_level_0" "roidc1"
],
"lang": "en-US",
"notices": {
"title": "Login Result",
"description": [
"Login succeeded",
"user.idp.example"
], ],
}, "lang": "en-US",
"session": { "notices": {
"userClaims": { "title": "Login Result",
"sub": "103892603076825016132", "description": [
"name": "User Person", "Login succeeded",
"given_name": "User", "user.idp.example"
"family_name": "Person", ],
"picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com",
"email_verified": true,
"locale": "en",
"purpose": "domainNameControl",
"dnt": false
}, },
"sessionInfo": { "roidc1_session": {
"tokenExpiration": 3599, "userClaims": {
"tokenRefresh": true "sub": "103892603076825016132",
"name": "User Person",
"given_name": "User",
"family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com",
"email_verified": true,
"locale": "en",
"rdap_allowed_purposes": [
"domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
},
"sessionInfo": {
"tokenExpiration": 3599,
"tokenRefresh": true
}
} }
} }
}
Figure 3 Figure 4
An example of a failed "session/login" response: An example of a failed "roidc1_session/login" response:
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_openidc_remote_level_0" "roidc1"
], ],
"lang": "en-US", "lang": "en-US",
"notices": { "notices": {
"title": "Login Result", "title": "Login Result",
"description": [ "description": [
"Login failed", "Login failed",
"user.idp.example" "user.idp.example"
] ]
}
} }
}
Figure 4 Figure 5
4.2.1. Clients with Limited User Interfaces 4.2.4. Clients with Limited User Interfaces
The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an
OPTIONAL method to request user authorization from devices that have OPTIONAL method to request user authorization from devices that have
an Internet connection, but lack a suitable browser for a more an Internet connection, but lack a suitable browser for a more
traditional OAuth flow. This method requires an End-User to use a traditional OAuth flow. This method requires an End-User to use a
second device (such as a smart telephone) that has access to a web second device (such as a smart telephone) that has access to a web
browser for entry of a code sequence that is presented on the UI- browser for entry of a code sequence that is presented on the UI-
constrained device. constrained device.
4.2.1.1. UI-constrained Client Login 4.2.4.1. UI-constrained Client Login
Client authentication is requested by sending a "session/device" Client authentication is requested by sending a "roidc1_session/
request to an RDAP server. If the RDAP server supports only remote device" request to an RDAP server. If the RDAP server supports only
Authorization Servers, the "session/device" request MUST include an remote Authorization Servers, the "roidc1_session/device" request
End-User identifier that's delivered using one of two methods: by MUST include an End-User identifier that's delivered using one of two
adding a query component to an RDAP request URI using the syntax methods: by adding a query component to an RDAP request URI using the
described in Section 3.4 of RFC 3986 [RFC3986], or by including an syntax described in Section 3.4 of RFC 3986 [RFC3986], or by
HTTP authorization header for the Basic authentication scheme as including an HTTP authorization header for the Basic authentication
described in RFC 7617 [RFC7617]. If the RDAP server supports a local scheme as described in RFC 7617 [RFC7617]. If the RDAP server
Authorization Server, the End-User identifier MAY be omitted. supports a default Authorization Server, the End-User identifier MAY
Clients can use either of these methods. Servers MUST support both be omitted. Clients can use either of these methods. Servers MUST
methods. support both methods.
The query used to request client authentication is represented as an The query used to request client authentication is represented as an
OPTIONAL "key=value" pair using a key value of "id" and a value OPTIONAL "key=value" pair using a key value of "id" and a value
component that contains the client identifier issued by an OP. component that contains the client identifier issued by an OP.
An example using wget for client identifier "user.idp.example": An example using wget for client identifier "user.idp.example":
wget -qO- --keep-session-cookies --save-cookies\ wget -qO- --keep-session-cookies --save-cookies\
https://example.com/rdap/session/device?id=user.idp.example https://example.com/rdap/session/device?roidc1_id=user.idp.example
Figure 5 Figure 6
The authorization header for the Basic authentication scheme contains The authorization header for the Basic authentication scheme contains
a Base64-encoded representation of the client identifier issued by an a Base64-encoded representation of the client identifier issued by an
OP. No password is provided. OP. No password is provided.
An example using curl and an authorization header: An example using curl and an authorization header:
curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\ curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\
-c cookies.txt https://example.com/rdap/session/device -c cookies.txt https://example.com/rdap/session/device
Figure 6 Figure 7
The response to this request MUST use the response structures The response to this request MUST use the response structures
specified in RFC 9083 [RFC9083]. In addition, the response MUST specified in RFC 9083 [RFC9083]. In addition, the response MUST
include an indication of the requested operation's success or failure include an indication of the requested operation's success or failure
in the "notices" data structure (including the client identifier), in the "notices" data structure (including the client identifier),
and, if successful, a "deviceInfo" data structure. and, if successful, a "roidc1_deviceInfo" data structure.
An example of a "session/device" response: An example of a "roidc1_session/device" response:
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_openidc_remote_level_0" "roidc1"
], ],
"lang": "en-US", "lang": "en-US",
"notices": { "notices": {
"title": "Device Login Result", "title": "Device Login Result",
"description": [ "description": [
"Login succeeded", "Login succeeded",
"user.idp.example" "user.idp.example"
] ]
}, },
"deviceInfo": { "roidc1_deviceInfo": {
"verification_url": "https://www.example.com/device", "verification_url": "https://www.example.com/device",
"user_code": "NJJQ-GJFC", "user_code": "NJJQ-GJFC",
"expires_in": 1800 "expires_in": 1800
} }
} }
Figure 7 Figure 8
4.2.1.2. UI-constrained Client Login Polling 4.2.4.2. UI-constrained Client Login Polling
After successful processing of the "session/device" request, the After successful processing of the "roidc1_session/device" request,
client MUST send a "session/devicepoll" request to the RDAP server to the client MUST send a "roidc1_session/devicepoll" request to the
continue the login process. This request performs the polling RDAP server to continue the login process. This request performs the
function described in RFC 8628 [RFC8628], allowing the RDAP server to polling function described in RFC 8628 [RFC8628], allowing the RDAP
wait for the End-User to enter the information returned from the server to wait for the End-User to enter the information returned
"session/device" request using the interface on their second device. from the "roidc1_session/device" request using the interface on their
After the End-User has completed that process, or if the process second device. After the End-User has completed that process, or if
fails or times out, the OP will respond to the polling requests with the process fails or times out, the OP will respond to the polling
an indication of success or failure. requests with an indication of success or failure.
An example using wget: An example using wget:
wget -qO- --load-cookies cookies.txt\ wget -qO- --load-cookies cookies.txt\
https://example.com/rdap/session/devicepoll https://example.com/rdap/roidc1_session/devicepoll
Figure 8 Figure 9
An example using curl: An example using curl:
curl -b cookies.txt https://example.com/rdap/session/devicepoll curl -b cookies.txt https://example.com/rdap/roidc1_session/devicepoll
Figure 9 Figure 10
The response to this request MUST use the response structures The response to this request MUST use the response structures
described in Section 4.2. RDAP query processing can continue described in Section 4.2. RDAP query processing can continue
normally on the UI-constrained device once the "login" process has normally on the UI-constrained device once the "login" process has
been completed. been completed.
4.3. Session Status 4.3. RDAP Query Parameters
Clients MAY send a query to an RDAP server to determine the status of This specification describes two OPTIONAL query parameters for use
an existing login session using a "session/status" path segment. An with RDAP queries that request access to information associated with
example "session/status" request: protected resources:
https://example.com/rdap/session/status 1. "roidc1_qp": A query parameter to identify the purpose of the
query.
2. "roidc1_dnt": A query parameter to request that the server not
log or otherwise record information about the identity associated
with a query.
One or both of these parameters MAY be added to an RDAP request URI
using the syntax described in Section 3.4 of RFC 3986 [RFC3986].
4.3.1. RDAP Query Purpose
This query is represented as a "key=value" pair using a key value of
"roidc1_qp" and a value component that contains a single query
purpose string from the set of allowed purposes associated with the
End-User's identity (see Section 3.1.4.1). If present, the server
SHOULD compare the value of the parameter to the
"rdap_allowed_purposes" claim values associated with the End-User's
identity and ensure that the requested purpose is present in the set
of allowed purposes. The RDAP server MAY choose to ignore both
requested purpose and the "rdap_allowed_purposes" claim values if
they are inconsistent with local server policy. The server MUST
return an HTTP 403 (Forbidden) response if the requested purpose is
not an allowed purpose. If this parameter is not present, the server
MUST proces the query and make an acces control decision based on any
other information known to the server about the End-User and the
information they are requesting. For example, a server MAY treat the
request as one performed by an unidentified or unauthenticated user
and return either an error or an appropriate subset of the available
data. An example domain query using the "roidc1_qp" query parameter:
https://example.com/rdap/domain/example.com?roidc1_qp=legalActions
4.3.2. RDAP Do Not Track
This query is represented as a "key=value" pair using a key value of
"roidc1_dnt" and a value component that contains a single boolean
value. A value of "true" indicates that the End-User is requesting
that their query not be tracked or logged in accordance with server
policy. A value of "false" indicates that the End-User is accepting
that their query can be tracked or logged in accordance with server
policy. The server MUST return an HTTP 501 (Not Implemented)
response if the server is unable to perform the action requested by
this query parameter. An example domain query using the "roidc1_dnt"
query parameter:
https://example.com/rdap/domain/example.com?roidc1_dnt=true
4.4. Session Status
Clients MAY send a query to an RDAP server to determine the status of
an existing login session using a "roidc1_session/status" path
segment. An example "roidc1_session/status" request:
https://example.com/rdap/roidc1_session/status
The response to this query MUST use the response structures specified The response to this query MUST use the response structures specified
in RFC 9083 [RFC9083]. In addition, the response MUST include an in RFC 9083 [RFC9083]. In addition, the response MUST include an
indication of the requested operation's success or failure in the indication of the requested operation's success or failure in the
"notices" data structure (including the client identifier), and, if "notices" data structure (including the client identifier), and, if
successful, a "session" data structure. successful, a "roidc1_session" data structure.
An example of a "session/status" response: An example of a "roidc1_session/status" response:
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_openidc_remote_level_0" "roidc1"
], ],
"lang": "en-US", "lang": "en-US",
"notices": { "notices": {
"title": "Session Status Result", "title": "Session Status Result",
"description": [ "description": [
"Session status succeeded", "Session status succeeded",
"user.idp.example" "user.idp.example"
] ]
}, },
"session": { "roidc1_session": {
"userClaims": { "userClaims": {
"sub": "103892603076825016132", "sub": "103892603076825016132",
"name": "User Person", "name": "User Person",
"given_name": "User", "given_name": "User",
"family_name": "Person", "family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c", "picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com", "email": "user@example.com",
"email_verified": true, "email_verified": true,
"locale": "en", "locale": "en",
"purpose": "domainNameControl", "rdap_allowed_purposes": [
"dnt": false "domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
}, },
"sessionInfo": { "sessionInfo": {
"tokenExpiration": 3490, "tokenExpiration": 3490,
"tokenRefresh": true "tokenRefresh": true
} }
} }
} }
Figure 10 Figure 11
4.4. Session Refresh 4.5. Session Refresh
Clients MAY send a request to an RDAP server to refresh, or extend, Clients MAY send a request to an RDAP server to refresh, or extend,
an existing login session using a "session/refresh" path segment. an existing login session using a "roidc1_session/refresh" path
The RDAP server MAY attempt to refresh the access token associated segment. The RDAP server MAY attempt to refresh the access token
with the current session as part of extending the session for a associated with the current session as part of extending the session
period of time determined by the RDAP server. As described in RFC for a period of time determined by the RDAP server. As described in
6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP RFC 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An
server MUST determine if the OP supports token refresh and process RDAP server MUST determine if the OP supports token refresh and
the refresh request by either requesting refresh of the access token process the refresh request by either requesting refresh of the
or by returning a response that indicates that token refresh is not access token or by returning a response that indicates that token
supported by the OP in the "notices" data structure. An example refresh is not supported by the OP in the "notices" data structure.
"session/refresh" request: An example "roidc1_session/refresh" request:
https://example.com/rdap/session/refresh https://example.com/rdap/roidc1_session/refresh
The response to this request MUST use the response structures The response to this request MUST use the response structures
specified in RFC 9083 [RFC9083]. In addition, the response MUST specified in RFC 9083 [RFC9083]. In addition, the response MUST
include an indication of the requested operation's success or failure include an indication of the requested operation's success or failure
in the "notices" data structure (including the client identifier), in the "notices" data structure (including the client identifier),
and, if successful, a "session" data structure. and, if successful, a "roidc1_session" data structure.
An example of a "session/refresh" response: An example of a "roidc1_session/refresh" response:
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_openidc_remote_level_0" "roidc1"
], ],
"lang": "en-US", "lang": "en-US",
"notices": { "notices": {
"title": "Session Refresh Result", "title": "Session Refresh Result",
"description": [ "description": [
"Session refresh succeeded", "Session refresh succeeded",
"user.idp.example", "user.idp.example",
"Token refresh succeeded." "Token refresh succeeded."
] ]
}, },
"session": { "roidc1_session": {
"userClaims": { "userClaims": {
"sub": "103892603076825016132", "sub": "103892603076825016132",
"name": "User Person", "name": "User Person",
"given_name": "User", "given_name": "User",
"family_name": "Person", "family_name": "Person",
"picture": "https://lh3.example.com/a-/AOh14=s96-c", "picture": "https://lh3.example.com/a-/AOh14=s96-c",
"email": "user@example.com", "email": "user@example.com",
"email_verified": true, "email_verified": true,
"locale": "en", "locale": "en",
"purpose": "domainNameControl", "rdap_allowed_purposes": [
"dnt": false "domainNameControl",
"personalDataProtection"
],
"rdap_dnt_allowed": false
}, },
"sessionInfo": { "sessionInfo": {
"tokenExpiration": 3599, "tokenExpiration": 3599,
"tokenRefresh": true "tokenRefresh": true
} }
} }
} }
Figure 11 Figure 12
4.5. Client Logout 4.6. Client Logout
Clients MAY send a request to an RDAP server to terminate an existing Clients MAY send a request to an RDAP server to terminate an existing
login session. Termination of a session is requested using a login session. Termination of a session is requested using a
"session/logout" path segment. Access and refresh tokens can be "roidc1_session/logout" path segment. Access and refresh tokens can
revoked during the "session/logout" process as described in RFC 7009 be revoked during the "roidc1_session/logout" process as described in
[RFC7009] if supported by the OP (token revocation endpoint support RFC 7009 [RFC7009] if supported by the OP (token revocation endpoint
is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature support is OPTIONAL per RFC 8414 [RFC8414]). If supported, this
SHOULD be used to ensure that the tokens are not mistakenly feature SHOULD be used to ensure that the tokens are not mistakenly
associated with a future RDAP session. Alternatively, an RDAP server associated with a future RDAP session. Alternatively, an RDAP server
MAY attempt to logout from the OP using the "OpenID Connect RP- MAY attempt to logout from the OP using the "OpenID Connect RP-
Initiated Logout" protocol ([OIDCL]) if that protocol is supported by Initiated Logout" protocol ([OIDCL]) if that protocol is supported by
the OP. the OP.
An example "session/logout" request: An example "roidc1_session/logout" request:
https://example.com/rdap/session/logout https://example.com/rdap/roidc1_session/logout
The response to this request MUST use the response structures The response to this request MUST use the response structures
specified in RFC 9083 [RFC9083]. In addition, the response MUST specified in RFC 9083 [RFC9083]. In addition, the response MUST
include an indication of the requested operation's success or failure include an indication of the requested operation's success or failure
in the "notices" data structure (including the client identifier). in the "notices" data structure (including the client identifier).
The "notices" data structure MUST also include an indication of the The "notices" data structure MUST also include an indication of the
success or failure of any attempt to logout from the OP or to revoke success or failure of any attempt to logout from the OP or to revoke
the tokens issued by the OP. the tokens issued by the OP.
An example of a "session/logout" response: An example of a "roidc1_session/logout" response:
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_openidc_remote_level_0" "roidc1"
], ],
"lang": "en-US", "lang": "en-US",
"notices": { "notices": {
"title": "Logout Result", "title": "Logout Result",
"description": [ "description": [
"Logout succeeded", "Logout succeeded",
"user.idp.example", "user.idp.example",
"Provider logout failed: Not supported by provider.", "Provider logout failed: Not supported by provider.",
"Token revocation successful." "Token revocation successful."
] ]
} }
} }
Figure 12 Figure 13
In the absence of a "logout" request, an RDAP session MUST be In the absence of a "logout" request, an RDAP session MUST be
terminated by the RDAP server after a server-defined period of time. terminated by the RDAP server after a server-defined period of time.
The server should also take appropriate steps to ensure that the The server should also take appropriate steps to ensure that the
tokens associated with the terminated session cannot be reused. This tokens associated with the terminated session cannot be reused. This
SHOULD include revoking the tokens or logging out from the OP if SHOULD include revoking the tokens or logging out from the OP if
either operation is supported by the OP. either operation is supported by the OP.
4.6. Parameter Processing 4.7. Parameter Processing
Unrecognized query parameters MUST be ignored. An RDAP server that Unrecognized query parameters MUST be ignored. An RDAP server that
processes an authenticated query MUST determine if the End-User processes an authenticated query MUST determine if the End-User
identification information is associated with an OP that is identification information is associated with an OP that is
recognized and supported by the server. Servers MUST reject queries recognized and supported by the server. Servers MUST reject queries
that include identification information that is not associated with a that include identification information that is not associated with a
supported OP by returning an HTTP 501 (Not Implemented) response. An supported OP by returning an HTTP 501 (Not Implemented) response. An
RDAP server that receives a query containing identification RDAP server that receives a query containing identification
information associated with a recognized OP MUST perform the steps information associated with a recognized OP MUST perform the steps
required to authenticate the user with the OP, process the query, and required to authenticate the user with the OP, process the query, and
skipping to change at page 21, line 48 skipping to change at page 25, line 41
implementation used by the RDAP server. implementation used by the RDAP server.
6. RDAP Query Processing 6. RDAP Query Processing
Once an RDAP session is active, an RDAP server MUST determine if the Once an RDAP session is active, an RDAP server MUST determine if the
End-User is authorized to perform any queries that are received End-User is authorized to perform any queries that are received
during the duration of the session. This MAY include rejecting during the duration of the session. This MAY include rejecting
queries outright, and it MAY include omitting or otherwise redacting queries outright, and it MAY include omitting or otherwise redacting
information that the End-User is not authorized to receive. Specific information that the End-User is not authorized to receive. Specific
processing requirements are beyond the scope of this document. A processing requirements are beyond the scope of this document. A
client can end a session explicitly by sending a "session/logout" client can end a session explicitly by sending a "roidc1_session/
request to the RDAP server. A session can also be ended implicitly logout" request to the RDAP server. A session can also be ended
by the server after a server-defined period of time. The status of a implicitly by the server after a server-defined period of time. The
session can be determined at any time by sending a "session/status" status of a session can be determined at any time by sending a
query to the RDAP server. "roidc1_session/status" query to the RDAP server.
An RDAP server MUST maintain session state information for the An RDAP server MUST maintain session state information for the
duration of an active session. This is commonly done using HTTP duration of an active session. This is commonly done using HTTP
cookies as described in RFC 6265 [RFC6265]. Doing so allows End-User cookies as described in RFC 6265 [RFC6265]. Doing so allows End-User
to submit queries without having to explicitly identify and to submit queries without having to explicitly identify and
authenticate themselves for each and every query. authenticate themselves for each and every query.
7. RDAP Conformance 7. RDAP Conformance
RDAP responses that contain values described in this document MUST RDAP responses that contain values described in this document MUST
indicate conformance with this specification by including an indicate conformance with this specification by including an
rdapConformance ([RFC9083]) value of "rdap_openidc_remote_level_0" rdapConformance ([RFC9083]) value of "roidc1" (RDAP OpenID Connect
(to indicate support for one or more remote Authorization Servers), version 1). The information needed to register this value in the
"rdap_openidc_local_level_0" (to indicate support for a local RDAP Extensions Registry is described in Section 8.1.
Authorization Server), or both values if the server supports both
remote and local OpenID Authorization Servers. The information
needed to register these values in the RDAP Extensions Registry is
described in Section 8.1.
Example rdapConformance structure with extension specified: Example rdapConformance structure with extension specified:
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0", "rdap_level_0",
"rdap_openidc_remote_level_0" "roidc1"
] ]
Figure 13 Figure 14
8. IANA Considerations 8. IANA Considerations
8.1. RDAP Extensions Registry 8.1. RDAP Extensions Registry
IANA is requested to register the following values in the RDAP IANA is requested to register the following value in the RDAP
Extensions Registry: Extensions Registry:
Extension identifier: rdap_openidc_remote_level_0 Extension identifier: roidc1
Registry operator: Any
Published specification: This document.
Contact: IESG <iesg@ietf.org>
Intended usage: This extension describes a federated
authentication method for RDAP using OAuth 2.0, OpenID Connect,
and a remote Authorization Server.
Extension identifier: rdap_openidc_local_level_0
Registry operator: Any Registry operator: Any
Published specification: This document. Published specification: This document.
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Intended usage: This extension describes a federated Intended usage: This extension describes version 1 of a federated
authentication method for RDAP using OAuth 2.0, OpenID Connect, authentication method for RDAP using OAuth 2.0 and OpenID Connect.
and a local Authorization Server.
8.2. JSON Web Token Claims Registry 8.2. JSON Web Token Claims Registry
IANA is requested to register the following values in the JSON Web IANA is requested to register the following values in the JSON Web
Token Claims Registry: Token Claims Registry:
Claim Name: "purpose" Claim Name: "rdap_allowed_purposes"
Claim Description: This claim describes the stated purpose for Claim Description: This claim describes the set of RDAP query
submitting a request to access a protected RDAP resource. purposes that are available to an identity that is presented for
access to a protected RDAP resource.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 3.1.4.1 of this document. Specification Document(s): Section 3.1.4.1 of this document.
Claim Name: "dnt" Claim Name: "rdap_dnt_allowed"
Claim Description: This claim contains a JSON boolean literal that Claim Description: This claim contains a JSON boolean literal that
describes an End-User's "do not track" preference for identity describes a "do not track" request for server-side tracking,
tracking, logging, or recording when accessing a protected RDAP logging, or recording of an identity that is presented for access
resource. to a protected RDAP resource.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 3.1.4.2 of this document. Specification Document(s): Section 3.1.4.2 of this document.
8.3. RDAP Query Purpose Registry 8.3. RDAP Query Purpose Registry
IANA is requested to create a new protocol registry to manage RDAP IANA is requested to create a new protocol registry to manage RDAP
query purpose values. This registry should be named "Registration query purpose values. This registry should be named "Registration
Data Access Protocol (RDAP) Query Purpose Values" and should appear Data Access Protocol (RDAP) Query Purpose Values" and should appear
under the "Registration Data Access Protocol (RDAP)" section of under the "Registration Data Access Protocol (RDAP)" section of
IANA's protocol registries. The information to be registered and the IANA's protocol registries. The information to be registered and the
skipping to change at page 29, line 28 skipping to change at page 33, line 5
The author would like to acknowledge the following individuals for The author would like to acknowledge the following individuals for
their contributions to the development of this document: Marc their contributions to the development of this document: Marc
Blanchet, Tom Harrison, Russ Housley, Jasdip Singh, Rhys Smith, Blanchet, Tom Harrison, Russ Housley, Jasdip Singh, Rhys Smith,
Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In addition, the Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In addition, the
Verisign Registry Services Lab development team of Joseph Harvey, Verisign Registry Services Lab development team of Joseph Harvey,
Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin
Singh, and Zhao Zhao provided critical "proof of concept" Singh, and Zhao Zhao provided critical "proof of concept"
implementation experience that helped demonstrate the validity of the implementation experience that helped demonstrate the validity of the
concepts described in this document. concepts described in this document.
Mario Loffredo provided significant feedback based on implementation Pawel Kowalik and Mario Loffredo provided significant text
experience that led to welcome improvements in several sections of contributions that led to welcome improvements in several sections of
this document. His contributions are greatly appreciated. this document. Their contributions are greatly appreciated.
12. References 12. References
12.1. Normative References 12.1. Normative References
[OIDC] OpenID Foundation, "OpenID Connect", [OIDC] OpenID Foundation, "OpenID Connect",
<http://openid.net/connect/>. <http://openid.net/connect/>.
[OIDCC] OpenID Foundation, "OpenID Connect Core incorporating [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating
errata set 1", November 2014, errata set 1", November 2014,
skipping to change at page 32, line 26 skipping to change at page 36, line 4
04: Updated OAuth 2.0 token exchange description and reference due 04: Updated OAuth 2.0 token exchange description and reference due
to publication of RFC 8693. Corrected the RDAP conformance to publication of RFC 8693. Corrected the RDAP conformance
identifier to be registered with IANA. identifier to be registered with IANA.
05: Keepalive refresh. 05: Keepalive refresh.
06: Keepalive refresh. 06: Keepalive refresh.
07: Added "login_hint" description to Section 3.1.3.2. Added some 07: Added "login_hint" description to Section 3.1.3.2. Added some
text to Section 3.1.4.2 to note that "do not track" requires text to Section 3.1.4.2 to note that "do not track" requires
compliance with local regulations. compliance with local regulations.
08: Rework of token management processing in Sections 4 and 5. 08: Rework of token management processing in Sections 4 and 5.
09: Updated RDAP specification references. Added text to describe 09: Updated RDAP specification references. Added text to describe
both local and remote Authorization Server processing. Removed both default and remote Authorization Server processing. Removed
text that described passing of ID Tokens as query parameters. text that described passing of ID Tokens as query parameters.
10: Updated Section 3.1.3.1. Replaced token processing queries with 10: Updated Section 3.1.3.1. Replaced token processing queries with
"login", "session", and "logout" queries. "login", "session", and "logout" queries.
11: Replaced queries with "session/*" queries. Added description of 11: Replaced queries with "session/*" queries. Added description of
"rdap" OAuth scope. Added implementation status information. "rdap" OAuth scope. Added implementation status information.
12: Updated data structure descriptions. Updated Section 8. Minor 12: Updated data structure descriptions. Updated Section 8. Minor
formatting changes due to a move to xml2rfc-v3 markup. formatting changes due to a move to xml2rfc-v3 markup.
13: Added support for OP discovery via OP's Issuer Identifier.
Modified the RDAP conformance text to use "roidc1", and added that
value to extension path segments, data structures, and query
parameters. Changed the "purpose" and "dnt" claims to
"rdap_allowed_purposes" (making it an array) and
"rdap_dnt_allowed". Added the "roidc1_qp" and "roidc1_dnt" query
parameters. Changed the descriptions of "local" OPs to "default"
OPs.
Author's Address Author's Address
Scott Hollenbeck Scott Hollenbeck
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: shollenbeck@verisign.com Email: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
 End of changes. 106 change blocks. 
284 lines changed or deleted 456 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/