draft-ietf-regext-rdap-openid-14.txt   draft-ietf-regext-rdap-openid-15.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track 24 May 2022 Intended status: Standards Track 16 June 2022
Expires: 25 November 2022 Expires: 18 December 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-14 draft-ietf-regext-rdap-openid-15
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 25 November 2022. This Internet-Draft will expire on 18 December 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 7, line 20 skipping to change at page 7, line 20
Discovery" protocol [OIDCD], but that protocol is not widely Discovery" protocol [OIDCD], but that protocol is not widely
implemented. Out-of-band methods are also possible and can be more implemented. Out-of-band methods are also possible and can be more
dependable. For example, an RP can support a limited number of OPs dependable. For example, an RP can support a limited number of OPs
and maintain internal associations of those identifiers with the OPs and maintain internal associations of those identifiers with the OPs
that issued them. that issued them.
Alternatively, if mapping of an End-User's identifier is not Alternatively, if mapping of an End-User's identifier is not
possible, or not supported by the RDAP server, the RDAP server SHOULD possible, or not supported by the RDAP server, the RDAP server SHOULD
support explicit specification of a remote OP by the RDAP client in support explicit specification of a remote OP by the RDAP client in
the form of a query parameter as described in Section 4.2.2. An RDAP the form of a query parameter as described in Section 4.2.2. An RDAP
server SHOULD provide information about its capabilities and server MUST provide information about its capabilities and supported
supported OPs in the "help" query response in the OPs in the "help" query response in the "roidc1_openidcConfiguration"
"openidcConfiguration" data structure described in Section 4.1.3. data structure described in Section 4.1.3.
An RP can also ask an End-User to identify the OP that issued their An RP can also ask an End-User to identify the OP that issued their
identifier as part of an RDAP query workflow. In this case, the RP identifier as part of an RDAP query workflow. In this case, the RP
will need to maintain state for the association between the user's will need to maintain state for the association between the user's
identifier and the OP in order to process later queries that rely on identifier and the OP in order to process later queries that rely on
passing the access token and user identifier as authorization passing the access token and user identifier as authorization
parameters. An RDAP server MUST support at least one of these parameters. An RDAP server MUST support at least one of these
methods of OP discovery. methods of OP discovery.
3.1.3.2. Authentication Request 3.1.3.2. Authentication Request
skipping to change at page 37, line 6 skipping to change at page 37, line 6
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" 14: Fixed a few instances of "id" that were changed to "roidc1_id"
and "session" that were changed to "roidc1_session". Added and "session" that were changed to "roidc1_session". Added
"implicitTokenRefreshSupported". "implicitTokenRefreshSupported".
15: Fixed an instance of openidcConfiguration that was missing the
"roidc1" prefix. Changed SHOULD to MUST to describe the need to
return the roidc1_openidcConfiguration data structure in a "help"
response.
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. 5 change blocks. 
7 lines changed or deleted 11 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/