--- 1/draft-ietf-regext-rdap-openid-13.txt 2022-05-24 10:13:10.490863107 -0700 +++ 2/draft-ietf-regext-rdap-openid-14.txt 2022-05-24 10:13:10.566865041 -0700 @@ -1,19 +1,19 @@ REGEXT Working Group S. Hollenbeck Internet-Draft Verisign Labs -Intended status: Standards Track 18 May 2022 -Expires: 19 November 2022 +Intended status: Standards Track 24 May 2022 +Expires: 25 November 2022 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect - draft-ietf-regext-rdap-openid-13 + draft-ietf-regext-rdap-openid-14 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 19 November 2022. + This Internet-Draft will expire on 25 November 2022. Copyright Notice Copyright (c) 2022 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 carefully, as they describe your rights @@ -84,42 +84,42 @@ 4.2.2. OP Issuer Identifier . . . . . . . . . . . . . . . . 15 4.2.3. Login Response . . . . . . . . . . . . . . . . . . . 15 4.2.4. Clients with Limited User Interfaces . . . . . . . . 17 4.2.4.1. UI-constrained Client Login . . . . . . . . . . . 17 4.2.4.2. UI-constrained Client Login Polling . . . . . . . 19 4.3. RDAP Query Parameters . . . . . . . . . . . . . . . . . . 19 4.3.1. RDAP Query Purpose . . . . . . . . . . . . . . . . . 20 4.3.2. RDAP Do Not Track . . . . . . . . . . . . . . . . . . 20 4.4. Session Status . . . . . . . . . . . . . . . . . . . . . 20 4.5. Session Refresh . . . . . . . . . . . . . . . . . . . . . 22 - 4.6. Client Logout . . . . . . . . . . . . . . . . . . . . . . 23 + 4.6. Client Logout . . . . . . . . . . . . . . . . . . . . . . 24 4.7. Parameter Processing . . . . . . . . . . . . . . . . . . 25 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 25 - 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 25 + 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 26 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 26 - 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 26 + 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 27 + 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 27 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 27 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 31 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 31 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 32 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 10.1. Authentication and Access Control . . . . . . . . . . . 32 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 10.1. Authentication and Access Control . . . . . . . . . . . 33 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 35 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction 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) [RFC7230]. @@ -331,25 +331,25 @@ described in Section 3.2 of the OpenID Connect Core protocol. The Hybrid Flow (described in Section 3.3 of the OpenID Connect Core protocol) combines elements of the Authorization and Implicit Flows by returning some tokens from the Authorization Endpoint and others from the Token Endpoint. An Authentication Request can contain several parameters. REQUIRED parameters are specified in Section 3.1.2.1 of the OpenID Connect Core protocol [OIDCC]. Apart from these parameters, it is RECOMMENDED that the RP include the optional "login_hint" parameter - in the request, with the value being that of the "id" query parameter - of the End-User's RDAP "login" request, if provided. Passing the - "login_hint" parameter allows a client to pre-fill login form - information, so logging in can be more convenient for users. Other - parameters MAY be included. + in the request, with the value being that of the "roidc1_id" query + parameter of the End-User's RDAP "login" request, if provided. + Passing the "login_hint" parameter allows a client to pre-fill login + form information, so logging in can be more convenient for users. + Other parameters MAY be included. The OP receives the Authentication Request and attempts to validate 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 authenticate the End-User as described in Section 3.1.2.3 of the OpenID Connect Core protocol [OIDCC]. The OP returns an error response if the request is not valid or if any error is encountered. 3.1.3.3. End-User Authorization @@ -584,21 +584,24 @@ 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 + 4. "implicitTokenRefreshSupported": (OPTIONAL) a boolean value that + describes RDAP server support for implicit token refresh. The + default value is "false". + 5. "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 @@ -777,37 +780,37 @@ MUST include an End-User identifier that's delivered using one of two methods: by 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 HTTP authorization header for the Basic authentication scheme as described in RFC 7617 [RFC7617]. If the RDAP server supports a default Authorization Server, the End-User identifier MAY be omitted. Clients can use either of these methods. Servers MUST support both methods. The query used to request client authentication is represented as an - OPTIONAL "key=value" pair using a key value of "id" and a value - component that contains the client identifier issued by an OP. + OPTIONAL "key=value" pair using a key value of "roidc1_id" and a + value component that contains the client identifier issued by an OP. An example using wget for client identifier "user.idp.example": wget -qO- --keep-session-cookies --save-cookies\ - https://example.com/rdap/session/device?roidc1_id=user.idp.example + https://example.com/rdap/roidc1_session/device?roidc1_id=user.idp.example Figure 6 The authorization header for the Basic authentication scheme contains a Base64-encoded representation of the client identifier issued by an OP. No password is provided. An example using curl and an authorization header: curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\ - -c cookies.txt https://example.com/rdap/session/device + -c cookies.txt https://example.com/rdap/roidc1_session/device Figure 7 The response to this request MUST use the response structures specified in RFC 9083 [RFC9083]. In addition, the response MUST include an indication of the requested operation's success or failure in the "notices" data structure (including the client identifier), and, if successful, a "roidc1_deviceInfo" data structure. An example of a "roidc1_session/device" response: @@ -1023,20 +1026,40 @@ }, "sessionInfo": { "tokenExpiration": 3599, "tokenRefresh": true } } } Figure 12 + Alternatively, an RDAP server MAY implicitly attempt to refresh an + access token upon receipt of a query if the access token associated + with an existing session has expired and the corresponding OP + supports token refresh. The default RDAP server behavior is + described in the "implicitTokenRefreshSupported" value that's include + in the "roidc1_openidcConfiguration" data structure (see + Section 4.1.3). If the value of "implicitTokenRefreshSupported" is + "true", the client MAY either explicitly attempt to refresh the + session using the "roidc1_session/refresh" query, or it MAY depend on + the RDAP server to implicitly attempt to refresh the session as + necessary when an RDAP query is received by the server. If the value + of "implicitTokenRefreshSupported" is "false", the client MUST + explicitly attempt to refresh the session using the "roidc1_session/ + refresh" query to extend an existing session. If a session cannot be + extended for any reason, the client MUST establish a new session to + continue authenticated query processing by submitting a + "roidc1_session/login" query. If the OP does not support token + refresh, the client MUST submit a new "roidc1_session/login" request + to establish a new session once an access token has expired. + 4.6. Client Logout Clients MAY send a request to an RDAP server to terminate an existing login session. Termination of a session is requested using a "roidc1_session/logout" path segment. Access and refresh tokens can be revoked during the "roidc1_session/logout" process as described in RFC 7009 [RFC7009] if supported by the OP (token revocation endpoint support is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature SHOULD be used to ensure that the tokens are not mistakenly associated with a future RDAP session. Alternatively, an RDAP server @@ -1612,20 +1633,23 @@ 12: Updated data structure descriptions. Updated Section 8. Minor 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. + 14: Fixed a few instances of "id" that were changed to "roidc1_id" + and "session" that were changed to "roidc1_session". Added + "implicitTokenRefreshSupported". Author's Address Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/