draft-ietf-regext-rdap-openid-13.txt   draft-ietf-regext-rdap-openid-14.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track 18 May 2022 Intended status: Standards Track 24 May 2022
Expires: 19 November 2022 Expires: 25 November 2022
Federated Authentication for the Registration Data Access Protocol Federated Authentication for the Registration Data Access Protocol
(RDAP) using OpenID Connect (RDAP) using OpenID Connect
draft-ietf-regext-rdap-openid-13 draft-ietf-regext-rdap-openid-14
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 19 November 2022. This Internet-Draft will expire on 25 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4.2.2. OP Issuer Identifier . . . . . . . . . . . . . . . . 15 4.2.2. OP Issuer Identifier . . . . . . . . . . . . . . . . 15
4.2.3. Login Response . . . . . . . . . . . . . . . . . . . 15 4.2.3. Login Response . . . . . . . . . . . . . . . . . . . 15
4.2.4. Clients with Limited User Interfaces . . . . . . . . 17 4.2.4. Clients with Limited User Interfaces . . . . . . . . 17
4.2.4.1. UI-constrained Client Login . . . . . . . . . . . 17 4.2.4.1. UI-constrained Client Login . . . . . . . . . . . 17
4.2.4.2. UI-constrained Client Login Polling . . . . . . . 19 4.2.4.2. UI-constrained Client Login Polling . . . . . . . 19
4.3. RDAP Query Parameters . . . . . . . . . . . . . . . . . . 19 4.3. RDAP Query Parameters . . . . . . . . . . . . . . . . . . 19
4.3.1. RDAP Query Purpose . . . . . . . . . . . . . . . . . 20 4.3.1. RDAP Query Purpose . . . . . . . . . . . . . . . . . 20
4.3.2. RDAP Do Not Track . . . . . . . . . . . . . . . . . . 20 4.3.2. RDAP Do Not Track . . . . . . . . . . . . . . . . . . 20
4.4. Session Status . . . . . . . . . . . . . . . . . . . . . 20 4.4. Session Status . . . . . . . . . . . . . . . . . . . . . 20
4.5. Session Refresh . . . . . . . . . . . . . . . . . . . . . 22 4.5. Session Refresh . . . . . . . . . . . . . . . . . . . . . 22
4.6. Client Logout . . . . . . . . . . . . . . . . . . . . . . 23 4.6. Client Logout . . . . . . . . . . . . . . . . . . . . . . 24
4.7. Parameter Processing . . . . . . . . . . . . . . . . . . 25 4.7. Parameter Processing . . . . . . . . . . . . . . . . . . 25
5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 25 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 25
6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 25 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 26
7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 26 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 26 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 27
8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 26 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 27
8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 27 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 27
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 30
9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 31 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 31
9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 31
9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10.1. Authentication and Access Control . . . . . . . . . . . 32 10.1. Authentication and Access Control . . . . . . . . . . . 33
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The Registration Data Access Protocol (RDAP) provides "RESTful" web The Registration Data Access Protocol (RDAP) provides "RESTful" web
services to retrieve registration metadata from domain name and services to retrieve registration metadata from domain name and
regional internet registries. RDAP allows a server to make access regional internet registries. RDAP allows a server to make access
control decisions based on client identity, and as such it includes control decisions based on client identity, and as such it includes
support for client identification features provided by the Hypertext support for client identification features provided by the Hypertext
Transfer Protocol (HTTP) [RFC7230]. Transfer Protocol (HTTP) [RFC7230].
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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]. Apart from these parameters, it is Core protocol [OIDCC]. Apart from these parameters, it is
RECOMMENDED that the RP include the optional "login_hint" parameter RECOMMENDED that the RP include the optional "login_hint" parameter
in the request, with the value being that of the "id" query parameter in the request, with the value being that of the "roidc1_id" query
of the End-User's RDAP "login" request, if provided. Passing the parameter of the End-User's RDAP "login" request, if provided.
"login_hint" parameter allows a client to pre-fill login form Passing the "login_hint" parameter allows a client to pre-fill login
information, so logging in can be more convenient for users. Other form information, so logging in can be more convenient for users.
parameters MAY be included. 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 13, line 27 skipping to change at page 13, line 27
1. "dntSupported": (MANDATORY) a boolean value that describes RDAP 1. "dntSupported": (MANDATORY) a boolean value that describes RDAP
server support for the "roidc1_dnt" query parameter (see server support for the "roidc1_dnt" query parameter (see
Section 4.3.2). Section 4.3.2).
2. "endUserIdentifierDiscoverySupported": (OPTIONAL) a boolean value 2. "endUserIdentifierDiscoverySupported": (OPTIONAL) a boolean value
that describes RDAP server support for discovery of End-User that describes RDAP server support for discovery of End-User
identifiers. The default value is "true". identifiers. The default value is "true".
3. "issuerIdentifierSupported": (OPTIONAL) a boolean value that 3. "issuerIdentifierSupported": (OPTIONAL) a boolean value that
describes RDAP server support for explicit client specification describes RDAP server support for explicit client specification
of an Issuer Identifier. The default value is "true". of an Issuer Identifier. The default value is "true".
4. "openidcProviders": (OPTIONAL) a list of objects with the 4. "implicitTokenRefreshSupported": (OPTIONAL) a boolean value that
describes RDAP server support for implicit token refresh. The
default value is "false".
5. "openidcProviders": (OPTIONAL) a list of objects with the
following members that describes the set of OPs that are following members that describes the set of OPs that are
supported by the RDAP server. This data is RECOMMENDED if the supported by the RDAP server. This data is RECOMMENDED if the
value of issuerIdentifierSupported is "true": value of issuerIdentifierSupported is "true":
a. "iss": (MANDATORY) a string value equal to Issuer Identifier a. "iss": (MANDATORY) a string value equal to Issuer Identifier
of the OP as per OpenID Connect Core specification [OIDCC] of the OP as per OpenID Connect Core specification [OIDCC]
b. "name": (MANDATORY) a string value representing the human- b. "name": (MANDATORY) a string value representing the human-
friendly name of the OP. friendly name of the OP.
c. "default": (OPTIONAL) a boolean value that describes RDAP c. "default": (OPTIONAL) a boolean value that describes RDAP
server support for an OPTIONAL default OP that will be used server support for an OPTIONAL default OP that will be used
when a client omits the "roidc1_id" and "roidc1_iss" query when a client omits the "roidc1_id" and "roidc1_iss" query
skipping to change at page 17, line 46 skipping to change at page 17, line 46
MUST include an End-User identifier that's delivered using one of two MUST include an End-User identifier that's delivered using one of two
methods: by adding a query component to an RDAP request URI using the 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 syntax described in Section 3.4 of RFC 3986 [RFC3986], or by
including an HTTP authorization header for the Basic authentication including an HTTP authorization header for the Basic authentication
scheme as described in RFC 7617 [RFC7617]. If the RDAP server scheme as described in RFC 7617 [RFC7617]. If the RDAP server
supports a default Authorization Server, the End-User identifier MAY supports a default Authorization Server, the End-User identifier MAY
be omitted. Clients can use either of these methods. Servers MUST be omitted. Clients can use either of these methods. Servers MUST
support both methods. support both methods.
The query used to request client authentication is represented as an The query used to request client authentication is represented as an
OPTIONAL "key=value" pair using a key value of "id" and a value OPTIONAL "key=value" pair using a key value of "roidc1_id" and a
component that contains the client identifier issued by an OP. value component that contains the client identifier issued by an OP.
An example using wget for client identifier "user.idp.example": An example using wget for client identifier "user.idp.example":
wget -qO- --keep-session-cookies --save-cookies\ wget -qO- --keep-session-cookies --save-cookies\
https://example.com/rdap/session/device?roidc1_id=user.idp.example https://example.com/rdap/roidc1_session/device?roidc1_id=user.idp.example
Figure 6 Figure 6
The authorization header for the Basic authentication scheme contains The authorization header for the Basic authentication scheme contains
a Base64-encoded representation of the client identifier issued by an a Base64-encoded representation of the client identifier issued by an
OP. No password is provided. OP. No password is provided.
An example using curl and an authorization header: An example using curl and an authorization header:
curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\ curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\
-c cookies.txt https://example.com/rdap/session/device -c cookies.txt https://example.com/rdap/roidc1_session/device
Figure 7 Figure 7
The response to this request MUST use the response structures The response to this request MUST use the response structures
specified in RFC 9083 [RFC9083]. In addition, the response MUST specified in RFC 9083 [RFC9083]. In addition, the response MUST
include an indication of the requested operation's success or failure include an indication of the requested operation's success or failure
in the "notices" data structure (including the client identifier), in the "notices" data structure (including the client identifier),
and, if successful, a "roidc1_deviceInfo" data structure. and, if successful, a "roidc1_deviceInfo" data structure.
An example of a "roidc1_session/device" response: An example of a "roidc1_session/device" response:
skipping to change at page 23, line 43 skipping to change at page 23, line 43
}, },
"sessionInfo": { "sessionInfo": {
"tokenExpiration": 3599, "tokenExpiration": 3599,
"tokenRefresh": true "tokenRefresh": true
} }
} }
} }
Figure 12 Figure 12
Alternatively, an RDAP server MAY implicitly attempt to refresh an
access token upon receipt of a query if the access token associated
with an existing session has expired and the corresponding OP
supports token refresh. The default RDAP server behavior is
described in the "implicitTokenRefreshSupported" value that's include
in the "roidc1_openidcConfiguration" data structure (see
Section 4.1.3). If the value of "implicitTokenRefreshSupported" is
"true", the client MAY either explicitly attempt to refresh the
session using the "roidc1_session/refresh" query, or it MAY depend on
the RDAP server to implicitly attempt to refresh the session as
necessary when an RDAP query is received by the server. If the value
of "implicitTokenRefreshSupported" is "false", the client MUST
explicitly attempt to refresh the session using the "roidc1_session/
refresh" query to extend an existing session. If a session cannot be
extended for any reason, the client MUST establish a new session to
continue authenticated query processing by submitting a
"roidc1_session/login" query. If the OP does not support token
refresh, the client MUST submit a new "roidc1_session/login" request
to establish a new session once an access token has expired.
4.6. Client Logout 4.6. Client Logout
Clients MAY send a request to an RDAP server to terminate an existing Clients MAY send a request to an RDAP server to terminate an existing
login session. Termination of a session is requested using a login session. Termination of a session is requested using a
"roidc1_session/logout" path segment. Access and refresh tokens can "roidc1_session/logout" path segment. Access and refresh tokens can
be revoked during the "roidc1_session/logout" process as described in be revoked during the "roidc1_session/logout" process as described in
RFC 7009 [RFC7009] if supported by the OP (token revocation endpoint RFC 7009 [RFC7009] if supported by the OP (token revocation endpoint
support is OPTIONAL per RFC 8414 [RFC8414]). If supported, this support is OPTIONAL per RFC 8414 [RFC8414]). If supported, this
feature SHOULD be used to ensure that the tokens are not mistakenly feature SHOULD be used to ensure that the tokens are not mistakenly
associated with a future RDAP session. Alternatively, an RDAP server associated with a future RDAP session. Alternatively, an RDAP server
skipping to change at page 36, line 20 skipping to change at page 36, line 52
12: Updated data structure descriptions. Updated Section 8. Minor 12: Updated data structure descriptions. Updated Section 8. Minor
formatting changes due to a move to xml2rfc-v3 markup. formatting changes due to a move to xml2rfc-v3 markup.
13: Added support for OP discovery via OP's Issuer Identifier. 13: Added support for OP discovery via OP's Issuer Identifier.
Modified the RDAP conformance text to use "roidc1", and added that Modified the RDAP conformance text to use "roidc1", and added that
value to extension path segments, data structures, and query value to extension path segments, data structures, and query
parameters. Changed the "purpose" and "dnt" claims to parameters. Changed the "purpose" and "dnt" claims to
"rdap_allowed_purposes" (making it an array) and "rdap_allowed_purposes" (making it an array) and
"rdap_dnt_allowed". Added the "roidc1_qp" and "roidc1_dnt" query "rdap_dnt_allowed". Added the "roidc1_qp" and "roidc1_dnt" query
parameters. Changed the descriptions of "local" OPs to "default" parameters. Changed the descriptions of "local" OPs to "default"
OPs. OPs.
14: Fixed a few instances of "id" that were changed to "roidc1_id"
and "session" that were changed to "roidc1_session". Added
"implicitTokenRefreshSupported".
Author's Address Author's Address
Scott Hollenbeck Scott Hollenbeck
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: shollenbeck@verisign.com Email: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
 End of changes. 15 change blocks. 
25 lines changed or deleted 51 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/