draft-ietf-regext-rdap-openid-06.txt   draft-ietf-regext-rdap-openid-07.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track January 5, 2021 Intended status: Standards Track 28 June 2021
Expires: July 9, 2021 Expires: 30 December 2021
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-06 draft-ietf-regext-rdap-openid-07
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 July 9, 2021. This Internet-Draft will expire on 30 December 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4 3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4
3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5 3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . 6 3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 6
3.1.3.2. Authentication Request . . . . . . . . . . . . . 6 3.1.3.2. Authentication Request . . . . . . . . . . . . . 6
3.1.3.3. End-User Authorization . . . . . . . . . . . . . 7 3.1.3.3. End-User Authorization . . . . . . . . . . . . . 7
3.1.3.4. Authorization Response and Validation . . . . . . 7 3.1.3.4. Authorization Response and Validation . . . . . . 7
3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 7 3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 7
3.1.3.6. Delivery of User Information . . . . . . . . . . 7 3.1.3.6. Delivery of User Information . . . . . . . . . . 8
3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 8 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 8
3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8
3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
4.1. Client Authentication Request and Response . . . . . . . 10 4.1. Client Authentication Request and Response . . . . . . . 10
4.2. Token Request and Response . . . . . . . . . . . . . . . 10 4.2. Token Request and Response . . . . . . . . . . . . . . . 10
4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 11 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 12
4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14 4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14
4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 15
4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15 4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15
5. Clients with Limited User Interfaces . . . . . . . . . . . . 15 5. Clients with Limited User Interfaces . . . . . . . . . . . . 16
5.1. OAuth 2.0 Device Authorization Grant . . . . . . . . . . 16 5.1. OAuth 2.0 Device Authorization Grant . . . . . . . . . . 16
5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16 5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17 6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17
6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17 6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17
6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 17 6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Authentication and Access Control . . . . . . . . . . . . 22 8.1. Authentication and Access Control . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
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
skipping to change at page 7, line 11 skipping to change at page 7, line 11
protocol. The Implicit Flow is more commonly used by clients protocol. The Implicit Flow is more commonly used by clients
implemented in a web browser using a scripting language; it is implemented in a web browser using a scripting language; it is
described in Section 3.2 of the OpenID Connect Core protocol. The described in Section 3.2 of the OpenID Connect Core protocol. The
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]. Other parameters MAY be included. Core protocol [OIDCC]. Apart from these parameters, it is
RECOMMENDED that the RP include the optional "login_hint" parameter
in the request, with the value being that of the "id" from the query
component of the end user's RDAP request. Passing "login_hint"
allows a client to pre-fill login form information, so logging in can
be more convenient for users. Other 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 8 skipping to change at page 9, line 18
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
interpreted by clients and servers. interpreted by clients and servers.
This registry is operated under the "Specification Required" policy This registry is operated under the "Specification Required" policy
defined in RFC 5226 ([RFC5226]). The set of initial values used to defined in RFC 5226 ([RFC5226]). The set of initial values used to
populate the registry as described in Section 6.3 are taken from the populate the registry as described in Section 6.3 are taken from the
final report [1] produced by the Expert Working Group on gTLD final report (https://www.icann.org/en/system/files/files/final-
report-06jun14-en.pdf) produced by the Expert Working Group on gTLD
Directory Services chartered by the Internet Corporation for Assigned Directory Services chartered by the Internet Corporation for Assigned
Names and Numbers (ICANN). Names and Numbers (ICANN).
3.1.4.2. Do Not Track 3.1.4.2. Do Not Track
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" ("dnt") claim can be used to identify an End-User
that is authorized to perform queries without the End-User's that is authorized to perform queries without the End-User's
association with those queries being logged, tracked, or recorded by association with those queries being logged, tracked, or recorded by
the server. Client use of the "dnt" claim is OPTIONAL. Server the server. Client use of the "dnt" claim is OPTIONAL. Server
operators MUST NOT log, track, or record any association of the query operators MUST NOT log, track, or record any association of the query
and the End-User's identity if the End-User is successfully and the End-User's identity if the End-User is successfully
identified and authorized, the "dnt" claim is present, and the value identified and authorized, the "dnt" claim is present, the value of
of the claim is "true". the claim is "true", and accepting the claim complies with local
regulations regarding logging and tracking.
The "dnt" value is represented as a JSON boolean literal. An The "dnt" value is represented as a JSON boolean literal. An
example: example:
{"dnt" : true} {"dnt" : 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"
priviliges in accordance with service policies and regulations. priviliges 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:
skipping to change at page 11, line 14 skipping to change at page 11, line 27
An example (the encoded tokens have been abbreviated for clarity): An example (the encoded tokens have been abbreviated for clarity):
{ {
"access_token" : "eyJ0...NiJ9", "access_token" : "eyJ0...NiJ9",
"id_token" : "eyJ0...EjXk", "id_token" : "eyJ0...EjXk",
"token_type" : "bearer", "token_type" : "bearer",
"expires_in" : "3600" "expires_in" : "3600"
} }
Figure 1 Figure 1
An RDAP server that processes this type of query MUST determine if An RDAP server that processes this type of query MUST determine if
the identifier is associated with an OP that is recognized and the identifier is associated with an OP that is recognized and
supported by the server. Servers MUST reject queries that include an supported by the server. Servers MUST reject queries that include an
identifier associated with an unsupported OP with an HTTP 501 (Not identifier associated with an unsupported OP with an HTTP 501 (Not
Implemented) response. An RDAP server that receives a query Implemented) response. An RDAP server that receives a query
containing an identifier associated with a recognized OP MUST perform containing an identifier associated with a recognized OP MUST perform
the steps required to authenticate the user with the OP using a the steps required to authenticate the user with the OP using a
browser or browser-like client and return encoded tokens to the browser or browser-like client and return encoded tokens to the
client. Note that tokens are typically valid for a limited period of client. Note that tokens are typically valid for a limited period of
skipping to change at page 12, line 11 skipping to change at page 12, line 25
A refresh token is requested using a "tokens" path segment and two A refresh token is requested using a "tokens" path segment and two
query parameters. The first query parameter includes a key value of query parameters. The first query parameter includes a key value of
"id" and a value component that contains the client identifier issued "id" and a value component that contains the client identifier issued
by an OP. The second query parameter includes a key value of by an OP. The second query parameter includes a key value of
"refresh" and a value component of "true". A value component of "refresh" and a value component of "true". A value component of
"false" MUST be processed to return a result that is consistent with "false" MUST be processed to return a result that is consistent with
not including a "refresh" parameter at all as described in not including a "refresh" parameter at all as described in
Section 4.2. An example using "refresh=true": Section 4.2. An example using "refresh=true":
https://example.com/rdap/tokens?id=user.idp.example https://example.com/rdap/tokens?id=user.idp.example&refresh=true
&refresh=true
The response to this query MUST contain all of the response elements The response to this query MUST contain all of the response elements
described in Section 4.2. In addition, the response MUST contain a described in Section 4.2. In addition, the response MUST contain a
name-value pair that represents a refresh token. The name-value pair name-value pair that represents a refresh token. The name-value pair
includes a key value of "refresh_token" and a Base64url-encoded value includes a key value of "refresh_token" and a Base64url-encoded value
that represents the refresh token. that represents the refresh token.
Example refresh token request response (the encoded tokens have been Example refresh token request response (the encoded tokens have been
abbreviated for clarity): abbreviated for clarity):
{ {
"access_token" : "eyJ0...NiJ9", "access_token" : "eyJ0...NiJ9",
"id_token" : "eyJ0...EjXk", "id_token" : "eyJ0...EjXk",
"token_type" : "bearer", "token_type" : "bearer",
"expires_in" : "3600", "expires_in" : "3600",
"refresh_token" : "eyJ0...c8da" "refresh_token" : "eyJ0...c8da"
} }
Figure 2 Figure 2
Once acquired, a refresh token can be used to refresh an access Once acquired, a refresh token can be used to refresh an access
token. An access token is refreshed using a "tokens" path segment token. An access token is refreshed using a "tokens" path segment
and two query parameters. The first query parameter includes a key and two query parameters. The first query parameter includes a key
value of "id" and a value component that contains the client value of "id" and a value component that contains the client
identifier issued by an OP. The second query parameter includes a identifier issued by an OP. The second query parameter includes a
key value of "refresh_token" and a Base64url-encoded value that key value of "refresh_token" and a Base64url-encoded value that
represents the refresh token. An example: represents the refresh token. An example:
https://example.com/rdap/tokens?id=user.idp.example https://example.com/rdap/
&refresh_token=eyJ0...f3jE tokens?id=user.idp.example&refresh_token=eyJ0...f3jE
In addition to any core RDAP response elements, the response to this In addition to any core RDAP response elements, the response to this
query MUST contain four name-value pairs, in any order, representing query MUST contain four name-value pairs, in any order, representing
a returned Refresh Token and Access Token. The Refresh Token is a returned Refresh Token and Access Token. The Refresh Token is
represented using a key value of "refresh_token". The Access Token represented using a key value of "refresh_token". The Access Token
is represented using a key value of "access_token". The access token is represented using a key value of "access_token". The access token
type is represented using a key value of "token_type" and a value of type is represented using a key value of "token_type" and a value of
"bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749 "bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749
[RFC6749]. The lifetime of the access token is represented using a [RFC6749]. The lifetime of the access token is represented using a
key value of "expires_in" and a numerical value that describes the key value of "expires_in" and a numerical value that describes the
skipping to change at page 13, line 20 skipping to change at page 13, line 40
Example access token refresh response (the encoded tokens have been Example access token refresh response (the encoded tokens have been
abbreviated for clarity): abbreviated for clarity):
{ {
"access_token" : "0dac...13b0", "access_token" : "0dac...13b0",
"refresh_token" : "f735...d30c", "refresh_token" : "f735...d30c",
"token_type" : "bearer", "token_type" : "bearer",
"expires_in" : "3600" "expires_in" : "3600"
} }
Figure 3 Figure 3
Access and refresh tokens can be revoked as described in RFC 7009 Access and refresh tokens can be revoked as described in RFC 7009
[RFC7009] by sending a request to an RDAP server that contains a [RFC7009] by sending a request to an RDAP server that contains a
"tokens/revoke" path segment and two query parameters. The first "tokens/revoke" path segment and two query parameters. The first
query parameter includes a key value of "id" and a value component query parameter includes a key value of "id" and a value component
that contains the client identifier issued by an OP. The second that contains the client identifier issued by an OP. The second
query parameter includes a key value of "token" and a Base64url- query parameter includes a key value of "token" and a Base64url-
encoded value that represents either the current refresh token or the encoded value that represents either the current refresh token or the
associated access token. An example: associated access token. An example:
https://example.com/rdap/tokens/revoke?id=user.idp.example https://example.com/rdap/tokens/
&token=f735...d30c revoke?id=user.idp.example&token=f735...d30c
Note that this command will revoke both access and refresh tokens at Note that this command will revoke both access and refresh tokens at
the same time. In addition to any core RDAP response elements, the the same time. In addition to any core RDAP response elements, the
response to this query MUST contain a description of the result of response to this query MUST contain a description of the result of
processing the revocation request within the RDAP "notices" data processing the revocation request within the RDAP "notices" data
structure. structure.
Example token revocation success: Example token revocation success:
"notices" : "notices" :
[ [
{ {
"title" : "Token Revocation Result", "title" : "Token Revocation Result",
"description" : "Token revocation succeeded.", "description" : "Token revocation succeeded.",
} }
], ],
"lang" : "en-US" "lang" : "en-US"
Figure 4 Figure 4
Example token revocation failure: Example token revocation failure:
"notices" : "notices" :
[ [
{ {
"title" : "Token Revocation Result", "title" : "Token Revocation Result",
"description" : "Token revocation failed.", "description" : "Token revocation failed.",
} }
], ],
"errorCode" : 400, "errorCode" : 400,
"lang" : "en-US" "lang" : "en-US"
Figure 5 Figure 5
4.4. Token Exchange 4.4. Token Exchange
ID tokens include an audience parameter that contains the OAuth 2.0 ID tokens include an audience parameter that contains the OAuth 2.0
client_id of the RP as an audience value. In some operational client_id of the RP as an audience value. In some operational
scenarios (such as a client that is providing a proxy service), an RP scenarios (such as a client that is providing a proxy service), an RP
can receive tokens with an audience value that does not include the can receive tokens with an audience value that does not include the
RP's client_id. These tokens might not be trusted by the RP, and the RP's client_id. These tokens might not be trusted by the RP, and the
RP might refuse to accept the tokens. This situation can be remedied RP might refuse to accept the tokens. This situation can be remedied
by having the RP exchange these tokens with the OP for a set of by having the RP exchange these tokens with the OP for a set of
skipping to change at page 15, line 40 skipping to change at page 16, line 13
Registry is described in Section 6.1. Registry is described in Section 6.1.
Example rdapConformance structure with extension specified: Example rdapConformance structure with extension specified:
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0", "rdap_level_0",
"rdap_openidc_level_0" "rdap_openidc_level_0"
] ]
Figure 6 Figure 6
5. Clients with Limited User Interfaces 5. Clients with Limited User Interfaces
The flow described in Section 3.1.3 requires a client to interact The flow described in Section 3.1.3 requires a client to interact
with a server using a web browser. This will not work well in with a server using a web browser. This will not work well in
situations where the client is automated or an end-user is using a situations where the client is automated or an end-user is using a
command line user interface such as curl [2] or wget [3]. There are command line user interface such as curl (http://curl.haxx.se/) or
multiple ways to address this limitation using a web browser on a wget (https://www.gnu.org/software/wget/). There are multiple ways
second device. Two are described here. to address this limitation using a web browser on a second device.
Two are described here.
5.1. OAuth 2.0 Device Authorization Grant 5.1. OAuth 2.0 Device Authorization Grant
The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides one The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides one
method to request user authorization from devices that have an method to request user authorization from devices that have an
Internet connection, but lack a suitable browser for a more Internet connection, but lack a suitable browser for a more
traditional OAuth flow. This method requires a client to use a traditional OAuth flow. This method requires a client 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 browser for entry of a code sequence that is presented on the
constrained device. constrained device.
skipping to change at page 16, line 42 skipping to change at page 17, line 14
Here are two examples using the curl and wget utilities. Start by Here are two examples using the curl and wget utilities. Start by
authenticating with the OP: authenticating with the OP:
https://example.com/rdap/tokens?id=user.idp.example https://example.com/rdap/tokens?id=user.idp.example
Save the token information and pass it to the RP along with the URI Save the token information and pass it to the RP along with the URI
representing the RDAP query. Using curl (encoded tokens have been representing the RDAP query. Using curl (encoded tokens have been
abbreviated for clarity: abbreviated for clarity:
curl -H "Authorization: Bearer eyJ0...NiJ9"\ curl -H "Authorization: Bearer eyJ0...NiJ9"\-k
-k https://example.com/rdap/domain/example.com\ https://example.com/rdap/domain/example.com\?id_token=eyJ0...EjXk
?id_token=eyJ0...EjXk
curl -k https://example.com/rdap/domain/example.com\ curl -k https://example.com/rdap/domain/
?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 example.com\?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9
Using wget: Using wget:
wget --header="Authorization: Bearer eyJ0...NiJ9"\ wget --header="Authorization: Bearer
https://example.com/rdap/domain/example.com\ eyJ0...NiJ9"\https://example.com/rdap/domain/
?id_token=eyJ0...EjXk example.com\?id_token=eyJ0...EjXk
wget https://example.com/rdap/domain/example.com\ wget https://example.com/rdap/domain/
?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 example.com\?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9
Refresh tokens can be useful to automated or command line clients who Refresh tokens can be useful to automated or command line clients who
wish to continue a session without explicitly re-authenticating an wish to continue a session without explicitly re-authenticating an
end user. See Section 4.3 for more information. end user. See Section 4.3 for more information.
6. IANA Considerations 6. IANA Considerations
6.1. RDAP Extensions Registry 6.1. RDAP Extensions Registry
IANA is requested to register the following value in the RDAP IANA is requested to register the following value in the RDAP
Extensions Registry: Extensions Registry:
Extension identifier: rdap_openidc_level_0 * Extension identifier: rdap_openidc_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 and OpenID Connect. authentication method for RDAP using OAuth 2.0 and OpenID Connect.
6.2. JSON Web Token Claims Registry 6.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.
6.3. RDAP Query Purpose Registry 6.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 appear under its own
heading on IANA's protocol listings, using the same title as the name heading on IANA's protocol listings, using the same title as the name
of the registry. The information to be registered and the procedures of the registry. The information to be registered and the procedures
to be followed in populating the registry are described in to be followed in populating the registry are described in
Section 3.1.4.1. Section 3.1.4.1.
skipping to change at page 18, line 31 skipping to change at page 19, line 5
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----- -----BEGIN FORM----- Value: domainNameControl Description: Tasks
Value: domainNameControl within the scope of this purpose include creating and managing and
Description: Tasks within the scope of this purpose include creating monitoring a registrant's own domain name, including creating the
and managing and monitoring a registrant's own domain name, including domain name, updating information about the domain name, transferring
creating the domain name, updating information about the domain name, the domain name, renewing the domain name, deleting the domain name,
transferring the domain name, renewing the domain name, deleting the maintaining a domain name portfolio, and detecting fraudulent use of
domain name, maintaining a domain name portfolio, and detecting the Registrant's own contact information. -----END FORM-----
fraudulent use of the Registrant's own contact information.
-----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: personalDataProtection Description: Tasks
Value: personalDataProtection within the scope of this purpose include identifying the accredited
Description: Tasks within the scope of this purpose include privacy/proxy provider associated with a domain name and reporting
identifying the accredited privacy/proxy provider associated with a abuse, requesting reveal, or otherwise contacting the provider.
domain name and reporting abuse, requesting reveal, or otherwise
contacting the provider.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: technicalIssueResolution Description:
Value: technicalIssueResolution Tasks within the scope of this purpose include (but are not limited
Description: Tasks within the scope of this purpose include (but are to) working to resolve technical issues, including email delivery
not limited to) working to resolve technical issues, including email issues, DNS resolution failures, and web site functional issues.
delivery issues, DNS resolution failures, and web site functional
issues.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: domainNameCertification Description:
Value: domainNameCertification Tasks within the scope of this purpose include a Certification
Description: Tasks within the scope of this purpose include a Authority (CA) issuing an X.509 certificate to a subject identified
Certification Authority (CA) issuing an X.509 certificate to a by a domain name. -----END FORM-----
subject identified by a domain name.
-----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: individualInternetUse Description: Tasks
Value: individualInternetUse within the scope of this purpose include identifying the organization
Description: Tasks within the scope of this purpose include using a domain name to instill consumer trust, or contacting that
identifying the organization using a domain name to instill consumer organization to raise a customer complaint to them or file a
trust, or contacting that organization to raise a customer complaint complaint about them. -----END FORM-----
to them or file a complaint about them.
-----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: businessDomainNamePurchaseOrSale
Value: businessDomainNamePurchaseOrSale
Description: Tasks within the scope of this purpose include making Description: Tasks within the scope of this purpose include making
purchase queries about a domain name, acquiring a domain name from a purchase queries about a domain name, acquiring a domain name from a
registrant, and enabling due diligence research. registrant, and enabling due diligence research. -----END FORM-----
-----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: academicPublicInterestDNSRResearch
Value: academicPublicInterestDNSRResearch
Description: Tasks within the scope of this purpose include academic Description: Tasks within the scope of this purpose include academic
public interest research studies about domain names published in the public interest research studies about domain names published in the
registration data service, including public information about the registration data service, including public information about the
registrant and designated contacts, the domain name's history and registrant and designated contacts, the domain name's history and
status, and domain names registered by a given registrant (reverse status, and domain names registered by a given registrant (reverse
query). query). -----END FORM-----
-----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: legalActions Description: Tasks within
Value: legalActions the scope of this purpose include investigating possible fraudulent
Description: Tasks within the scope of this purpose include use of a registrant's name or address by other domain names,
investigating possible fraudulent use of a registrant's name or investigating possible trademark infringement, contacting a
address by other domain names, investigating possible trademark registrant/licensee's legal representative prior to taking legal
infringement, contacting a registrant/licensee's legal representative action and then taking a legal action if the concern is not
prior to taking legal action and then taking a legal action if the satisfactorily addressed. -----END FORM-----
concern is not satisfactorily addressed.
-----END FORM----- -----BEGIN FORM----- Value: regulatoryAndContractEnforcement
-----BEGIN FORM-----
Value: regulatoryAndContractEnforcement
Description: Tasks within the scope of this purpose include tax Description: Tasks within the scope of this purpose include tax
authority investigation of businesses with online presence, Uniform authority investigation of businesses with online presence, Uniform
Dispute Resolution Policy (UDRP) investigation, contractual Dispute Resolution Policy (UDRP) investigation, contractual
compliance investigation, and registration data escrow audits. compliance investigation, and registration data escrow audits.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value:
Value: criminalInvestigationAndDNSAbuseMitigation criminalInvestigationAndDNSAbuseMitigation Description: Tasks within
Description: Tasks within the scope of this purpose include reporting the scope of this purpose include reporting abuse to someone who can
abuse to someone who can investigate and address that abuse, or investigate and address that abuse, or contacting entities associated
contacting entities associated with a domain name during an offline with a domain name during an offline criminal investigation.
criminal investigation.
-----END FORM----- -----END FORM-----
-----BEGIN FORM----- -----BEGIN FORM----- Value: dnsTransparency Description: Tasks within
Value: dnsTransparency the scope of this purpose involve querying the registration data made
Description: Tasks within the scope of this purpose involve querying public by registrants to satisfy a wide variety of use cases around
the registration data made public by registrants to satisfy a wide informing the general public. -----END FORM-----
variety of use cases around informing the general public.
-----END FORM-----
7. Implementation Status 7. 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 21, line 7 skipping to change at page 21, line 7
According to RFC 7942, "this will allow reviewers and working groups According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
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".
7.1. Verisign Labs 7.1. 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
skipping to change at page 21, line 30 skipping to change at page 21, line 29
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.
Contact Information: Scott Hollenbeck, shollenbeck@verisign.com * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
7.2. Viagenie 7.2. 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.
Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca * Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca
8. Security Considerations 8. 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. Security services for ID Tokens and Access services as needed. Security services for ID Tokens and Access
Tokens (with references to the JWT specification) are described in Tokens (with references to the JWT specification) are described in
skipping to change at page 22, line 31 skipping to change at page 22, line 31
policy. For example, a client who provides an email address (and policy. For example, a client who provides an email address (and
nothing more) might be entitled to receive a subset of the nothing more) might be entitled to receive a subset of the
information that would be available to a client who provides an email information that would be available to a client who provides an email
address, a full name, and a stated purpose. Development of these address, a full name, and a stated purpose. Development of these
access control policies is beyond the scope of this document. access control policies is beyond the scope of this document.
9. Acknowledgements 9. Acknowledgements
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: Tom their contributions to the development of this document: Tom
Harrison, Russ Housley, Rhys Smith, Jaromir Talir, and Alessandro Harrison, Russ Housley, Mario Loffredo, Rhys Smith, Jaromir Talir,
Vesely. In addition, the Verisign Registry Services Lab development and Alessandro Vesely. In addition, the Verisign Registry Services
team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena, Lab development team of Joseph Harvey, Andrew Kaizer, Sai Mogali,
Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof Anurag Saxena, Swapneel Sheth, Nitin Singh, and Zhao Zhao provided
of concept" implementation experience that helped demonstrate the critical "proof of concept" implementation experience that helped
validity of the concepts described in this document. demonstrate the validity of the concepts described in this document.
10. References 10. References
10.1. Normative References 10.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 23, line 49 skipping to change at page 23, line 49
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", RFC 7480, Registration Data Access Protocol (RDAP)", STD 95,
DOI 10.17487/RFC7480, March 2015, RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>. <https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", RFC 7481, Registration Data Access Protocol (RDAP)", STD 95,
DOI 10.17487/RFC7481, March 2015, RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>. <https://www.rfc-editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482, Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015, DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>. <https://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483, Registration Data Access Protocol (RDAP)", RFC 7483,
DOI 10.17487/RFC7483, March 2015, DOI 10.17487/RFC7483, March 2015,
skipping to change at page 25, line 5 skipping to change at page 25, line 5
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
10.3. URIs
[1] https://www.icann.org/en/system/files/files/final-report-
06jun14-en.pdf
[2] http://curl.haxx.se/
[3] https://www.gnu.org/software/wget/
Appendix A. Change Log Appendix A. Change Log
00: Initial working group version ported from draft-hollenbeck- 00: Initial working group version ported from draft-hollenbeck-
regext-rdap-openid-10. regext-rdap-openid-10.
01: Modified ID Token delivery approach to note proper use of an 01: Modified ID Token delivery approach to note proper use of an
HTTP bearer authorization header. HTTP bearer authorization header.
02: Modified token delivery approach (access token is the bearer 02: Modified token delivery approach (access token is the bearer
token) to note proper use of an HTTP bearer authorization header, token) to note proper use of an HTTP bearer authorization header,
fixing the change made in -01. fixing the change made in -01.
03: Updated OAuth 2.0 Device Authorization Grant description and 03: Updated OAuth 2.0 Device Authorization Grant description and
reference due to publication of RFC 8628. reference due to publication of RFC 8628.
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
text to Section 3.1.4.2 to note that "do not track" requires
compliance with local regulations.
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
USA 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. 62 change blocks. 
162 lines changed or deleted 139 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/