draft-ietf-regext-rdap-openid-11.txt   draft-ietf-regext-rdap-openid-12.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track 24 February 2022 Intended status: Standards Track 23 March 2022
Expires: 28 August 2022 Expires: 24 September 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-11 draft-ietf-regext-rdap-openid-12
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 28 August 2022. This Internet-Draft will expire on 24 September 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 41 skipping to change at page 2, line 41
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 Purpose . . . . . . . . . . . . . . . . . 9
3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
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.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Clients with Limited User Interfaces . . . . . . . . 15 4.2.1. Clients with Limited User Interfaces . . . . . . . . 15
4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15 4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15
4.2.1.2. UI-constrained Client Login Polling . . . . . . . 16 4.2.1.2. UI-constrained Client Login Polling . . . . . . . 17
4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17 4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17
4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18 4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18
4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20
4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21 4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21
5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21
6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21
7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22
8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23
8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26
9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 26 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 27
9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 26 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 27
9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Authentication and Access Control . . . . . . . . . . . 28 10.1. Authentication and Access Control . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
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 11, line 20 skipping to change at page 11, line 20
4.1. Data Structures 4.1. Data Structures
This specification describes two new data structures that are used to This specification describes two new data structures that are used to
return information to a client: a "session" data structure that return information to a client: a "session" data structure that
contains information that describes an established session, and a contains information that describes an established session, and a
"deviceInfo" data structure that contains information that describes "deviceInfo" data structure that contains information that describes
an active attempt to establish a session on a UI-constrained device. an active attempt to establish a session on a UI-constrained device.
4.1.1. Session 4.1.1. Session
The "session" data structure is an array that contains two sub- The "session" data structure is an object that contains two sub-
arrays: objects:
1. A "userClaims" array that contains the set of claims associated 1. A "userClaims" object that contains the set of claims associated
with the End-User's identity, with each claim represented as a with the End-User's identity as used/requested by the RDAP server
name-value pair in string format. 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" array that contains two name-value pairs: 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 "session" data structure:
"session": { "session": {
skipping to change at page 12, line 37 skipping to change at page 12, line 37
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 "deviceInfo" data structure.
The "deviceInfo" data structure is an array that contains three name- The "deviceInfo" data structure is an object that contains three
value pairs: 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 "deviceInfo" data structure:
skipping to change at page 15, line 47 skipping to change at page 15, line 47
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]. If the RDAP server supports a local described in RFC 7617 [RFC7617]. If the RDAP server supports a local
Authorization Server, the End-User identifier MAY be omitted. Authorization Server, the End-User identifier MAY be omitted.
Clients can use either of these methods. Servers MUST support both Clients can use either of these methods. Servers MUST support both
methods. 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. An component that contains the client identifier issued by an OP.
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\
https://example.com/rdap/session/device?id=user.idp.example
Figure 5
wget -qO- --keep-session-cookies --save-
cookies\https://example.com/rdap/session/device?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 using curl and an OP. No password is provided.
authorization header:
curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\-c An example using curl and an authorization header:
cookies.txt https://example.com/rdap/session/device
curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\
-c cookies.txt https://example.com/rdap/session/device
Figure 6
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 "deviceInfo" data structure.
An example of a "session/device" response: An example of a "session/device" response:
{ {
skipping to change at page 16, line 35 skipping to change at page 16, line 40
"notices": { "notices": {
"title": "Device Login Result", "title": "Device Login Result",
"description": [ "description": [
"Login succeeded", "Login succeeded",
"user.idp.example" "user.idp.example"
] ]
}, },
"deviceInfo": { "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 5 Figure 7
4.2.1.2. UI-constrained Client Login Polling 4.2.1.2. UI-constrained Client Login Polling
After successful processing of the "session/device" request, the After successful processing of the "session/device" request, the
client MUST send a "session/devicepoll" request to the RDAP server to client MUST send a "session/devicepoll" request to the RDAP server to
continue the login process. This request performs the polling continue the login process. This request performs the polling
function described in RFC 8628 [RFC8628], allowing the RDAP server to function described in RFC 8628 [RFC8628], allowing the RDAP server to
wait for the End-User to enter the information returned from the wait for the End-User to enter the information returned from the
"session/device" request using the interface on their second device. "session/device" request using the interface on their second device.
After the End-User has completed that process, or if the process After the End-User has completed that process, or if the process
fails or times out, the OP will respond to the polling requests with fails or times out, the OP will respond to the polling requests with
an indication of success or failure. An example using wget: an indication of success or failure.
wget -qO- --load-cookies An example using wget:
cookies.txt\https://example.com/rdap/session/devicepoll
wget -qO- --load-cookies cookies.txt\
https://example.com/rdap/session/devicepoll
Figure 8
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/session/devicepoll
Figure 9
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. Session Status
Clients MAY send a query to an RDAP server to determine the status of Clients MAY send a query to an RDAP server to determine the status of
an existing login session using a "session/status" path segment. An an existing login session using a "session/status" path segment. An
skipping to change at page 18, line 37 skipping to change at page 18, line 37
"purpose": "domainNameControl", "purpose": "domainNameControl",
"dnt": false "dnt": false
}, },
"sessionInfo": { "sessionInfo": {
"tokenExpiration": 3490, "tokenExpiration": 3490,
"tokenRefresh": true "tokenRefresh": true
} }
} }
} }
Figure 6 Figure 10
4.4. Session Refresh 4.4. 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 "session/refresh" path segment.
The RDAP server MAY attempt to refresh the access token associated The RDAP server MAY attempt to refresh the access token associated
with the current session as part of extending the session for a with the current session as part of extending the session for a
period of time determined by the RDAP server. As described in RFC period of time determined by the RDAP server. As described in RFC
6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP
server MUST determine if the OP supports token refresh and process server MUST determine if the OP supports token refresh and process
skipping to change at page 19, line 48 skipping to change at page 19, line 48
"purpose": "domainNameControl", "purpose": "domainNameControl",
"dnt": false "dnt": false
}, },
"sessionInfo": { "sessionInfo": {
"tokenExpiration": 3599, "tokenExpiration": 3599,
"tokenRefresh": true "tokenRefresh": true
} }
} }
} }
Figure 7 Figure 11
4.5. Client Logout 4.5. 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 "session/logout" path segment. Access and refresh tokens can be
revoked during the "session/logout" process as described in RFC 7009 revoked during the "session/logout" process as described in RFC 7009
[RFC7009] if supported by the OP (token revocation endpoint support [RFC7009] if supported by the OP (token revocation endpoint support
is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature
SHOULD be used to ensure that the tokens are not mistakenly SHOULD be used to ensure that the tokens are not mistakenly
skipping to change at page 20, line 49 skipping to change at page 20, line 49
"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 8 Figure 12
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.6. Parameter Processing
skipping to change at page 22, line 31 skipping to change at page 22, line 31
described in Section 8.1. 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" "rdap_openidc_remote_level_0"
] ]
Figure 9 Figure 13
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 values in the RDAP
Extensions Registry: Extensions Registry:
* Extension identifier: rdap_openidc_remote_level_0 Extension identifier: rdap_openidc_remote_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 a federated
authentication method for RDAP using OAuth 2.0, OpenID Connect, authentication method for RDAP using OAuth 2.0, OpenID Connect,
and a remote Authorization Server. and a remote Authorization Server.
* Extension identifier: rdap_openidc_local_level_0 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 a federated
authentication method for RDAP using OAuth 2.0, OpenID Connect, authentication method for RDAP using OAuth 2.0, OpenID Connect,
and a local Authorization Server. 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: "purpose"
* Claim Description: This claim describes the stated purpose for Claim Description: This claim describes the stated purpose for
submitting a request to access a protected RDAP resource. submitting a request to access 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: "dnt"
* 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 an End-User's "do not track" preference for identity
tracking, logging, or recording when accessing a protected RDAP tracking, logging, or recording when accessing a protected RDAP
resource. 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 appear under its own query purpose values. This registry should be named "Registration
heading on IANA's protocol listings, using the same title as the name Data Access Protocol (RDAP) Query Purpose Values" and should appear
of the registry. The information to be registered and the procedures under the "Registration Data Access Protocol (RDAP)" section of
to be followed in populating the registry are described in IANA's protocol registries. The information to be registered and the
procedures to be followed in populating the registry are described in
Section 3.1.4.1. Section 3.1.4.1.
Name of registry: Registration Data Access Protocol (RDAP) Query Section at http://www.iana.org/protocols: Registration Data Access
Purpose Values Protocol (RDAP)
Section at http://www.iana.org/protocols:
Registry Title: Registration Data Access Protocol (RDAP) Query Name of registry: Registration Data Access Protocol (RDAP) Query
Purpose Values Purpose Values
Registry Name: Registration Data Access Protocol (RDAP) Query Purpose
Values
Registration Procedure: Specification Required Registration Procedure: Specification Required
Reference: This draft Reference: This document
Required information: See Section 3.1.4.1. Required information: See Section 3.1.4.1.
Review process: "Specification Required" as described in RFC 5226 Review process: "Specification Required" as described in RFC 5226
[RFC5226]. [RFC5226].
Size, format, and syntax of registry entries: See Section 3.1.4.1. Size, format, and syntax of registry entries: See Section 3.1.4.1.
Initial assignments and reservations: Initial assignments and reservations:
-----BEGIN FORM----- Value: domainNameControl Description: Tasks -----BEGIN FORM-----
within the scope of this purpose include creating and managing and
monitoring a registrant's own domain name, including creating the Value: domainNameControl
domain name, updating information about the domain name, transferring
the domain name, renewing the domain name, deleting the domain name, Description: Tasks within the scope of this purpose include
maintaining a domain name portfolio, and detecting fraudulent use of creating and managing and monitoring a registrant's own domain
the Registrant's own contact information. -----END FORM----- name, including creating the domain name, updating information
about the domain name, transferring the domain name, renewing the
domain name, deleting the domain name, maintaining a domain name
portfolio, and detecting fraudulent use of the Registrant's own
contact information.
-----BEGIN FORM----- Value: personalDataProtection Description: Tasks
within the scope of this purpose include identifying the accredited
privacy/proxy provider associated with a domain name and reporting
abuse, requesting reveal, or otherwise contacting the provider.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- Value: technicalIssueResolution Description: -----BEGIN FORM-----
Tasks within the scope of this purpose include (but are not limited
to) working to resolve technical issues, including email delivery Value: personalDataProtection
issues, DNS resolution failures, and web site functional issues.
Description: Tasks within the scope of this purpose include
identifying the accredited privacy/proxy provider associated with
a domain name and reporting abuse, requesting reveal, or otherwise
contacting the provider.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- Value: domainNameCertification Description: -----BEGIN FORM-----
Tasks within the scope of this purpose include a Certification
Authority (CA) issuing an X.509 certificate to a subject identified
by a domain name. -----END FORM-----
-----BEGIN FORM----- Value: individualInternetUse Description: Tasks Value: technicalIssueResolution
within the scope of this purpose include identifying the organization
using a domain name to instill consumer trust, or contacting that
organization to raise a customer complaint to them or file a
complaint about them. -----END FORM-----
-----BEGIN FORM----- Value: businessDomainNamePurchaseOrSale Description: Tasks within the scope of this purpose include (but
Description: Tasks within the scope of this purpose include making are not limited to) working to resolve technical issues, including
purchase queries about a domain name, acquiring a domain name from a email delivery issues, DNS resolution failures, and web site
registrant, and enabling due diligence research. -----END FORM----- functional issues.
-----BEGIN FORM----- Value: academicPublicInterestDNSRResearch
Description: Tasks within the scope of this purpose include academic
public interest research studies about domain names published in the
registration data service, including public information about the
registrant and designated contacts, the domain name's history and
status, and domain names registered by a given registrant (reverse
query). -----END FORM-----
-----BEGIN FORM----- Value: legalActions Description: Tasks within -----END FORM-----
the scope of this purpose include investigating possible fraudulent
use of a registrant's name or address by other domain names, -----BEGIN FORM-----
investigating possible trademark infringement, contacting a
registrant/licensee's legal representative prior to taking legal Value: domainNameCertification
action and then taking a legal action if the concern is not
satisfactorily addressed. -----END FORM----- Description: Tasks within the scope of this purpose include a
Certification Authority (CA) issuing an X.509 certificate to a
subject identified by a domain name.
-----BEGIN FORM----- Value: regulatoryAndContractEnforcement
Description: Tasks within the scope of this purpose include tax
authority investigation of businesses with online presence, Uniform
Dispute Resolution Policy (UDRP) investigation, contractual
compliance investigation, and registration data escrow audits.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- Value: -----BEGIN FORM-----
criminalInvestigationAndDNSAbuseMitigation Description: Tasks within
the scope of this purpose include reporting abuse to someone who can Value: individualInternetUse
investigate and address that abuse, or contacting entities associated
with a domain name during an offline criminal investigation. Description: Tasks within the scope of this purpose include
identifying the organization using a domain name to instill
consumer trust, or contacting that organization to raise a
customer complaint to them or file a complaint about them.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- Value: dnsTransparency Description: Tasks within -----BEGIN FORM-----
the scope of this purpose involve querying the registration data made
public by registrants to satisfy a wide variety of use cases around Value: businessDomainNamePurchaseOrSale
informing the general public. -----END FORM-----
Description: Tasks within the scope of this purpose include making
purchase queries about a domain name, acquiring a domain name from
a registrant, and enabling due diligence research.
-----END FORM-----
-----BEGIN FORM-----
Value: academicPublicInterestDNSRResearch
Description: Tasks within the scope of this purpose include
academic public interest research studies about domain names
published in the registration data service, including public
information about the registrant and designated contacts, the
domain name's history and status, and domain names registered by a
given registrant (reverse query).
-----END FORM-----
-----BEGIN FORM-----
Value: legalActions
Description: Tasks within the scope of this purpose include
investigating possible fraudulent use of a registrant's name or
address by other domain names, investigating possible trademark
infringement, contacting a registrant/licensee's legal
representative prior to taking legal action and then taking a
legal action if the concern is not satisfactorily addressed.
-----END FORM-----
-----BEGIN FORM-----
Value: regulatoryAndContractEnforcement
Description: Tasks within the scope of this purpose include tax
authority investigation of businesses with online presence,
Uniform Dispute Resolution Policy (UDRP) investigation,
contractual compliance investigation, and registration data escrow
audits.
-----END FORM-----
-----BEGIN FORM-----
Value: criminalInvestigationAndDNSAbuseMitigation
Description: Tasks within the scope of this purpose include
reporting abuse to someone who can investigate and address that
abuse, or contacting entities associated with a domain name during
an offline criminal investigation.
-----END FORM-----
-----BEGIN FORM-----
Value: dnsTransparency
Description: Tasks within the scope of this purpose involve
querying the registration data made public by registrants to
satisfy a wide variety of use cases around informing the general
public.
-----END FORM-----
9. Implementation Status 9. Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC. to publication as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942 Internet-Draft, and is based on a proposal described in RFC 7942
[RFC7942]. The description of implementations in this section is [RFC7942]. The description of implementations in this section is
skipping to change at page 26, line 23 skipping to change at page 27, line 22
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
Version -09 of this specification introduced changes that are Version -09 of this specification introduced changes that are
incompatible with earlier implementations. Implementations that are incompatible with earlier implementations. Implementations that are
consistent with this specification will be added as they are consistent with this specification will be added as they are
identified. identified.
9.1. Editor Implementation 9.1. Editor Implementation
* Location: https://procuratus.net/rdap/ Location: https://procuratus.net/rdap/
* Description: This implementation is a functionally-limited RDAP Description: This implementation is a functionally-limited RDAP
server that supports only the path segments described in this server that supports only the path segments described in this
specification. It uses the "jumbojett/OpenID-Connect-PHP" library specification. It uses the "jumbojett/OpenID-Connect-PHP" library
found on GitHub, which appears to no longer be under active found on GitHub, which appears to no longer be under active
development. The library was modified to add support for the development. The library was modified to add support for the
device authorization grant. Session variable management is still device authorization grant. Session variable management is still
a little buggy. Supported OPs include Google (Gmail) and Yahoo. a little buggy. Supported OPs include Google (Gmail) and Yahoo.
* Level of Maturity: This is a "proof of concept" research Level of Maturity: This is a "proof of concept" research
implementation. implementation.
* Coverage: This implementation includes all of the features Coverage: This implementation includes all of the features
described in this specification. described in this specification.
* Version compatibility: Version -11 of this specification. Version compatibility: Version -11+ of this specification.
* Contact Information: Scott Hollenbeck, shollenbeck@verisign.com Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
9.2. Verisign Labs 9.2. Verisign Labs
* Responsible Organization: Verisign Labs Responsible Organization: Verisign Labs
* Location: https://rdap.verisignlabs.com/ Location: https://rdap.verisignlabs.com/
* Description: This implementation includes support for domain Description: This implementation includes support for domain
registry RDAP queries using live data from the .cc and .tv country registry RDAP queries using live data from the .cc and .tv country
code top-level domains and the .career generic top-level domain. code top-level domains and the .career generic top-level domain.
Three access levels are provided based on the authenticated Three access levels are provided based on the authenticated
identity of the client: identity of the client:
1. Unauthenticated: Limited information is returned in response 1. Unauthenticated: Limited information is returned in response
to queries from unauthenticated clients. to queries from unauthenticated clients.
2. Basic: Clients who authenticate using a publicly available 2. Basic: Clients who authenticate using a publicly available
identity provider like Google Gmail or Microsoft Hotmail will identity provider like Google Gmail or Microsoft Hotmail will
receive all of the information available to an unauthenticated receive all of the information available to an unauthenticated
client plus additional registration metadata, but no client plus additional registration metadata, but no
personally identifiable information associated with entities. personally identifiable information associated with entities.
3. Advanced: Clients who authenticate using a more restrictive 3. Advanced: Clients who authenticate using a more restrictive
identity provider will receive all of the information identity provider will receive all of the information
available to a Basic client plus whatever information the available to a Basic client plus whatever information the
server operator deems appropriate for a fully authorized server operator deems appropriate for a fully authorized
client. Currently supported identity providers include those client. Currently supported identity providers include those
developed by Verisign Labs developed by Verisign Labs
(https://testprovider.rdap.verisignlabs.com/) and CZ.NIC (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC
(https://www.mojeid.cz/). (https://www.mojeid.cz/).
* Level of Maturity: This is a "proof of concept" research Level of Maturity: This is a "proof of concept" research
implementation. implementation.
* Coverage: This implementation includes all of the features Coverage: This implementation includes all of the features
described in this specification. described in this specification.
* Version compatibility: Version -07 of this specification. Version compatibility: Version -07 of this specification.
* Contact Information: Scott Hollenbeck, shollenbeck@verisign.com Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
9.3. Viagenie 9.3. Viagenie
* Responsible Organization: Viagenie Responsible Organization: Viagenie
* Location: https://auth.viagenie.ca Location: https://auth.viagenie.ca
* Description: This implementation is an OpenID identity provider Description: This implementation is an OpenID identity provider
enabling users and registries to connect to the federation. It enabling users and registries to connect to the federation. It
also includes a barebone RDAP client and RDAP server in order to also includes a barebone RDAP client and RDAP server in order to
test the authentication framework. Various level of purposes are test the authentication framework. Various level of purposes are
available for testing. available for testing.
* Level of Maturity: This is a "proof of concept" research Level of Maturity: This is a "proof of concept" research
implementation. implementation.
* Coverage: This implementation includes most features described in Coverage: This implementation includes most features described in
this specification as an identity provider. this specification as an identity provider.
* Version compatibility: Version -07 of this specification. Version compatibility: Version -07 of this specification.
* Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca
10. Security Considerations 10. Security Considerations
Security considerations for RDAP can be found in RFC 7481 [RFC7481]. Security considerations for RDAP can be found in RFC 7481 [RFC7481].
Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0
[RFC6749] can be found in their reference specifications. OpenID [RFC6749] can be found in their reference specifications. OpenID
Connect defines optional mechanisms for robust signing and encryption Connect defines optional mechanisms for robust signing and encryption
that can be used to provide data integrity and data confidentiality that can be used to provide data integrity and data confidentiality
services as needed. services as needed.
skipping to change at page 31, line 32 skipping to change at page 32, line 32
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 local 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
formatting changes due to a move to xml2rfc-v3 markup.
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. 56 change blocks. 
150 lines changed or deleted 216 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/