draft-ietf-regext-rdap-openid-02.txt		draft-ietf-regext-rdap-openid-03.txt
	REGEXT Working Group S. Hollenbeck		REGEXT Working Group S. Hollenbeck
	Internet-Draft Verisign Labs		Internet-Draft Verisign Labs
	Intended status: Standards Track May 31, 2019		Intended status: Standards Track August 19, 2019
	Expires: December 2, 2019		Expires: February 20, 2020
	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-02		draft-ietf-regext-rdap-openid-03
	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 December 2, 2019.		This Internet-Draft will expire on February 20, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8		3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8
	3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9		3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9
	4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9		4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Client Authentication Request and Response . . . . . . . 10		4.1. Client Authentication Request and Response . . . . . . . 10
	4.2. Token Request and Response . . . . . . . . . . . . . . . 10		4.2. Token Request and Response . . . . . . . . . . . . . . . 10
	4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 11		4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 11
	4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14		4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14
	4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14		4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14
	4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15		4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15
	5. Clients with Limited User Interfaces . . . . . . . . . . . . 15		5. Clients with Limited User Interfaces . . . . . . . . . . . . 15
	5.1. OAuth 2.0 Device Flow . . . . . . . . . . . . . . . . . . 16		5.1. OAuth 2.0 Device Authorization Grant . . . . . . . . . . 16
	5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16		5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17		6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17
	6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17		6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17
	6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 17		6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 17
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
	7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21		7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21
	7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21		7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 22		8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	8.1. Authentication and Access Control . . . . . . . . . . . . 22		8.1. Authentication and Access Control . . . . . . . . . . . . 22
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	5. Clients with Limited User Interfaces		5. Clients with Limited User Interfaces
	The flow described in Section 3.1.3 requires a client to interact		The flow described in Section 3.1.3 requires a client to interact
	with a server using a web browser. This will not work well in		with a server using a web browser. This will not work well in
	situations where the client is automated or an end-user is using a		situations where the client is automated or an end-user is using a
	command line user interface such as curl [2] or wget [3]. There are		command line user interface such as curl [2] or wget [3]. There are
	multiple ways to address this limitation using a web browser on a		multiple ways to address this limitation using a web browser on a
	second device. Two are described here.		second device. Two are described here.
	5.1. OAuth 2.0 Device Flow		5.1. OAuth 2.0 Device Authorization Grant
	The "OAuth 2.0 Device Flow for Browserless and Input Constrained		The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides one
	Devices" [I-D.ietf-oauth-device-flow] provides one method to request		method to request user authorization from devices that have an
	user authorization from devices that have an Internet connection, but		Internet connection, but lack a suitable browser for a more
	lack a suitable browser for a more traditional OAuth flow. This		traditional OAuth flow. This method requires a client to use a
	method requires a client to use a second device (such as a smart		second device (such as a smart telephone) that has access to a web
	telephone) that has access to a web browser for entry of a code		browser for entry of a code sequence that is presented on the
	sequence that is presented on the constrained device.		constrained device.
	5.2. Manual Token Management		5.2. Manual Token Management
	A second method of requesting user authorization from a constrained		A second method of requesting user authorization from a constrained
	device is possible by producing and managing tokens manually as		device is possible by producing and managing tokens manually as
	follows:		follows:
	1. Authenticate with the OP as described in Section 4.2 using a		1. Authenticate with the OP as described in Section 4.2 using a
	browser or browser-like client.		browser or browser-like client.
	2. Store the returned ID Token and Access Token locally.		2. Store the returned ID Token and Access Token locally.
	skipping to change at page 22, line 42 ¶		skipping to change at page 22, line 42 ¶
	Vesely. In addition, the Verisign Registry Services Lab development		Vesely. In addition, the Verisign Registry Services Lab development
	team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena,		team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena,
	Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof		Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof
	of concept" implementation experience that helped demonstrate the		of concept" implementation experience that helped demonstrate the
	validity of the concepts described in this document.		validity of the concepts described in this document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-oauth-device-flow]
	Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
	"OAuth 2.0 Device Authorization Grant", draft-ietf-oauth-
	device-flow-15 (work in progress), March 2019.
	[I-D.ietf-oauth-token-exchange]		[I-D.ietf-oauth-token-exchange]
	Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.		Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
	Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-		Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
	token-exchange-16 (work in progress), October 2018.		token-exchange-19 (work in progress), July 2019.
	[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,
	<http://openid.net/specs/openid-connect-core-1_0.html>.		<http://openid.net/specs/openid-connect-core-1_0.html>.
	[OIDCD] OpenID Foundation, "OpenID Connect Discovery 1.0		[OIDCD] OpenID Foundation, "OpenID Connect Discovery 1.0
	incorporating errata set 1", November 2014,		incorporating errata set 1", November 2014,
	skipping to change at page 24, line 47 ¶		skipping to change at page 24, line 37 ¶
	2015, <https://www.rfc-editor.org/info/rfc7515>.		2015, <https://www.rfc-editor.org/info/rfc7515>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
			"OAuth 2.0 Device Authorization Grant", RFC 8628,
			DOI 10.17487/RFC8628, August 2019,
			<https://www.rfc-editor.org/info/rfc8628>.
	10.2. Informative References		10.2. Informative References
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.		<https://www.rfc-editor.org/info/rfc4949>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
	skipping to change at page 25, line 28 ¶		skipping to change at page 25, line 23 ¶
	Appendix A. Change Log		Appendix A. Change Log
	00: Initial working group version ported from draft-hollenbeck-		00: Initial working group version ported from draft-hollenbeck-
	regext-rdap-openid-10.		regext-rdap-openid-10.
	01: Modified ID Token delivery approach to note proper use of an		01: Modified ID Token delivery approach to note proper use of an
	HTTP bearer authorization header.		HTTP bearer authorization header.
	02: Modified token delivery approach (access token is the bearer		02: Modified token delivery approach (access token is the bearer
	token) to note proper use of an HTTP bearer authorization header,		token) to note proper use of an HTTP bearer authorization header,
	fixing the change made in -01.		fixing the change made in -01.
			03: Updated OAuth 2.0 Device Authorization Grant description and
			reference due to publication of RFC 8628.
	Author's Address		Author's Address
	Scott Hollenbeck		Scott Hollenbeck
	Verisign Labs		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	USA		USA
	Email: shollenbeck@verisign.com		Email: shollenbeck@verisign.com
End of changes. 10 change blocks.
	19 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/