--- 1/draft-ietf-regext-rdap-openid-01.txt 2019-05-31 12:13:08.965917501 -0700 +++ 2/draft-ietf-regext-rdap-openid-02.txt 2019-05-31 12:13:09.017918810 -0700 @@ -1,19 +1,19 @@ REGEXT Working Group S. Hollenbeck Internet-Draft Verisign Labs -Intended status: Standards Track May 28, 2019 -Expires: November 29, 2019 +Intended status: Standards Track May 31, 2019 +Expires: December 2, 2019 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect - draft-ietf-regext-rdap-openid-01 + draft-ietf-regext-rdap-openid-02 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 November 29, 2019. + This Internet-Draft will expire on December 2, 2019. 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 @@ -487,29 +487,29 @@ identifier associated with an unsupported OP with an HTTP 501 (Not Implemented) response. An RDAP server that receives a query containing an identifier associated with a recognized OP MUST perform the steps required to authenticate the user with the OP using a browser or browser-like client and return encoded tokens to the client. Note that tokens are typically valid for a limited period of time and new tokens will be required when an existing token's validity period has expired. The tokens can then be passed to the server for use with an RDAP - query by passing the encoded Access Token as a query parameter with a - key value of "access_token" and the encoded ID Token in an HTTP - Bearer authorization header [RFC6750]. An example (the encoded - tokens have been abbreviated and the URI split across multiple lines - for clarity): + query by passing the encoded ID Token as a query parameter with a key + value of "id_token" and the encoded Access Token in an HTTP Bearer + authorization header [RFC6750]. An example (the encoded tokens have + been abbreviated and the URI split across multiple lines for + clarity): - https://example.com/rdap/domain/example.com?access_token=eyJ0...NiJ9 + https://example.com/rdap/domain/example.com?id_token=eyJ0...EjXk - Authorization: Bearer eyJ0...EjXk + Authorization: Bearer eyJ0...NiJ9 The response to an authenticated query MUST use the response structures specified in RFC 7483 [RFC7483]. Information that the end-user is not authorized to receive MUST be omitted from the response. 4.3. Token Refresh and Revocation An access token can be refreshed as described in Section 12 of the OpenID Connect Core protocol [OIDCC] and Section 6 of OAuth 2.0 @@ -1147,20 +1147,23 @@ [2] http://curl.haxx.se/ [3] https://www.gnu.org/software/wget/ 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. Author's Address Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 USA Email: shollenbeck@verisign.com