draft-ietf-regext-rdap-openid-12.txt		draft-ietf-regext-rdap-openid-13.txt
	REGEXT Working Group S. Hollenbeck		REGEXT Working Group S. Hollenbeck
	Internet-Draft Verisign Labs		Internet-Draft Verisign Labs
	Intended status: Standards Track 23 March 2022		Intended status: Standards Track 18 May 2022
	Expires: 24 September 2022		Expires: 19 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-12		draft-ietf-regext-rdap-openid-13
	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 24 September 2022.		This Internet-Draft will expire on 19 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 32 ¶		skipping to change at page 2, line 32 ¶
	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 . . . . . . . . . . . . . . . 7		3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 7
	3.1.3.2. Authentication Request . . . . . . . . . . . . . 7		3.1.3.2. Authentication Request . . . . . . . . . . . . . 7
	3.1.3.3. End-User Authorization . . . . . . . . . . . . . 8		3.1.3.3. End-User Authorization . . . . . . . . . . . . . 8
	3.1.3.4. Authorization Response and Validation . . . . . . 8		3.1.3.4. Authorization Response and Validation . . . . . . 8
	3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 8		3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . 9		3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 9
	3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 9		3.1.4.1. Stated Purposes . . . . . . . . . . . . . . . . . 9
	3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10		3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10
	4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10		4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 11		4.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 11
	4.1.1. Session . . . . . . . . . . . . . . . . . . . . . . . 11		4.1.1. Session . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.2. Device Info . . . . . . . . . . . . . . . . . . . . . 12		4.1.2. Device Info . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 13		4.1.3. OpenID Connect Configuration . . . . . . . . . . . . 13
	4.2.1. Clients with Limited User Interfaces . . . . . . . . 15		4.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 14
	4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15		4.2.1. End-User Identifier . . . . . . . . . . . . . . . . . 14
	4.2.1.2. UI-constrained Client Login Polling . . . . . . . 17		4.2.2. OP Issuer Identifier . . . . . . . . . . . . . . . . 15
	4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17		4.2.3. Login Response . . . . . . . . . . . . . . . . . . . 15
	4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18		4.2.4. Clients with Limited User Interfaces . . . . . . . . 17
	4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20		4.2.4.1. UI-constrained Client Login . . . . . . . . . . . 17
	4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21		4.2.4.2. UI-constrained Client Login Polling . . . . . . . 19
	5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21		4.3. RDAP Query Parameters . . . . . . . . . . . . . . . . . . 19
	6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21		4.3.1. RDAP Query Purpose . . . . . . . . . . . . . . . . . 20
	7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22		4.3.2. RDAP Do Not Track . . . . . . . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		4.4. Session Status . . . . . . . . . . . . . . . . . . . . . 20
	8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22		4.5. Session Refresh . . . . . . . . . . . . . . . . . . . . . 22
	8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23		4.6. Client Logout . . . . . . . . . . . . . . . . . . . . . . 23
	8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23		4.7. Parameter Processing . . . . . . . . . . . . . . . . . . 25
	9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26		5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 25
	9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 27		6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 25
	9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 27		7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 26
	9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 28		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 26
	10.1. Authentication and Access Control . . . . . . . . . . . 29		8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 26
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29		9. Implementation Status . . . . . . . . . . . . . . . . . . . . 30
	12.1. Normative References . . . . . . . . . . . . . . . . . . 29		9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 31
	12.2. Informative References . . . . . . . . . . . . . . . . . 31		9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 31
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32		9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 32
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32		10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
			10.1. Authentication and Access Control . . . . . . . . . . . 32
			11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
			12.1. Normative References . . . . . . . . . . . . . . . . . . 33
			12.2. Informative References . . . . . . . . . . . . . . . . . 35
			Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
	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 6, line 6 ¶		skipping to change at page 6, line 6 ¶
	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-like client using		At a high level, RDAP authentication of a browser-like client using
	OpenID Connect requires completion of the following steps:		OpenID Connect requires completion of the following steps:
	1. An RDAP client sends an RDAP "help" query to an RDAP server to		1. An RDAP client sends an RDAP "help" query to an RDAP server to
	determine the type of OpenID Authorization Server that's used by		determine the type and capabilities of the OpenID Authorization
	the RDAP server. This information is returned in the		Servers that are used by the RDAP server. This information is
	rdapConformance section of the response. A value of		returned in the rdapConformance section of the response. A
	"rdap_openidc_local_level_0" indicates that the server uses a		value of "roidc1" indicates support for the extension described
	local Authorization Server. A value of		in this specification. If one or more remote Authorization
	"rdap_openidc_remote_level_0" indicates that the server uses a		Servers are supported, the RDAP client SHOULD evaluate the
	remote Authorization Server.		additional information described in Section 4.1.3 in order to
			discover the capabilties of the RDAP server and optionally
			obtain the set of supported OPs.
	2. An RDAP client (acting as an OpenID End-User) sends an RDAP		2. An RDAP client (acting as an OpenID End-User) sends an RDAP
	"login" request to an RDAP server as described in Section 4.2.		"login" request to an RDAP server as described in Section 4.2.
	3. The RDAP server (acting as an OpenID Relying Party (RP))		3. The RDAP server (acting as an OpenID Relying Party (RP))
	prepares an Authentication Request containing the desired		prepares an Authentication Request containing the desired
	request parameters.		request parameters.
	4. The RDAP server sends the RDAP client and Authentication Request		4. The RDAP server sends the RDAP client and Authentication Request
	to an Authorization Server operated by an OpenID Provider (OP)		to an Authorization Server operated by an OpenID Provider (OP)
	using an HTTP redirect.		using an HTTP redirect.
	5. The Authorization Server authenticates the End-User.		5. The Authorization Server authenticates the End-User.
	6. The Authorization Server obtains End-User consent/authorization.		6. The Authorization Server obtains End-User consent/authorization.
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 42 ¶
	associated with the End-User's identity.		associated with the End-User's identity.
	The RDAP server can then make identification, authorization, and		The RDAP server can then make identification, authorization, and
	access control decisions based on End-User identity information and		access control decisions based on End-User identity information and
	local policies. Note that OpenID Connect describes different process		local policies. Note that OpenID Connect describes different process
	flows for other types of clients, such as script-based or command		flows for other types of clients, such as script-based or command
	line clients.		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 MAY present an identifier (an OpenID) issued by an OP to
	use OpenID Connect with RDAP. An OP SHOULD include support for the		use OpenID Connect with RDAP. If the RDAP server supports a default
	claims described in Section 3.1.4 to provide additional information		Authorization Server or End-User identifier discovery is not
	needed for RDAP End-User authorization. OpenID Connect requires RPs		supported, the End-User identifier MAY be omitted. An OP SHOULD
	to register with OPs to use OpenID Connect services for an End-User.		include support for the claims described in Section 3.1.4 to provide
	The registration process is often completed using out-of-band		additional information needed for RDAP End-User authorization.
	methods, but it is also possible to use the automated method		OpenID Connect requires RPs to register with OPs to use OpenID
	described by the "OpenID Connect Dynamic Client Registration"		Connect services for an End-User. The registration process is often
	protocol [OIDCR]. The parties involved can use any method that is		completed using out-of-band methods, but it is also possible to use
	mutually acceptable.		the automated method described by the "OpenID Connect Dynamic Client
			Registration" protocol [OIDCR]. The parties involved can use any
			method that is mutually acceptable.
	3.1.3.1. Provider Discovery		3.1.3.1. Provider Discovery
	An RDAP server/RP needs to be able to map an End-User's identifier to		An RDAP server/RP needs to be able to map an End-User's identifier to
	an OP. This can be accomplished using the OPTIONAL "OpenID Connect		an OP. This can be accomplished using the OPTIONAL "OpenID Connect
	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. An RP can also ask an End-User to identify the OP		that issued them.
	that issued their identifier as part of an RDAP query workflow. In
	this case, the RP will need to maintain state for the association		Alternatively, if mapping of an End-User's identifier is not
	between the user's identifier and the OP in order to process later		possible, or not supported by the RDAP server, the RDAP server SHOULD
	queries that rely on passing the access token and user identifier as		support explicit specification of a remote OP by the RDAP client in
	authorization parameters. An RP MAY use any provider discovery		the form of a query parameter as described in Section 4.2.2. An RDAP
	approach that is suitable for its operating environment.		server SHOULD provide information about its capabilities and
			supported OPs in the "help" query response in the
			"openidcConfiguration" data structure described in Section 4.1.3.
			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
			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
			passing the access token and user identifier as authorization
			parameters. An RDAP server MUST support at least one of these
			methods of OP discovery.
	3.1.3.2. Authentication Request		3.1.3.2. Authentication Request
	Once the OP is known, an RP MUST form an Authentication Request and		Once the OP is known, an RP MUST form an Authentication Request and
	send it to the OP as described in Section 3 of the OpenID Connect		send it to the OP as described in Section 3 of the OpenID Connect
	Core protocol [OIDCC]. The authentication path followed		Core protocol [OIDCC]. The authentication path followed
	(authorization, implicit, or hybrid) will depend on the		(authorization, implicit, or hybrid) will depend on the
	Authentication Request response_type set by the RP. The remainder of		Authentication Request response_type set by the RP. The remainder of
	the processing steps described here assume that the Authorization		the processing steps described here assume that the Authorization
	Code Flow is being used by setting "response_type=code" in the		Code Flow is being used by setting "response_type=code" in the
	skipping to change at page 7, line 47 ¶		skipping to change at page 8, line 10 ¶
	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 "id" query parameter
	of the End-User's RDAP "login" request. Passing the "login_hint"		of the End-User's RDAP "login" request, if provided. Passing the
	parameter allows a client to pre-fill login form information, so		"login_hint" parameter allows a client to pre-fill login form
	logging in can be more convenient for users. Other parameters MAY be		information, so logging in can be more convenient for users. Other
	included.		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 15 ¶		skipping to change at page 9, line 18 ¶
	3.1.4. Specialized Claims for RDAP		3.1.4. Specialized Claims for RDAP
	OpenID Connect claims are pieces of information used to make		OpenID Connect claims are pieces of information used to make
	assertions about an entity. Section 5 of the OpenID Connect Core		assertions about an entity. Section 5 of the OpenID Connect Core
	protocol [OIDCC] describes a set of standard claims that can be used		protocol [OIDCC] describes a set of standard claims that can be used
	to identify a person. Section 5.1.2 notes that additional claims MAY		to identify a person. Section 5.1.2 notes that additional claims MAY
	be used, and it describes a method to create them. The set of claims		be used, and it describes a method to create them. The set of claims
	that are specific to RDAP are associated with an OAuth scope request		that are specific to RDAP are associated with an OAuth scope request
	parameter value (see Section 3.3 of RFC 6749 ([RFC6749])) of "rdap".		parameter value (see Section 3.3 of RFC 6749 ([RFC6749])) of "rdap".
	3.1.4.1. Stated Purpose		3.1.4.1. Stated Purposes
	There are communities of RDAP users and operators who wish to make		There are communities of RDAP users and operators who wish to make
	and validate claims about a user's "need to know" when it comes to		and validate claims about a user's "need to know" when it comes to
	requesting access to a resource. For example, a law enforcement		requesting access to a resource. For example, a law enforcement
	agent or a trademark attorney may wish to be able to assert that they		agent or a trademark attorney may wish to be able to assert that they
	have a legal right to access a protected resource, and a server		have a legal right to access a protected resource, and a server
	operator will need to be able to receive and validate that claim.		operator will need to be able to receive and validate that claim.
	These needs can be met by defining and using an additional "purpose"		These needs can be met by defining and using an additional
	claim.		"rdap_allowed_purposes" claim.
	The "purpose" claim identifies the purpose for which access to a		The "rdap_allowed_purposes" claim identifies the purposes for which
	protected resource is being requested. Use of the "purpose" claim is		access to a protected resource can be requested by an End-User. Use
	OPTIONAL; processing of this claim is subject to server acceptance of		of the "rdap_allowed_purposes" claim is OPTIONAL; processing of this
	the purpose and successful authentication of the End-User.		claim is subject to server acceptance of the purposes, the trust
	Unrecognized purpose values MUST be ignored and the associated query		level assigned to this claim by the server, and successful
	MUST be processed as if the unrecognized purpose value was not		authentication of the End-User. Unrecognized purpose values MUST be
	present at all.		ignored and the associated query MUST be processed as if the
			unrecognized purpose value was not present at all.
	The "purpose" value is a case-sensitive string containing a		The "rdap_allowed_purposes" claim is represented as an array of case-
	StringOrURI value as specified in Section 2 of the JSON Web Token		sensitive StringOrURI values as specified in Section 2 of the JSON
	(JWT) specification ([RFC7519]). An example:		Web Token (JWT) specification ([RFC7519]). An example:
	{"purpose" : "domainNameControl"}		"rdap_allowed_purposes": ["domainNameControl","dnsTransparency"]
	Purpose values are themselves registered with IANA. Each entry in		Individual purpose values are registered with IANA. Each entry in
	the registry contains the following fields:		the registry contains the following fields:
	Value: the purpose string value being registered. Value strings can		Value: the purpose string value being registered. Value strings can
	contain upper case characters from "A" to "Z", lower case ASCII		contain upper case characters from "A" to "Z", lower case ASCII
	characters from "a" to "z", and the underscore ("_") character.		characters from "a" to "z", and the underscore ("_") character.
	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
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 28 ¶
	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" ("rdap_dnt_allowed") claim can be used to identify
	that is authorized to perform queries without the End-User's		an End-User that is authorized to perform queries without the End-
	association with those queries being logged, tracked, or recorded by		User's association with those queries being logged, tracked, or
	the server. Client use of the "dnt" claim is OPTIONAL. Server		recorded by the server. Client use of the "rdap_dnt_allowed" claim
	operators MUST NOT log, track, or record any association of the query		is OPTIONAL. Server operators MUST NOT log, track, or record any
	and the End-User's identity if the End-User is successfully		association of the query and the End-User's identity if the End-User
	identified and authorized, the "dnt" claim is present, the value of		is successfully identified and authorized, the "rdap_dnt_allowed"
	the claim is "true", and accepting the claim complies with local		claim is present, the value of the claim is "true", and accepting the
	regulations regarding logging and tracking.		claim complies with local regulations regarding logging and tracking.
	The "dnt" value is represented as a JSON boolean literal. An		The "rdap_dnt_allowed" value is represented as a JSON boolean
	example:		literal. An example:
	{"dnt" : true}		rdap_dnt_allowed: 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"
	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. Data structures to return information that describes an		1. Data structures to return information that describes an
	established session and the information needed to establish a		established session, the information needed to establish a
	session for a UI-constrained device.		session for a UI-constrained device, and the RDAP server's OpenID
			Connect extension configuration.
	2. A query parameter to request authentication for a specific End-		2. A query parameter to request authentication for a specific End-
	User identity.		User identity.
	3. Path segments to start, stop, refresh, and determine the status		3. A query parameter to identify the purpose of the query.
			4. A query parameter to request that the server not log or otherwise
			record information about the identity associated with a query.
			5. Path segments to start, stop, refresh, and determine the status
	of an authenticated session for a specific End-User identity.		of an authenticated session for a specific End-User identity.
	4.1. Data Structures		4.1. Data Structures
	This specification describes two new data structures that are used to		This specification describes three new data structures that are used
	return information to a client: a "session" data structure that		to return information to a client: a "roidc1_session" data structure
	contains information that describes an established session, and a		that contains information that describes an established session, a
	"deviceInfo" data structure that contains information that describes		"roidc1_deviceInfo" data structure that contains information that
	an active attempt to establish a session on a UI-constrained device.		describes an active attempt to establish a session on a UI-
			constrained device, and a "roidc1_openidcConfiguration" data
			structure that describes the OpenID Connect configuration and related
			extension features supported by the RDAP server.
	4.1.1. Session		4.1.1. Session
	The "session" data structure is an object that contains two sub-		The "roidc1_session" data structure is an object that contains two
	objects:		sub-objects:
	1. A "userClaims" object that contains the set of claims associated		1. A "userClaims" object that contains the set of claims associated
	with the End-User's identity as used/requested by the RDAP server		with the End-User's identity as used/requested by the RDAP server
	to make access control decisions. The set of possible values is		to make access control decisions. The set of possible values is
	determined by OP policy.		determined by OP policy.
	2. A "sessionInfo" object that contains two members:		2. A "sessionInfo" object that contains two members:
	a. "tokenExpiration": an integer value that represents the		a. "tokenExpiration": an integer value that represents the
	number of seconds from the current time for which the Access		number of seconds from the current time for which the Access
	Token remains valid, and		Token remains valid, and
	b. "tokenRefresh": A boolean value that indicates if the OP		b. "tokenRefresh": A boolean value that indicates if the OP
	supports refresh tokens. As described in RFC 6749 [RFC6749],		supports refresh tokens. As described in RFC 6749 [RFC6749],
	support for refresh tokens is OPTIONAL.		support for refresh tokens is OPTIONAL.
	An example of a "session" data structure:		An example of a "roidc1_session" data structure:
	"session": {		"roidc1_session": {
	"userClaims": {		"userClaims": {
	"sub": "103892603076825016132",		"sub": "103892603076825016132",
	"name": "User Person",		"name": "User Person",
	"given_name": "User",		"given_name": "User",
	"family_name": "Person",		"family_name": "Person",
	"picture": "https://lh3.example.com/a-/AOh14=s96-c",		"picture": "https://lh3.example.com/a-/AOh14=s96-c",
	"email": "user@example.com",		"email": "user@example.com",
	"email_verified": true,		"email_verified": true,
	"locale": "en",		"locale": "en",
	"purpose": "domainNameControl",		"rdap_allowed_purposes": [
	"dnt": false		"domainNameControl",
			"personalDataProtection"
			],
			"rdap_dnt_allowed": false
	},		},
	"sessionInfo": {		"sessionInfo": {
	"tokenExpiration": 3599,		"tokenExpiration": 3599,
	"tokenRefresh": true		"tokenRefresh": true
	}		}
	}		}
	Figure 1		Figure 1
	4.1.2. Device Info		4.1.2. Device Info
	The flow described in Section 3.1.3 requires an End-User to interact		The flow described in Section 3.1.3 requires an End-User to interact
	with a server using a user interface that can process HTTP. This		with a server using a user interface that can process HTTP. This
	will not work well in situations where the client is automated or an		will not work well in situations where the client is automated or an
	End-User is using a command line user interface such as curl		End-User is using a command line user interface such as curl
	(http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/).		(http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/).
	This limitation can be addressed using a web browser on a second		This limitation can be addressed using a web browser on a second
	device. The information that needs to be entered using the web		device. The information that needs to be entered using the web
	browser is contained in the "deviceInfo" data structure.		browser is contained in the "roidc1_deviceInfo" data structure.
	The "deviceInfo" data structure is an object that contains three		The "roidc1_deviceInfo" data structure is an object that contains
	members:		three members:
	1. "verification_url": the URL that the End-User needs to visit		1. "verification_url": the URL that the End-User needs to visit
	using the web browser,		using the web browser,
	2. "user_code": the string value that the End-User needs to enter on		2. "user_code": the string value that the End-User needs to enter on
	the form presented in the web browser, and		the form presented in the web browser, and
	3. "expires_in": an integer value that represents the number of		3. "expires_in": an integer value that represents the number of
	seconds after which the opportunity to visit the URL and enter		seconds after which the opportunity to visit the URL and enter
	the user_code will expire.		the user_code will expire.
	An example of a "deviceInfo" data structure:		An example of a "roidc1_deviceInfo" data structure:
	"deviceInfo": {		"roidc1_deviceInfo": {
	"verification_url": "https://www.example.com/device",		"verification_url": "https://www.example.com/device",
	"user_code": "NJJQ-GJFC",		"user_code": "NJJQ-GJFC",
	"expires_in": "1800"		"expires_in": "1800"
	}		}
	Figure 2		Figure 2
			4.1.3. OpenID Connect Configuration
			The "roidc1_openidcConfiguration" data structure is an object with
			the following members:
			1. "dntSupported": (MANDATORY) a boolean value that describes RDAP
			server support for the "roidc1_dnt" query parameter (see
			Section 4.3.2).
			2. "endUserIdentifierDiscoverySupported": (OPTIONAL) a boolean value
			that describes RDAP server support for discovery of End-User
			identifiers. The default value is "true".
			3. "issuerIdentifierSupported": (OPTIONAL) a boolean value that
			describes RDAP server support for explicit client specification
			of an Issuer Identifier. The default value is "true".
			4. "openidcProviders": (OPTIONAL) a list of objects with the
			following members that describes the set of OPs that are
			supported by the RDAP server. This data is RECOMMENDED if the
			value of issuerIdentifierSupported is "true":
			a. "iss": (MANDATORY) a string value equal to Issuer Identifier
			of the OP as per OpenID Connect Core specification [OIDCC]
			b. "name": (MANDATORY) a string value representing the human-
			friendly name of the OP.
			c. "default": (OPTIONAL) a boolean value that describes RDAP
			server support for an OPTIONAL default OP that will be used
			when a client omits the "roidc1_id" and "roidc1_iss" query
			parameters from a "roidc1_session/login" request. Only one
			member of this set can be identified as the default OP by
			setting a value of "true". The default value is "false".
			An example of a "roidc1_openidcConfiguration" data structure:
			"roidc1_openidcConfiguration": {
			"dntSupported": false,
			"endUserIdentifierDiscoverySupported": true,
			"issuerIdentifierSupported": true,
			"openidcProviders":
			[
			{
			"iss": "https://idp.example.com",
			"name": "Example IDP"
			},
			{
			"iss": "https://accounts.example.net",
			"name": "Login with EXAMPLE"
			},
			{
			"iss": "https://auth.nic.example/auth/realms/rdap",
			"name": "Default OP for the Example RDAP server",
			"default": "true"
			}
			]
			}
			Figure 3
	4.2. Client Login		4.2. Client Login
	Client authentication is requested by sending a "session/login"		Client authentication is requested by sending a "roidc1_session/
	request to an RDAP server. If the RDAP server supports only remote		login" request to an RDAP server. If the RDAP server supports only
	Authorization Servers, the "session/login" request MUST include an		remote Authorization Servers, the "roidc1_session/login" request MUST
	End-User identifier that's delivered using one of two methods: by		include at least one of an End-User Identifier or an OP Issuer
			Identifier.
			4.2.1. End-User Identifier
			The End-User identifier is delivered using one of two methods: by
	adding a query component to an RDAP request URI using the syntax		adding a query component to an RDAP request URI using the syntax
	described in Section 3.4 of RFC 3986 [RFC3986], or by including an		described in Section 3.4 of RFC 3986 [RFC3986], or by including an
	HTTP authorization header for the Basic authentication scheme as		HTTP authorization header for the Basic authentication scheme as
	described in RFC 7617 [RFC7617]. Clients can use either of these		described in RFC 7617 [RFC7617]. Clients can use either of these
	methods to deliver the End-User identifier to a server that supports		methods to deliver the End-User identifier to a server that supports
	remote Authorization Servers. Servers that support remote		remote Authorization Servers and End-User identifier discovery.
	Authorization Servers MUST accept both methods. If the RDAP server		Servers that support remote Authorization Servers and End-User
	supports a local Authorization Server, the End-User identifier MAY be		identifier discovery MUST accept both methods. If the RDAP server
	omitted.		supports a default Authorization Server or End-User identifier
			discovery is not supported, the End-User identifier MAY be omitted.
	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. An		value component that contains the client identifier issued by an OP.
	example for client identifier "user.idp.example":		An example for client identifier "user.idp.example":
	https://example.com/rdap/session/login?id=user.idp.example		https://example.com/rdap/roidc1_session/
			login?roidc1_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/session/login		https://example.com/rdap/roidc1_session/login
	Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==		Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==
	An example for use with a local Authorization Server:		An example for use with a default Authorization Server:
	https://example.com/rdap/session/login		https://example.com/rdap/roidc1_session/login
	The response to this request MUST use the response structures
			4.2.2. OP Issuer Identifier
			The OP's Issuer Identifier is delivered by adding a query component
			to an RDAP request URI using the syntax described in Section 3.4 of
			RFC 3986 [RFC3986]. If the RDAP server supports a default
			Authorization Server, the Issuer Identifier MAY be omitted.
			The query used to request client authentication is represented as an
			OPTIONAL "key=value" pair using a key value of "roidc1_iss" and a
			value component that contains the Issuer Identifier associated with
			an OP. An RDAP server MAY accept Issuer Identifiers not specified in
			the "roidc1_openidcConfiguration" data structure and MAY also decide
			to accept specific Issuer Identifiers only from specific clients.
			An example for Issuer Identifier "https://idp.example.com":
			https://example.com/rdap/roidc1_session/
			login?roidc1_iss=https%3A%2F%2Fidp.example.com
			4.2.3. Login Response
			The response to the login 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 "session" data structure.		and, if successful, a "roidc1_session" data structure.
	An example of a successful "session/login" response:		An example of a successful "roidc1_session/login" response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_openidc_remote_level_0"		"roidc1"
	],
	"lang": "en-US",
	"notices": {
	"title": "Login Result",
	"description": [
	"Login succeeded",
	"user.idp.example"
	],		],
	},		"lang": "en-US",
	"session": {		"notices": {
	"userClaims": {		"title": "Login Result",
	"sub": "103892603076825016132",		"description": [
	"name": "User Person",		"Login succeeded",
	"given_name": "User",		"user.idp.example"
	"family_name": "Person",		],
	"picture": "https://lh3.example.com/a-/AOh14=s96-c",
	"email": "user@example.com",
	"email_verified": true,
	"locale": "en",
	"purpose": "domainNameControl",
	"dnt": false
	},		},
	"sessionInfo": {		"roidc1_session": {
	"tokenExpiration": 3599,		"userClaims": {
	"tokenRefresh": true		"sub": "103892603076825016132",
			"name": "User Person",
			"given_name": "User",
			"family_name": "Person",
			"picture": "https://lh3.example.com/a-/AOh14=s96-c",
			"email": "user@example.com",
			"email_verified": true,
			"locale": "en",
			"rdap_allowed_purposes": [
			"domainNameControl",
			"personalDataProtection"
			],
			"rdap_dnt_allowed": false
			},
			"sessionInfo": {
			"tokenExpiration": 3599,
			"tokenRefresh": true
			}
	}		}
	}		}
	}
	Figure 3		Figure 4
	An example of a failed "session/login" response:		An example of a failed "roidc1_session/login" response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_openidc_remote_level_0"		"roidc1"
	],		],
	"lang": "en-US",		"lang": "en-US",
	"notices": {		"notices": {
	"title": "Login Result",		"title": "Login Result",
	"description": [		"description": [
	"Login failed",		"Login failed",
	"user.idp.example"		"user.idp.example"
	]		]
			}
	}		}
	}
	Figure 4		Figure 5
	4.2.1. Clients with Limited User Interfaces		4.2.4. Clients with Limited User Interfaces
	The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an		The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an
	OPTIONAL method to request user authorization from devices that have		OPTIONAL method to request user authorization from devices that have
	an Internet connection, but lack a suitable browser for a more		an Internet connection, but lack a suitable browser for a more
	traditional OAuth flow. This method requires an End-User to use a		traditional OAuth flow. This method requires an End-User 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 UI-		browser for entry of a code sequence that is presented on the UI-
	constrained device.		constrained device.
	4.2.1.1. UI-constrained Client Login		4.2.4.1. UI-constrained Client Login
	Client authentication is requested by sending a "session/device"		Client authentication is requested by sending a "roidc1_session/
	request to an RDAP server. If the RDAP server supports only remote		device" request to an RDAP server. If the RDAP server supports only
	Authorization Servers, the "session/device" request MUST include an		remote Authorization Servers, the "roidc1_session/device" request
	End-User identifier that's delivered using one of two methods: by		MUST include an End-User identifier that's delivered using one of two
	adding a query component to an RDAP request URI using the syntax		methods: by adding a query component to an RDAP request URI using the
	described in Section 3.4 of RFC 3986 [RFC3986], or by including an		syntax described in Section 3.4 of RFC 3986 [RFC3986], or by
	HTTP authorization header for the Basic authentication scheme as		including an HTTP authorization header for the Basic authentication
	described in RFC 7617 [RFC7617]. If the RDAP server supports a local		scheme as described in RFC 7617 [RFC7617]. If the RDAP server
	Authorization Server, the End-User identifier MAY be omitted.		supports a default Authorization Server, the End-User identifier MAY
	Clients can use either of these methods. Servers MUST support both		be omitted. Clients can use either of these methods. Servers MUST
	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 "id" and a value
	component that contains the client identifier issued by an OP.		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?id=user.idp.example		https://example.com/rdap/session/device?roidc1_id=user.idp.example
	Figure 5		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/session/device
	Figure 6		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 "deviceInfo" data structure.		and, if successful, a "roidc1_deviceInfo" data structure.
	An example of a "session/device" response:		An example of a "roidc1_session/device" response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_openidc_remote_level_0"		"roidc1"
	],		],
	"lang": "en-US",		"lang": "en-US",
	"notices": {		"notices": {
	"title": "Device Login Result",		"title": "Device Login Result",
	"description": [		"description": [
	"Login succeeded",		"Login succeeded",
	"user.idp.example"		"user.idp.example"
	]		]
	},		},
	"deviceInfo": {		"roidc1_deviceInfo": {
	"verification_url": "https://www.example.com/device",		"verification_url": "https://www.example.com/device",
	"user_code": "NJJQ-GJFC",		"user_code": "NJJQ-GJFC",
	"expires_in": 1800		"expires_in": 1800
	}		}
	}		}
	Figure 7		Figure 8
	4.2.1.2. UI-constrained Client Login Polling		4.2.4.2. UI-constrained Client Login Polling
	After successful processing of the "session/device" request, the		After successful processing of the "roidc1_session/device" request,
	client MUST send a "session/devicepoll" request to the RDAP server to		the client MUST send a "roidc1_session/devicepoll" request to the
	continue the login process. This request performs the polling		RDAP server to continue the login process. This request performs the
	function described in RFC 8628 [RFC8628], allowing the RDAP server to		polling function described in RFC 8628 [RFC8628], allowing the RDAP
	wait for the End-User to enter the information returned from the		server to wait for the End-User to enter the information returned
	"session/device" request using the interface on their second device.		from the "roidc1_session/device" request using the interface on their
	After the End-User has completed that process, or if the process		second device. After the End-User has completed that process, or if
	fails or times out, the OP will respond to the polling requests with		the process fails or times out, the OP will respond to the polling
	an indication of success or failure.		requests with an indication of success or failure.
	An example using wget:		An example using wget:
	wget -qO- --load-cookies cookies.txt\		wget -qO- --load-cookies cookies.txt\
	https://example.com/rdap/session/devicepoll		https://example.com/rdap/roidc1_session/devicepoll
	Figure 8		Figure 9
	An example using curl:		An example using curl:
	curl -b cookies.txt https://example.com/rdap/session/devicepoll		curl -b cookies.txt https://example.com/rdap/roidc1_session/devicepoll
	Figure 9		Figure 10
	The response to this request MUST use the response structures		The response to this request MUST use the response structures
	described in Section 4.2. RDAP query processing can continue		described in Section 4.2. RDAP query processing can continue
	normally on the UI-constrained device once the "login" process has		normally on the UI-constrained device once the "login" process has
	been completed.		been completed.
	4.3. Session Status		4.3. RDAP Query Parameters
	Clients MAY send a query to an RDAP server to determine the status of		This specification describes two OPTIONAL query parameters for use
	an existing login session using a "session/status" path segment. An		with RDAP queries that request access to information associated with
	example "session/status" request:		protected resources:
	https://example.com/rdap/session/status		1. "roidc1_qp": A query parameter to identify the purpose of the
			query.
			2. "roidc1_dnt": A query parameter to request that the server not
			log or otherwise record information about the identity associated
			with a query.
			One or both of these parameters MAY be added to an RDAP request URI
			using the syntax described in Section 3.4 of RFC 3986 [RFC3986].
			4.3.1. RDAP Query Purpose
			This query is represented as a "key=value" pair using a key value of
			"roidc1_qp" and a value component that contains a single query
			purpose string from the set of allowed purposes associated with the
			End-User's identity (see Section 3.1.4.1). If present, the server
			SHOULD compare the value of the parameter to the
			"rdap_allowed_purposes" claim values associated with the End-User's
			identity and ensure that the requested purpose is present in the set
			of allowed purposes. The RDAP server MAY choose to ignore both
			requested purpose and the "rdap_allowed_purposes" claim values if
			they are inconsistent with local server policy. The server MUST
			return an HTTP 403 (Forbidden) response if the requested purpose is
			not an allowed purpose. If this parameter is not present, the server
			MUST proces the query and make an acces control decision based on any
			other information known to the server about the End-User and the
			information they are requesting. For example, a server MAY treat the
			request as one performed by an unidentified or unauthenticated user
			and return either an error or an appropriate subset of the available
			data. An example domain query using the "roidc1_qp" query parameter:
			https://example.com/rdap/domain/example.com?roidc1_qp=legalActions
			4.3.2. RDAP Do Not Track
			This query is represented as a "key=value" pair using a key value of
			"roidc1_dnt" and a value component that contains a single boolean
			value. A value of "true" indicates that the End-User is requesting
			that their query not be tracked or logged in accordance with server
			policy. A value of "false" indicates that the End-User is accepting
			that their query can be tracked or logged in accordance with server
			policy. The server MUST return an HTTP 501 (Not Implemented)
			response if the server is unable to perform the action requested by
			this query parameter. An example domain query using the "roidc1_dnt"
			query parameter:
			https://example.com/rdap/domain/example.com?roidc1_dnt=true
			4.4. Session Status
			Clients MAY send a query to an RDAP server to determine the status of
			an existing login session using a "roidc1_session/status" path
			segment. An example "roidc1_session/status" request:
			https://example.com/rdap/roidc1_session/status
	The response to this query MUST use the response structures specified		The response to this query MUST use the response structures specified
	in RFC 9083 [RFC9083]. In addition, the response MUST include an		in RFC 9083 [RFC9083]. In addition, the response MUST include an
	indication of the requested operation's success or failure in the		indication of the requested operation's success or failure in the
	"notices" data structure (including the client identifier), and, if		"notices" data structure (including the client identifier), and, if
	successful, a "session" data structure.		successful, a "roidc1_session" data structure.
	An example of a "session/status" response:		An example of a "roidc1_session/status" response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_openidc_remote_level_0"		"roidc1"
	],		],
	"lang": "en-US",		"lang": "en-US",
	"notices": {		"notices": {
	"title": "Session Status Result",		"title": "Session Status Result",
	"description": [		"description": [
	"Session status succeeded",		"Session status succeeded",
	"user.idp.example"		"user.idp.example"
	]		]
	},		},
	"session": {		"roidc1_session": {
	"userClaims": {		"userClaims": {
	"sub": "103892603076825016132",		"sub": "103892603076825016132",
	"name": "User Person",		"name": "User Person",
	"given_name": "User",		"given_name": "User",
	"family_name": "Person",		"family_name": "Person",
	"picture": "https://lh3.example.com/a-/AOh14=s96-c",		"picture": "https://lh3.example.com/a-/AOh14=s96-c",
	"email": "user@example.com",		"email": "user@example.com",
	"email_verified": true,		"email_verified": true,
	"locale": "en",		"locale": "en",
	"purpose": "domainNameControl",		"rdap_allowed_purposes": [
	"dnt": false		"domainNameControl",
			"personalDataProtection"
			],
			"rdap_dnt_allowed": false
	},		},
	"sessionInfo": {		"sessionInfo": {
	"tokenExpiration": 3490,		"tokenExpiration": 3490,
	"tokenRefresh": true		"tokenRefresh": true
	}		}
	}		}
	}		}
	Figure 10		Figure 11
	4.4. Session Refresh		4.5. Session Refresh
	Clients MAY send a request to an RDAP server to refresh, or extend,		Clients MAY send a request to an RDAP server to refresh, or extend,
	an existing login session using a "session/refresh" path segment.		an existing login session using a "roidc1_session/refresh" path
	The RDAP server MAY attempt to refresh the access token associated		segment. The RDAP server MAY attempt to refresh the access token
	with the current session as part of extending the session for a		associated with the current session as part of extending the session
	period of time determined by the RDAP server. As described in RFC		for a period of time determined by the RDAP server. As described in
	6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP		RFC 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An
	server MUST determine if the OP supports token refresh and process		RDAP server MUST determine if the OP supports token refresh and
	the refresh request by either requesting refresh of the access token		process the refresh request by either requesting refresh of the
	or by returning a response that indicates that token refresh is not		access token or by returning a response that indicates that token
	supported by the OP in the "notices" data structure. An example		refresh is not supported by the OP in the "notices" data structure.
	"session/refresh" request:		An example "roidc1_session/refresh" request:
	https://example.com/rdap/session/refresh		https://example.com/rdap/roidc1_session/refresh
	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 "session" data structure.		and, if successful, a "roidc1_session" data structure.
	An example of a "session/refresh" response:		An example of a "roidc1_session/refresh" response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_openidc_remote_level_0"		"roidc1"
	],		],
	"lang": "en-US",		"lang": "en-US",
	"notices": {		"notices": {
	"title": "Session Refresh Result",		"title": "Session Refresh Result",
	"description": [		"description": [
	"Session refresh succeeded",		"Session refresh succeeded",
	"user.idp.example",		"user.idp.example",
	"Token refresh succeeded."		"Token refresh succeeded."
	]		]
	},		},
	"session": {		"roidc1_session": {
	"userClaims": {		"userClaims": {
	"sub": "103892603076825016132",		"sub": "103892603076825016132",
	"name": "User Person",		"name": "User Person",
	"given_name": "User",		"given_name": "User",
	"family_name": "Person",		"family_name": "Person",
	"picture": "https://lh3.example.com/a-/AOh14=s96-c",		"picture": "https://lh3.example.com/a-/AOh14=s96-c",
	"email": "user@example.com",		"email": "user@example.com",
	"email_verified": true,		"email_verified": true,
	"locale": "en",		"locale": "en",
	"purpose": "domainNameControl",		"rdap_allowed_purposes": [
	"dnt": false		"domainNameControl",
			"personalDataProtection"
			],
			"rdap_dnt_allowed": false
	},		},
	"sessionInfo": {		"sessionInfo": {
	"tokenExpiration": 3599,		"tokenExpiration": 3599,
	"tokenRefresh": true		"tokenRefresh": true
	}		}
	}		}
	}		}
	Figure 11		Figure 12
	4.5. 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
	"session/logout" path segment. Access and refresh tokens can be		"roidc1_session/logout" path segment. Access and refresh tokens can
	revoked during the "session/logout" process as described in RFC 7009		be revoked during the "roidc1_session/logout" process as described in
	[RFC7009] if supported by the OP (token revocation endpoint support		RFC 7009 [RFC7009] if supported by the OP (token revocation endpoint
	is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature		support is OPTIONAL per RFC 8414 [RFC8414]). If supported, this
	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
	MAY attempt to logout from the OP using the "OpenID Connect RP-		MAY attempt to logout from the OP using the "OpenID Connect RP-
	Initiated Logout" protocol ([OIDCL]) if that protocol is supported by		Initiated Logout" protocol ([OIDCL]) if that protocol is supported by
	the OP.		the OP.
	An example "session/logout" request:		An example "roidc1_session/logout" request:
	https://example.com/rdap/session/logout		https://example.com/rdap/roidc1_session/logout
	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).
	The "notices" data structure MUST also include an indication of the		The "notices" data structure MUST also include an indication of the
	success or failure of any attempt to logout from the OP or to revoke		success or failure of any attempt to logout from the OP or to revoke
	the tokens issued by the OP.		the tokens issued by the OP.
	An example of a "session/logout" response:		An example of a "roidc1_session/logout" response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_openidc_remote_level_0"		"roidc1"
	],		],
	"lang": "en-US",		"lang": "en-US",
	"notices": {		"notices": {
	"title": "Logout Result",		"title": "Logout Result",
	"description": [		"description": [
	"Logout succeeded",		"Logout succeeded",
	"user.idp.example",		"user.idp.example",
	"Provider logout failed: Not supported by provider.",		"Provider logout failed: Not supported by provider.",
	"Token revocation successful."		"Token revocation successful."
	]		]
	}		}
	}		}
	Figure 12		Figure 13
	In the absence of a "logout" request, an RDAP session MUST be		In the absence of a "logout" request, an RDAP session MUST be
	terminated by the RDAP server after a server-defined period of time.		terminated by the RDAP server after a server-defined period of time.
	The server should also take appropriate steps to ensure that the		The server should also take appropriate steps to ensure that the
	tokens associated with the terminated session cannot be reused. This		tokens associated with the terminated session cannot be reused. This
	SHOULD include revoking the tokens or logging out from the OP if		SHOULD include revoking the tokens or logging out from the OP if
	either operation is supported by the OP.		either operation is supported by the OP.
	4.6. Parameter Processing		4.7. Parameter Processing
	Unrecognized query parameters MUST be ignored. An RDAP server that		Unrecognized query parameters MUST be ignored. An RDAP server that
	processes an authenticated query MUST determine if the End-User		processes an authenticated query MUST determine if the End-User
	identification information is associated with an OP that is		identification information is associated with an OP that is
	recognized and supported by the server. Servers MUST reject queries		recognized and supported by the server. Servers MUST reject queries
	that include identification information that is not associated with a		that include identification information that is not associated with a
	supported OP by returning an HTTP 501 (Not Implemented) response. An		supported OP by returning an HTTP 501 (Not Implemented) response. An
	RDAP server that receives a query containing identification		RDAP server that receives a query containing identification
	information associated with a recognized OP MUST perform the steps		information associated with a recognized OP MUST perform the steps
	required to authenticate the user with the OP, process the query, and		required to authenticate the user with the OP, process the query, and
	skipping to change at page 21, line 48 ¶		skipping to change at page 25, line 41 ¶
	implementation used by the RDAP server.		implementation used by the RDAP server.
	6. RDAP Query Processing		6. RDAP Query Processing
	Once an RDAP session is active, an RDAP server MUST determine if the		Once an RDAP session is active, an RDAP server MUST determine if the
	End-User is authorized to perform any queries that are received		End-User is authorized to perform any queries that are received
	during the duration of the session. This MAY include rejecting		during the duration of the session. This MAY include rejecting
	queries outright, and it MAY include omitting or otherwise redacting		queries outright, and it MAY include omitting or otherwise redacting
	information that the End-User is not authorized to receive. Specific		information that the End-User is not authorized to receive. Specific
	processing requirements are beyond the scope of this document. A		processing requirements are beyond the scope of this document. A
	client can end a session explicitly by sending a "session/logout"		client can end a session explicitly by sending a "roidc1_session/
	request to the RDAP server. A session can also be ended implicitly		logout" request to the RDAP server. A session can also be ended
	by the server after a server-defined period of time. The status of a		implicitly by the server after a server-defined period of time. The
	session can be determined at any time by sending a "session/status"		status of a session can be determined at any time by sending a
	query to the RDAP server.		"roidc1_session/status" query to the RDAP server.
	An RDAP server MUST maintain session state information for the		An RDAP server MUST maintain session state information for the
	duration of an active session. This is commonly done using HTTP		duration of an active session. This is commonly done using HTTP
	cookies as described in RFC 6265 [RFC6265]. Doing so allows End-User		cookies as described in RFC 6265 [RFC6265]. Doing so allows End-User
	to submit queries without having to explicitly identify and		to submit queries without having to explicitly identify and
	authenticate themselves for each and every query.		authenticate themselves for each and every query.
	7. RDAP Conformance		7. 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 ([RFC9083]) value of "rdap_openidc_remote_level_0"		rdapConformance ([RFC9083]) value of "roidc1" (RDAP OpenID Connect
	(to indicate support for one or more remote Authorization Servers),		version 1). The information needed to register this value in the
	"rdap_openidc_local_level_0" (to indicate support for a local		RDAP Extensions Registry is described in Section 8.1.
	Authorization Server), or both values if the server supports both
	remote and local OpenID Authorization Servers. The information
	needed to register these values in the RDAP Extensions Registry is
	described in Section 8.1.
	Example rdapConformance structure with extension specified:		Example rdapConformance structure with extension specified:
	"rdapConformance" :		"rdapConformance" :
	[		[
	"rdap_level_0",		"rdap_level_0",
	"rdap_openidc_remote_level_0"		"roidc1"
	]		]
	Figure 13		Figure 14
	8. IANA Considerations		8. IANA Considerations
	8.1. RDAP Extensions Registry		8.1. RDAP Extensions Registry
	IANA is requested to register the following values in the RDAP		IANA is requested to register the following value in the RDAP
	Extensions Registry:		Extensions Registry:
	Extension identifier: rdap_openidc_remote_level_0		Extension identifier: roidc1
	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 remote Authorization Server.
	Extension identifier: rdap_openidc_local_level_0
	Registry operator: Any		Registry operator: Any
	Published specification: This document.		Published specification: This document.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Intended usage: This extension describes a federated		Intended usage: This extension describes version 1 of a federated
	authentication method for RDAP using OAuth 2.0, OpenID Connect,		authentication method for RDAP using OAuth 2.0 and OpenID Connect.
	and a local Authorization Server.
	8.2. JSON Web Token Claims Registry		8.2. JSON Web Token Claims Registry
	IANA is requested to register the following values in the JSON Web		IANA is requested to register the following values in the JSON Web
	Token Claims Registry:		Token Claims Registry:
	Claim Name: "purpose"		Claim Name: "rdap_allowed_purposes"
	Claim Description: This claim describes the stated purpose for		Claim Description: This claim describes the set of RDAP query
	submitting a request to access a protected RDAP resource.		purposes that are available to an identity that is presented for
			access to 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: "rdap_dnt_allowed"
	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 a "do not track" request for server-side tracking,
	tracking, logging, or recording when accessing a protected RDAP		logging, or recording of an identity that is presented for access
	resource.		to a protected RDAP resource.
	Change Controller: IESG		Change Controller: IESG
	Specification Document(s): Section 3.1.4.2 of this document.		Specification Document(s): Section 3.1.4.2 of this document.
	8.3. RDAP Query Purpose Registry		8.3. RDAP Query Purpose Registry
	IANA is requested to create a new protocol registry to manage RDAP		IANA is requested to create a new protocol registry to manage RDAP
	query purpose values. This registry should be named "Registration		query purpose values. This registry should be named "Registration
	Data Access Protocol (RDAP) Query Purpose Values" and should appear		Data Access Protocol (RDAP) Query Purpose Values" and should appear
	under the "Registration Data Access Protocol (RDAP)" section of		under the "Registration Data Access Protocol (RDAP)" section of
	IANA's protocol registries. The information to be registered and the		IANA's protocol registries. The information to be registered and the
	skipping to change at page 29, line 28 ¶		skipping to change at page 33, line 5 ¶
	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: Marc		their contributions to the development of this document: Marc
	Blanchet, Tom Harrison, Russ Housley, Jasdip Singh, Rhys Smith,		Blanchet, Tom Harrison, Russ Housley, Jasdip Singh, Rhys Smith,
	Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In addition, the		Jaromir Talir, Rick Wilhelm, and Alessandro Vesely. In addition, the
	Verisign Registry Services Lab development team of Joseph Harvey,		Verisign Registry Services Lab development team of Joseph Harvey,
	Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin		Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin
	Singh, and Zhao Zhao provided critical "proof of concept"		Singh, and Zhao Zhao provided critical "proof of concept"
	implementation experience that helped demonstrate the validity of the		implementation experience that helped demonstrate the validity of the
	concepts described in this document.		concepts described in this document.
	Mario Loffredo provided significant feedback based on implementation		Pawel Kowalik and Mario Loffredo provided significant text
	experience that led to welcome improvements in several sections of		contributions that led to welcome improvements in several sections of
	this document. His contributions are greatly appreciated.		this document. Their contributions are greatly appreciated.
	12. References		12. References
	12.1. Normative References		12.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 32, line 26 ¶		skipping to change at page 36, line 4 ¶
	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		09: Updated RDAP specification references. Added text to describe
	both local and remote Authorization Server processing. Removed		both default and remote Authorization Server processing. Removed
	text that described passing of ID Tokens as query parameters.		text that described passing of ID Tokens as query parameters.
	10: Updated Section 3.1.3.1. Replaced token processing queries with		10: Updated Section 3.1.3.1. Replaced token processing queries with
	"login", "session", and "logout" queries.		"login", "session", and "logout" queries.
	11: Replaced queries with "session/*" queries. Added description of		11: Replaced queries with "session/*" queries. Added description of
	"rdap" OAuth scope. Added implementation status information.		"rdap" OAuth scope. Added implementation status information.
	12: Updated data structure descriptions. Updated Section 8. Minor		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.
			Modified the RDAP conformance text to use "roidc1", and added that
			value to extension path segments, data structures, and query
			parameters. Changed the "purpose" and "dnt" claims to
			"rdap_allowed_purposes" (making it an array) and
			"rdap_dnt_allowed". Added the "roidc1_qp" and "roidc1_dnt" query
			parameters. Changed the descriptions of "local" OPs to "default"
			OPs.
	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. 106 change blocks.
	284 lines changed or deleted		456 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/