--- 1/draft-ietf-regext-rdap-openid-02.txt 2019-08-19 05:13:14.977508591 -0700 +++ 2/draft-ietf-regext-rdap-openid-03.txt 2019-08-19 05:13:15.009509017 -0700 @@ -1,19 +1,19 @@ REGEXT Working Group S. Hollenbeck Internet-Draft Verisign Labs -Intended status: Standards Track May 31, 2019 -Expires: December 2, 2019 +Intended status: Standards Track August 19, 2019 +Expires: February 20, 2020 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect - draft-ietf-regext-rdap-openid-02 + draft-ietf-regext-rdap-openid-03 Abstract The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,21 +76,21 @@ 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9 4.1. Client Authentication Request and Response . . . . . . . 10 4.2. Token Request and Response . . . . . . . . . . . . . . . 10 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 11 4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14 4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 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 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17 6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17 6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 17 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8.1. Authentication and Access Control . . . . . . . . . . . . 22 @@ -703,29 +703,29 @@ 5. Clients with Limited User Interfaces 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 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 multiple ways to address this limitation using a web browser on a 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 - Devices" [I-D.ietf-oauth-device-flow] provides one method to request - user authorization from devices that have an Internet connection, but - lack a suitable browser for a more traditional OAuth flow. This - method requires a client to use a 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 constrained device. + The "OAuth 2.0 Device Authorization Grant" [RFC8628] provides one + method to request user authorization from devices that have an + Internet connection, but lack a suitable browser for a more + traditional OAuth flow. This method requires a client to use a + 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 + constrained device. 5.2. Manual Token Management A second method of requesting user authorization from a constrained device is possible by producing and managing tokens manually as follows: 1. Authenticate with the OP as described in Section 4.2 using a browser or browser-like client. 2. Store the returned ID Token and Access Token locally. @@ -1024,29 +1024,24 @@ Vesely. In addition, the Verisign Registry Services Lab development team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof of concept" implementation experience that helped demonstrate the validity of the concepts described in this document. 10. 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] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. 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", . [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating errata set 1", November 2014, . [OIDCD] OpenID Foundation, "OpenID Connect Discovery 1.0 incorporating errata set 1", November 2014, @@ -1121,20 +1116,25 @@ 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, + "OAuth 2.0 Device Authorization Grant", RFC 8628, + DOI 10.17487/RFC8628, August 2019, + . + 10.2. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . @@ -1150,20 +1150,22 @@ Appendix A. Change Log 00: Initial working group version ported from draft-hollenbeck- regext-rdap-openid-10. 01: Modified ID Token delivery approach to note proper use of an HTTP bearer authorization header. 02: Modified token delivery approach (access token is the bearer token) to note proper use of an HTTP bearer authorization header, 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 Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 USA Email: shollenbeck@verisign.com