draft-ietf-regext-rdap-openid-08.txt   draft-ietf-regext-rdap-openid-09.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track 8 November 2021 Intended status: Standards Track 18 January 2022
Expires: 12 May 2022 Expires: 22 July 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-08 draft-ietf-regext-rdap-openid-09
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 12 May 2022. This Internet-Draft will expire on 22 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 11 4.2. Token Request and Response . . . . . . . . . . . . . . . 11
4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 12 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 13
4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14 4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 15
4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 15
4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15 4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . 18
6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 18 6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
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
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
skipping to change at page 3, line 24 skipping to change at page 3, line 21
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].
RDAP is specified in multiple documents, including "HTTP Usage in the RDAP is specified in multiple documents, including "HTTP Usage in the
Registration Data Access Protocol (RDAP)" [RFC7480], "Security Registration Data Access Protocol (RDAP)" [RFC7480], "Security
Services for the Registration Data Access Protocol (RDAP)" [RFC7481], Services for the Registration Data Access Protocol (RDAP)" [RFC7481],
"Registration Data Access Protocol Query Format" [RFC7482], and "JSON "Registration Data Access Protocol Query Format" [RFC9082], and "JSON
Responses for the Registration Data Access Protocol (RDAP)" Responses for the Registration Data Access Protocol (RDAP)"
[RFC7483]. RFC 7481 describes client identification and [RFC9083]. RFC 7481 describes client identification and
authentication services that can be used with RDAP, but it does not authentication services that can be used with RDAP, but it does not
specify how any of these services can (or should) be used with RDAP. specify how any of these services can (or should) be used with RDAP.
1.1. Problem Statement 1.1. Problem Statement
The traditional "user name and password" authentication method does The traditional "user name and password" authentication method does
not scale well in the RDAP ecosystem. Assuming that all domain name not scale well in the RDAP ecosystem. Assuming that all domain name
and address registries will eventually provide RDAP service, it is and address registries will eventually provide RDAP service, it is
impractical and inefficient for users to secure login credentials impractical and inefficient for users to secure login credentials
from the hundreds of different server operators. Authentication from the hundreds of different server operators. Authentication
skipping to change at page 5, line 40 skipping to change at page 5, line 31
Core [OIDCC] Entity or End-User. An RDAP server performs the role of Core [OIDCC] Entity or End-User. An RDAP server performs the role of
an OpenID Connect Core Relying Party (RP). Additional terms from an OpenID Connect Core Relying Party (RP). Additional terms from
Section 1.2 of the OpenID Connect Core specification are incorporated Section 1.2 of the OpenID Connect Core specification are incorporated
by reference. by reference.
3.1.2. Overview 3.1.2. Overview
At a high level, RDAP authentication of a browser-based client using At a high level, RDAP authentication of a browser-based client using
OpenID Connect requires completion of the following steps: OpenID Connect requires completion of the following steps:
1. An RDAP client (acting as an OpenID End-User) sends an HTTP (or 1. An RDAP client sends an RDAP "help" query to an RDAP server to
HTTPS) query containing OAuth 2.0 request parameters to an RDAP determine the type of OpenID Authorization Server that's used by
server. the RDAP server. This information is returned in the
2. The RDAP server (acting as an OpenID Relying Party (RP)) prepares rdapConformance section of the response. A value of
an Authentication Request containing the desired request "rdap_openidc_local_level_0" indicates that the server uses a
parameters. local Authorization Server. A value of
3. The RDAP server sends the RDAP client and Authentication Request "rdap_openidc_remote_level_0" indicates that the server uses a
to an Authorization Server operated by an OpenID Provider (OP) remote Authorization Server.
using an HTTP redirect. 2. An RDAP client (acting as an OpenID End-User) sends a "tokens"
4. The Authorization Server authenticates the RDAP Client. request (see Section 4.2) to an RDAP server. The request MUST
5. The Authorization Server obtains RDAP Client consent/ include an "id" parameter if the server uses only a remote
authorization. Authorization Server. The "id" parameter is OPTIONAL if the
server uses a local Authorization Server.
3. The RDAP server (acting as an OpenID Relying Party (RP))
prepares an Authentication Request containing the desired
request parameters.
4. The RDAP server sends the RDAP client and Authentication Request
to an Authorization Server operated by an OpenID Provider (OP)
using an HTTP redirect.
5. The Authorization Server authenticates the RDAP Client.
6. The Authorization Server sends the RDAP Client back to the RDAP 6. The Authorization Server obtains RDAP Client consent/
server with an Authorization Code using an HTTP redirect. authorization.
7. The RDAP server requests a response using the Authorization Code 7. The Authorization Server sends the RDAP Client back to the RDAP
at the Token Endpoint. server with an Authorization Code using an HTTP redirect.
8. The RDAP server receives a response that contains an ID Token and 8. The RDAP server requests a response using the Authorization Code
Access Token in the response body. at the Token Endpoint.
9. The RDAP server validates the ID Token and retrieves the RDAP 9. The RDAP server receives a response that contains an ID Token
client's Subject Identifier. and Access Token in the response body.
10. The RDAP server validates the ID Token and retrieves the RDAP
client's Subject Identifier.
The RDAP server can then make identification, authorization, and The RDAP server can then make identification, authorization, and
access control decisions based on local policies, the ID Token access control decisions based on local policies, the ID Token
received from the OP, and the received Claims. Note that OpenID received from the OP, and the received Claims. Note that OpenID
Connect describes different process flows for other types of clients, Connect describes different process flows for other types of clients,
such as script-based or command line clients. such as script-based or command line clients.
3.1.3. RDAP Authentication and Authorization Steps 3.1.3. RDAP Authentication and Authorization Steps
End-Users MUST possess an identifier (an OpenID) issued by an OP to End-Users MUST possess an identifier (an OpenID) issued by an OP to
use OpenID Connect with RDAP. An OP MUST include support for the use OpenID Connect with RDAP. An OP SHOULD include support for the
claims described in Section 3.1.4 to provide additional information claims described in Section 3.1.4 to provide additional information
needed for RDAP End-User authorization. OpenID Connect requires RPs needed for RDAP End-User authorization. OpenID Connect requires RPs
to register with OPs to use OpenID Connect services for an End-User. to register with OPs to use OpenID Connect services for an End-User.
That process is described by the "OpenID Connect Dynamic Client That process is described by the "OpenID Connect Dynamic Client
Registration" protocol [OIDCR]. Registration" protocol [OIDCR].
3.1.3.1. Provider Discovery 3.1.3.1. Provider Discovery
An RDAP server/RP needs to receive an identifier from an End-User An RDAP server/RP needs to receive an identifier from an End-User
that can be used to discover the End-User's OP. That process is that can be used to discover the End-User's OP. That process is
skipping to change at page 10, line 17 skipping to change at page 10, line 17
privileges in accordance with service policies and regulations. privileges in accordance with service policies and regulations.
Specification of these policies and regulations is beyond the scope Specification of these policies and regulations is beyond the scope
of this document. of this document.
4. Protocol Parameters 4. Protocol Parameters
This specification adds the following protocol parameters to RDAP: This specification adds the following protocol parameters to RDAP:
1. A query parameter to request authentication for a specific end- 1. A query parameter to request authentication for a specific end-
user identity. user identity.
2. A path segment to request an ID Token and an Access Token for a 2. A path segment to request an tokens for a specific end-user
specific end-user identity. identity.
3. A query parameter to deliver an ID Token and an Access Token for 3. A query parameter to deliver an Access Token for use with an RDAP
use with an RDAP query. query.
4.1. Client Authentication Request and Response 4.1. Client Authentication Request and Response
Client authentication is requested using one of two methods: either Client authentication is requested using one of three methods:
by 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 1. by adding a query component to an RDAP request URI using the
HTTP authorization header for the Basic authentication scheme as syntax described in Section 3.4 of RFC 3986 [RFC3986],
described in RFC 7617 [RFC7617]. Clients can use either method. 2. by including an HTTP authorization header for the Basic
Servers MUST support both methods. authentication scheme as described in RFC 7617 [RFC7617], or
3. by including an HTTP authorization header with a Bearer token as
described in RFC 6750 [RFC6750].
Clients can use any of these methods. Servers MUST support all
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. An
example for client identifier "user.idp.example": example for client identifier "user.idp.example":
https://example.com/rdap/domain/example.com?id=user.idp.example https://example.com/rdap/domain/example.com?id=user.idp.example
The authorization header for the Basic authentication scheme contains The authorization header for the Basic authentication scheme contains
a Base64-encoded representation of the client identifier issued by an a Base64-encoded representation of the client identifier issued by an
OP. No password is provided. An example for client identifier OP. No password is provided. An example for client identifier
"user.idp.example": "user.idp.example":
https://example.com/rdap/domain/example.com Authorization: Basic https://example.com/rdap/domain/example.com
dXNlci5pZHAuZXhhbXBsZQ==
Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==
The HTTP Bearer authorization header contains a Base64url-encoded
representation of the Access Token issued by an OP. An example that
has been abbreviated for clarity:
https://example.com/rdap/domain/example.com
Authorization: Bearer eyJ0...NiJ9
The response to an authenticated query MUST use the response The response to an authenticated query MUST use the response
structures specified in RFC 7483 [RFC7483]. Information that the structures specified in RFC 9083 [RFC9083]. Information that the
end-user is not authorized to receive MUST be omitted from the end-user is not authorized to receive MUST be omitted from the
response. response.
4.2. Token Request and Response 4.2. Token Request and Response
Clients MAY send a request to an RDAP server to authenticate an end- Clients MAY send a request to an RDAP server to authenticate an end-
user and return tokens (an ID Token, an Access Token, and a Refresh user and return tokens (an ID Token, an Access Token, and a Refresh
Token) from an OP that can be then be passed to the RP/RDAP server to Token) from an OP that can be then be passed to the RP/RDAP server to
authenticate and process subsequent queries. An access token can be authenticate and process subsequent queries. An Access Token can be
refreshed as described in Section 12 of the OpenID Connect Core refreshed as described in Section 12 of the OpenID Connect Core
protocol [OIDCC] and Section 6 of RFC 6749 [RFC6749]. Clients can protocol [OIDCC] and Section 6 of RFC 6749 [RFC6749]. Clients can
take advantage of this functionality if it is supported by the OP and take advantage of this functionality if it is supported by the OP and
accepted by the RDAP server. Identity provider authentication is accepted by the RDAP server. Identity provider authentication is
requested using a "tokens" path segment and a query parameter with a requested using a "tokens" path segment and an OPTIONAL query
key value of "id" and a value component that contains the client parameter (the query parameter isn't needed if the RDAP server is
identifier issued by an OP. An example: using a local OP) with a key value of "id" and a value component that
contains the client identifier issued by an OP. An example for use
with a remote OP:
https://example.com/rdap/tokens?id=user.idp.example https://example.com/rdap/tokens?id=user.idp.example
An example for use with a local OP:
https://example.com/rdap/tokens
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 five name-value pairs, in any order, representing query MUST contain five name-value pairs, in any order, representing
the returned ID Token, Access Token, and Refresh Token. The ID Token the returned ID Token, Access Token, and Refresh Token. The ID Token
is represented using a key value of "id_token". The Access Token is is represented using a key value of "id_token". The Access Token is
represented using a key value of "access_token". The access token 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
lifetime in seconds of the access token as described in Section 4.2.2 lifetime in seconds of the Access Token as described in Section 4.2.2
of RFC 6749 [RFC6749]. The Refresh Token is represented using a key of RFC 6749 [RFC6749]. The Refresh Token is represented using a key
value of "refresh_token". The token values returned in the RDAP value of "refresh_token". The token values returned in the RDAP
server response MUST be Base64url-encoded as described in RFCs 7515 server response MUST be Base64url-encoded as described in RFCs 7515
[RFC7515] and 7519 [RFC7519]. [RFC7515] and 7519 [RFC7519].
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",
skipping to change at page 12, line 11 skipping to change at page 12, line 43
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
time and new tokens will be required when an existing token's time and new tokens will be required when an existing token's
validity period has expired. validity period has expired.
The tokens can then be passed to the server for use with an RDAP The Access Token can then be passed to the server for use with an
query by passing the encoded ID Token as a query parameter with a key RDAP query by including the encoded token in an HTTP Bearer
value of "id_token" and the encoded Access Token in an HTTP Bearer authorization header [RFC6750]. An example (the encoded token has
authorization header [RFC6750]. An example (the encoded tokens have been abbreviated for clarity):
been abbreviated and the URI split across multiple lines for
clarity):
https://example.com/rdap/domain/example.com?id_token=eyJ0...EjXk https://example.com/rdap/domain/example.com?id=user.idp.example
Authorization: Bearer eyJ0...NiJ9 Authorization: Bearer eyJ0...NiJ9
The RDAP server can retrieve user information (such as claims
The response to an authenticated query MUST use the response associated with the user) from the OP by querying the UserInfo
structures specified in RFC 7483 [RFC7483]. Information that the endpoint using the given Access Token. The user information can then
end-user is not authorized to receive MUST be omitted from the be used to determine if the uiser is authorized to receive the
response. requested information. The response to an authenticated query MUST
use the response structures specified in RFC 9083 [RFC9083].
Information that the end-user is not authorized to receive MUST be
omitted from the response.
4.3. Token Refresh and Revocation 4.3. Token Refresh and Revocation
The refresh token returned in the token response can be used to The refresh token returned in the token response can be used to
refresh an access token. An access token is refreshed using a refresh an Access Token. An Access Token is refreshed using a
"tokens" path segment and a query parameter. The query parameter "tokens" path segment and a query parameter. The query parameter
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. An example: that represents the refresh token. An example:
https://example.com/rdap/tokens?refresh_token=eyJ0...c8da https://example.com/rdap/tokens?refresh_token=eyJ0...c8da
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
lifetime in seconds of the access token as described in Section 4.2.2 lifetime in seconds of the Access Token as described in Section 4.2.2
of RFC 6749 [RFC6749]. The token values returned in the RDAP server of RFC 6749 [RFC6749]. The token values returned in the RDAP server
response MUST be Base64url-encoded as described in RFCs 7515 response MUST be Base64url-encoded as described in RFCs 7515
[RFC7515] and 7519 [RFC7519]. [RFC7515] and 7519 [RFC7519].
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 2 Figure 2
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 a query parameter. The query "tokens/revoke" path segment and a query parameter. The query
parameter includes a key value of "token" and a Base64url-encoded parameter includes a key value of "token" and a Base64url-encoded
value that represents either the current refresh token or the value that represents the current refresh token. An example:
associated access token. An example:
https://example.com/rdap/tokens/revoke?token=f735...d30c https://example.com/rdap/tokens/revoke?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:
skipping to change at page 14, line 31 skipping to change at page 15, line 19
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
trusted tokens that reset the audience parameter. This token trusted tokens that reset the audience parameter. This token
exchange protocol is described in RFC 8693 [RFC8693]. exchange protocol is described in RFC 8693 [RFC8693].
4.5. Parameter Processing 4.5. Parameter Processing
Unrecognized query parameters MUST be ignored. An RDAP request that Unrecognized query parameters MUST be ignored. An RDAP server that
does not include an "id" query component MUST be processed as an processes an authenticated query MUST determine if the end-user
unauthenticated query. An RDAP server that processes an identification information is associated with an OP that is
authenticated query MUST determine if the identifier is associated recognized and supported by the server. Servers MUST reject queries
with an OP that is recognized and supported by the server. Servers that include identification information that is not associated with a
MUST reject queries that include an identifier associated with an supported OP by returning an HTTP 501 (Not Implemented) response. An
unsupported OP with an HTTP 501 (Not Implemented) response. An RDAP RDAP server that receives a query containing identification
server that receives a query containing an identifier associated with information associated with a recognized OP MUST perform the steps
a recognized OP MUST perform the steps required to authenticate the required to authenticate the user with the OP, process the query, and
user with the OP, process the query, and return an RDAP response that return an RDAP response that is appropriate for the end user's level
is appropriate for the end user's level of authorization and access. of authorization and access.
An RDAP server that receives a query containing tokens associated An RDAP server that receives a query containing tokens associated
with a recognized OP and authenticated end user MUST process the with a recognized OP and authenticated end user MUST process the
query and return an RDAP response that is appropriate for the end query and return an RDAP response that is appropriate for the end
user's level of authorization and access. Errors based on processing user's level of authorization and access. Errors based on processing
either the ID Token or the Access Token MUST be signaled with an either the ID Token or the Access Token MUST be signaled with an
appropriate HTTP status code as described in Section 3.1 of RFC 6750 appropriate HTTP status code as described in Section 3.1 of RFC 6750
[RFC6750]. [RFC6750].
On receiving a query containing tokens, the RDAP server MUST validate On receiving a query containing tokens, the RDAP server MUST validate
the ID Token. It can do this independently of the OP, because the ID the identity information received from a UserInfo endpoint. It can
Token is a JWT that contains all the data necessary for validation. do this independently of the OP, because the response is a JSON
The Access Token, however, is an opaque value, and can only be object that contains all the data necessary for validation. The
validated by sending a request using it to the UserInfo Endpoint and Access Token can be validated by sending a request using it to the
confirming that a successful response is received. This is different UserInfo Endpoint and confirming that a successful response is
from the OpenID Connect Authorization Code and Implicit flows, where received. This is different from the OpenID Connect Authorization
the Access Token can be validated against the at_hash claim from the Code and Implicit flows, where the Access Token can be validated
ID Token. With a query containing tokens, the Access Token might not against the at_hash claim from the ID Token. With a query containing
validate against the at_hash claim because the Access Token may have tokens, the Access Token might not validate against the at_hash claim
been refreshed since the ID Token was issued. because the Access Token may have been refreshed since the ID Token
was issued.
An RDAP server that processes requests without needing the UserInfo An RDAP server that processes requests without needing the UserInfo
claims does not need to retrieve the claims merely in order to claims does not need to retrieve the claims merely in order to
validate the Access Token. Similarly, an RDAP server that has cached validate the Access Token. Similarly, an RDAP server that has cached
the UserInfo claims for an end user, in accordance with the HTTP the UserInfo claims for an end user, in accordance with the HTTP
headers of a previous UserInfo Endpoint response, does not need to headers of a previous UserInfo Endpoint response, does not need to
retrieve those claims again in order to revalidate the Access Token. retrieve those claims again in order to re-validate the Access Token.
4.6. RDAP Conformance 4.6. RDAP Conformance
RDAP responses that contain values described in this document MUST RDAP responses that contain values described in this document MUST
indicate conformance with this specification by including an indicate conformance with this specification by including an
rdapConformance ([RFC7483]) value of "rdap_openidc_level_0". The rdapConformance ([RFC9083]) value of "rdap_openidc_remote_level_0" or
"rdap_openidc_local_level_0". Both values MAY be present if a server
supports both local and remote OpenID Authorization Servers. The
information needed to register this value in the RDAP Extensions information needed to register this value in the RDAP Extensions
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_remote_level_0"
] ]
Figure 5 Figure 5
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 an end-user to interact
with a server using a web browser. This will not work well in with a server using a user interface that can process HTTP. This
situations where the client is automated or an end-user is using a will not work well in situations where the client is automated or an
command line user interface such as curl (http://curl.haxx.se/) or end-user is using a command line user interface such as curl
wget (https://www.gnu.org/software/wget/). There are multiple ways (http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/).
to address this limitation using a web browser on a second device. There are multiple ways to address this limitation using a web
Two are described here. 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 25 skipping to change at page 17, line 15
5.2. Manual Token Management 5.2. Manual Token Management
A second method of requesting user authorization from a constrained A second method of requesting user authorization from a constrained
device is possible by producing and managing tokens manually as device is possible by producing and managing tokens manually as
follows: follows:
1. Authenticate with the OP as described in Section 4.2 using a 1. Authenticate with the OP as described in Section 4.2 using a
browser or browser-like client. browser or browser-like client.
2. Store the returned ID Token, Access Token, and Refresh Token 2. Store the returned ID Token, Access Token, and Refresh Token
locally. locally.
3. Send a request to the content provider/RP along with the ID Token 3. Send a request to the content provider/RP along with the client
and Access Token received from the OP. ID and Access Token received from the OP.
The Access Token MAY be passed to the RP in an HTTP "Authorization" The Access Token MUST be passed to the RP in an HTTP "Authorization"
header [RFC7235] or as a query parameter. The Access Token MUST be header [RFC7235]. The Access Token MUST be specified using the
specified using the "Bearer" authentication scheme [RFC6750] if it is "Bearer" authentication scheme [RFC6750].
passed in an "Authorization" header. The ID Token MUST be passed to
the RP as a query parameter.
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"\-k curl -H "Authorization: Bearer eyJ0...NiJ9"\-k
https://example.com/rdap/domain/example.com\?id_token=eyJ0...EjXk https://example.com/rdap/domain/example.com\?id=user.idp.example
curl -k https://example.com/rdap/domain/
example.com\?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9
Using wget: Using wget:
wget --header="Authorization: Bearer wget --header="Authorization: Bearer
eyJ0...NiJ9"\https://example.com/rdap/domain/ eyJ0...NiJ9"\https://example.com/rdap/domain/
example.com\?id_token=eyJ0...EjXk example.com\id=user.idp.example
wget https://example.com/rdap/domain/
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 values in the RDAP
Extensions Registry: Extensions Registry:
* Extension identifier: rdap_openidc_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 and OpenID Connect. authentication method for RDAP using OAuth 2.0, OpenID Connect,
and a remote Authorization Server.
* Extension identifier: rdap_openidc_local_level_0
* Registry operator: Any
* Published specification: This document.
* Contact: IESG <iesg@ietf.org>
* Intended usage: This extension describes a federated
authentication method for RDAP using OAuth 2.0, OpenID Connect,
and a local Authorization Server.
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
skipping to change at page 20, line 38 skipping to change at page 21, line 30
implementations or their features. Readers are advised to note that implementations or their features. Readers are advised to note that
other implementations may exist. other implementations may exist.
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 Version -09 of this specification introduced changes that are
incompatible with earlier implementations. Implementations that are
* Responsible Organization: Verisign Labs consistent with this specification will be added as they are
* Location: https://rdap.verisignlabs.com/ identified.
* Description: This implementation includes support for domain
registry RDAP queries using live data from the .cc and .tv country
code top-level domains and the .career generic top-level domain.
Three access levels are provided based on the authenticated
identity of the client:
1. Unauthenticated: Limited information is returned in response
to queries from unauthenticated clients.
2. Basic: Clients who authenticate using a publicly available
identity provider like Google Gmail or Microsoft Hotmail will
receive all of the information available to an unauthenticated
client plus additional registration metadata, but no
personally identifiable information associated with entities.
3. Advanced: Clients who authenticate using a more restrictive
identity provider will receive all of the information
available to a Basic client plus whatever information the
server operator deems appropriate for a fully authorized
client. Currently supported identity providers include those
developed by Verisign Labs
(https://testprovider.rdap.verisignlabs.com/) and CZ.NIC
(https://www.mojeid.cz/).
* Level of Maturity: This is a "proof of concept" research
implementation.
* Coverage: This implementation includes all of the features
described in this specification.
* Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
7.2. Viagenie
* Responsible Organization: Viagenie
* Location: https://auth.viagenie.ca
* Description: This implementation is an OpenID identity provider
enabling users and registries to connect to the federation. It
also includes a barebone RDAP client and RDAP server in order to
test the authentication framework. Various level of purposes are
available for testing.
* Level of Maturity: This is a "proof of concept" research
implementation.
* Coverage: This implementation includes most features described in
this specification as an identity provider.
* 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 24, line 5 skipping to change at page 24, line 5
[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)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, 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)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, 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
Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483,
DOI 10.17487/RFC7483, March 2015,
<https://www.rfc-editor.org/info/rfc7483>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
skipping to change at page 24, line 41 skipping to change at page 24, line 31
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Authorization Grant", RFC 8628, "OAuth 2.0 Device Authorization Grant", RFC 8628,
DOI 10.17487/RFC8628, August 2019, DOI 10.17487/RFC8628, August 2019,
<https://www.rfc-editor.org/info/rfc8628>. <https://www.rfc-editor.org/info/rfc8628>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020, DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>. <https://www.rfc-editor.org/info/rfc8693>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
10.2. Informative References 10.2. Informative References
[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>.
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 07: Added "login_hint" description to Section 3.1.3.2. Added some
text to Section 3.1.4.2 to note that "do not track" requires text to Section 3.1.4.2 to note that "do not track" requires
compliance with local regulations. compliance with local regulations.
08: Rework of token management processing in Sections 4 and 5. 08: Rework of token management processing in Sections 4 and 5.
09: Updated RDAP specification references. Added text to describe
both local and remote Authorization Server processing. Removed
text that described passing of ID Tokens as query parameters.
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
 End of changes. 52 change blocks. 
184 lines changed or deleted 175 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/