| < draft-ietf-regext-rdap-openid-11.txt | draft-ietf-regext-rdap-openid-12.txt > | |||
|---|---|---|---|---|
| REGEXT Working Group S. Hollenbeck | REGEXT Working Group S. Hollenbeck | |||
| Internet-Draft Verisign Labs | Internet-Draft Verisign Labs | |||
| Intended status: Standards Track 24 February 2022 | Intended status: Standards Track 23 March 2022 | |||
| Expires: 28 August 2022 | Expires: 24 September 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-11 | draft-ietf-regext-rdap-openid-12 | |||
| 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 28 August 2022. | This Internet-Draft will expire on 24 September 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 41 ¶ | skipping to change at page 2, line 41 ¶ | |||
| 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 Purpose . . . . . . . . . . . . . . . . . 9 | |||
| 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10 | 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10 | |||
| 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 | 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 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.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 4.2.1. Clients with Limited User Interfaces . . . . . . . . 15 | 4.2.1. Clients with Limited User Interfaces . . . . . . . . 15 | |||
| 4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15 | 4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15 | |||
| 4.2.1.2. UI-constrained Client Login Polling . . . . . . . 16 | 4.2.1.2. UI-constrained Client Login Polling . . . . . . . 17 | |||
| 4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17 | 4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18 | 4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20 | 4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21 | 4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21 | |||
| 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 | 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21 | 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21 | |||
| 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22 | 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22 | 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22 | |||
| 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23 | 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23 | |||
| 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23 | 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23 | |||
| 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 | 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 | |||
| 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 26 | 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 27 | |||
| 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 26 | 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 27 | 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
| 10.1. Authentication and Access Control . . . . . . . . . . . 28 | 10.1. Authentication and Access Control . . . . . . . . . . . 29 | |||
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 30 | 12.2. Informative References . . . . . . . . . . . . . . . . . 31 | |||
| Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 | Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 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 11, line 20 ¶ | skipping to change at page 11, line 20 ¶ | |||
| 4.1. Data Structures | 4.1. Data Structures | |||
| This specification describes two new data structures that are used to | This specification describes two new data structures that are used to | |||
| return information to a client: a "session" data structure that | return information to a client: a "session" data structure that | |||
| contains information that describes an established session, and a | contains information that describes an established session, and a | |||
| "deviceInfo" data structure that contains information that describes | "deviceInfo" data structure that contains information that describes | |||
| an active attempt to establish a session on a UI-constrained device. | an active attempt to establish a session on a UI-constrained device. | |||
| 4.1.1. Session | 4.1.1. Session | |||
| The "session" data structure is an array that contains two sub- | The "session" data structure is an object that contains two sub- | |||
| arrays: | objects: | |||
| 1. A "userClaims" array that contains the set of claims associated | 1. A "userClaims" object that contains the set of claims associated | |||
| with the End-User's identity, with each claim represented as a | with the End-User's identity as used/requested by the RDAP server | |||
| name-value pair in string format. 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" array that contains two name-value pairs: | 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 "session" data structure: | |||
| "session": { | "session": { | |||
| skipping to change at page 12, line 37 ¶ | skipping to change at page 12, line 37 ¶ | |||
| 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 "deviceInfo" data structure. | |||
| The "deviceInfo" data structure is an array that contains three name- | The "deviceInfo" data structure is an object that contains three | |||
| value pairs: | 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 "deviceInfo" data structure: | |||
| skipping to change at page 15, line 47 ¶ | skipping to change at page 15, line 47 ¶ | |||
| 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]. If the RDAP server supports a local | described in RFC 7617 [RFC7617]. If the RDAP server supports a local | |||
| Authorization Server, the End-User identifier MAY be omitted. | Authorization Server, the End-User identifier MAY be omitted. | |||
| Clients can use either of these methods. Servers MUST support both | Clients can use either of these methods. Servers MUST support both | |||
| methods. | 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. An | component that contains the client identifier issued by an OP. | |||
| 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\ | ||||
| https://example.com/rdap/session/device?id=user.idp.example | ||||
| Figure 5 | ||||
| wget -qO- --keep-session-cookies --save- | ||||
| cookies\https://example.com/rdap/session/device?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 using curl and an | OP. No password is provided. | |||
| authorization header: | ||||
| curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\-c | An example using curl and an authorization header: | |||
| cookies.txt https://example.com/rdap/session/device | ||||
| curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\ | ||||
| -c cookies.txt https://example.com/rdap/session/device | ||||
| Figure 6 | ||||
| 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 "deviceInfo" data structure. | |||
| An example of a "session/device" response: | An example of a "session/device" response: | |||
| { | { | |||
| skipping to change at page 16, line 35 ¶ | skipping to change at page 16, line 40 ¶ | |||
| "notices": { | "notices": { | |||
| "title": "Device Login Result", | "title": "Device Login Result", | |||
| "description": [ | "description": [ | |||
| "Login succeeded", | "Login succeeded", | |||
| "user.idp.example" | "user.idp.example" | |||
| ] | ] | |||
| }, | }, | |||
| "deviceInfo": { | "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 5 | Figure 7 | |||
| 4.2.1.2. UI-constrained Client Login Polling | 4.2.1.2. UI-constrained Client Login Polling | |||
| After successful processing of the "session/device" request, the | After successful processing of the "session/device" request, the | |||
| client MUST send a "session/devicepoll" request to the RDAP server to | client MUST send a "session/devicepoll" request to the RDAP server to | |||
| continue the login process. This request performs the polling | continue the login process. This request performs the polling | |||
| function described in RFC 8628 [RFC8628], allowing the RDAP server to | function described in RFC 8628 [RFC8628], allowing the RDAP server to | |||
| wait for the End-User to enter the information returned from the | wait for the End-User to enter the information returned from the | |||
| "session/device" request using the interface on their second device. | "session/device" request using the interface on their second device. | |||
| After the End-User has completed that process, or if the process | After the End-User has completed that process, or if the process | |||
| fails or times out, the OP will respond to the polling requests with | fails or times out, the OP will respond to the polling requests with | |||
| an indication of success or failure. An example using wget: | an indication of success or failure. | |||
| wget -qO- --load-cookies | An example using wget: | |||
| cookies.txt\https://example.com/rdap/session/devicepoll | ||||
| wget -qO- --load-cookies cookies.txt\ | ||||
| https://example.com/rdap/session/devicepoll | ||||
| Figure 8 | ||||
| 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/session/devicepoll | |||
| Figure 9 | ||||
| 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. Session Status | |||
| Clients MAY send a query to an RDAP server to determine the status of | Clients MAY send a query to an RDAP server to determine the status of | |||
| an existing login session using a "session/status" path segment. An | an existing login session using a "session/status" path segment. An | |||
| skipping to change at page 18, line 37 ¶ | skipping to change at page 18, line 37 ¶ | |||
| "purpose": "domainNameControl", | "purpose": "domainNameControl", | |||
| "dnt": false | "dnt": false | |||
| }, | }, | |||
| "sessionInfo": { | "sessionInfo": { | |||
| "tokenExpiration": 3490, | "tokenExpiration": 3490, | |||
| "tokenRefresh": true | "tokenRefresh": true | |||
| } | } | |||
| } | } | |||
| } | } | |||
| Figure 6 | Figure 10 | |||
| 4.4. Session Refresh | 4.4. 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 "session/refresh" path segment. | |||
| The RDAP server MAY attempt to refresh the access token associated | The RDAP server MAY attempt to refresh the access token associated | |||
| with the current session as part of extending the session for a | with the current session as part of extending the session for a | |||
| period of time determined by the RDAP server. As described in RFC | period of time determined by the RDAP server. As described in RFC | |||
| 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP | 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP | |||
| server MUST determine if the OP supports token refresh and process | server MUST determine if the OP supports token refresh and process | |||
| skipping to change at page 19, line 48 ¶ | skipping to change at page 19, line 48 ¶ | |||
| "purpose": "domainNameControl", | "purpose": "domainNameControl", | |||
| "dnt": false | "dnt": false | |||
| }, | }, | |||
| "sessionInfo": { | "sessionInfo": { | |||
| "tokenExpiration": 3599, | "tokenExpiration": 3599, | |||
| "tokenRefresh": true | "tokenRefresh": true | |||
| } | } | |||
| } | } | |||
| } | } | |||
| Figure 7 | Figure 11 | |||
| 4.5. Client Logout | 4.5. 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 | "session/logout" path segment. Access and refresh tokens can be | |||
| revoked during the "session/logout" process as described in RFC 7009 | revoked during the "session/logout" process as described in RFC 7009 | |||
| [RFC7009] if supported by the OP (token revocation endpoint support | [RFC7009] if supported by the OP (token revocation endpoint support | |||
| is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature | is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature | |||
| SHOULD be used to ensure that the tokens are not mistakenly | SHOULD be used to ensure that the tokens are not mistakenly | |||
| skipping to change at page 20, line 49 ¶ | skipping to change at page 20, line 49 ¶ | |||
| "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 8 | Figure 12 | |||
| 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.6. Parameter Processing | |||
| skipping to change at page 22, line 31 ¶ | skipping to change at page 22, line 31 ¶ | |||
| described in Section 8.1. | 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" | "rdap_openidc_remote_level_0" | |||
| ] | ] | |||
| Figure 9 | Figure 13 | |||
| 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 values in the RDAP | |||
| Extensions Registry: | Extensions Registry: | |||
| * Extension identifier: rdap_openidc_remote_level_0 | Extension identifier: rdap_openidc_remote_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 a federated | |||
| authentication method for RDAP using OAuth 2.0, OpenID Connect, | authentication method for RDAP using OAuth 2.0, OpenID Connect, | |||
| and a remote Authorization Server. | and a remote Authorization Server. | |||
| * Extension identifier: rdap_openidc_local_level_0 | 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 a federated | |||
| authentication method for RDAP using OAuth 2.0, OpenID Connect, | authentication method for RDAP using OAuth 2.0, OpenID Connect, | |||
| and a local Authorization Server. | 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: "purpose" | |||
| * Claim Description: This claim describes the stated purpose for | Claim Description: This claim describes the stated purpose for | |||
| submitting a request to access a protected RDAP resource. | submitting a request to access 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: "dnt" | |||
| * 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 an End-User's "do not track" preference for identity | |||
| tracking, logging, or recording when accessing a protected RDAP | tracking, logging, or recording when accessing a protected RDAP | |||
| resource. | 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 appear under its own | query purpose values. This registry should be named "Registration | |||
| heading on IANA's protocol listings, using the same title as the name | Data Access Protocol (RDAP) Query Purpose Values" and should appear | |||
| of the registry. The information to be registered and the procedures | under the "Registration Data Access Protocol (RDAP)" section of | |||
| to be followed in populating the registry are described in | IANA's protocol registries. The information to be registered and the | |||
| procedures to be followed in populating the registry are described in | ||||
| Section 3.1.4.1. | Section 3.1.4.1. | |||
| Name of registry: Registration Data Access Protocol (RDAP) Query | Section at http://www.iana.org/protocols: Registration Data Access | |||
| Purpose Values | Protocol (RDAP) | |||
| Section at http://www.iana.org/protocols: | ||||
| Registry Title: Registration Data Access Protocol (RDAP) Query | Name of registry: Registration Data Access Protocol (RDAP) Query | |||
| Purpose Values | Purpose Values | |||
| Registry Name: Registration Data Access Protocol (RDAP) Query Purpose | ||||
| Values | ||||
| Registration Procedure: Specification Required | Registration Procedure: Specification Required | |||
| Reference: This draft | Reference: This document | |||
| Required information: See Section 3.1.4.1. | Required information: See Section 3.1.4.1. | |||
| Review process: "Specification Required" as described in RFC 5226 | Review process: "Specification Required" as described in RFC 5226 | |||
| [RFC5226]. | [RFC5226]. | |||
| Size, format, and syntax of registry entries: See Section 3.1.4.1. | Size, format, and syntax of registry entries: See Section 3.1.4.1. | |||
| Initial assignments and reservations: | Initial assignments and reservations: | |||
| -----BEGIN FORM----- Value: domainNameControl Description: Tasks | -----BEGIN FORM----- | |||
| within the scope of this purpose include creating and managing and | ||||
| monitoring a registrant's own domain name, including creating the | Value: domainNameControl | |||
| domain name, updating information about the domain name, transferring | ||||
| the domain name, renewing the domain name, deleting the domain name, | Description: Tasks within the scope of this purpose include | |||
| maintaining a domain name portfolio, and detecting fraudulent use of | creating and managing and monitoring a registrant's own domain | |||
| the Registrant's own contact information. -----END FORM----- | name, including creating the domain name, updating information | |||
| about the domain name, transferring the domain name, renewing the | ||||
| domain name, deleting the domain name, maintaining a domain name | ||||
| portfolio, and detecting fraudulent use of the Registrant's own | ||||
| contact information. | ||||
| -----BEGIN FORM----- Value: personalDataProtection Description: Tasks | ||||
| within the scope of this purpose include identifying the accredited | ||||
| privacy/proxy provider associated with a domain name and reporting | ||||
| abuse, requesting reveal, or otherwise contacting the provider. | ||||
| -----END FORM----- | -----END FORM----- | |||
| -----BEGIN FORM----- Value: technicalIssueResolution Description: | -----BEGIN FORM----- | |||
| Tasks within the scope of this purpose include (but are not limited | ||||
| to) working to resolve technical issues, including email delivery | Value: personalDataProtection | |||
| issues, DNS resolution failures, and web site functional issues. | ||||
| Description: Tasks within the scope of this purpose include | ||||
| identifying the accredited privacy/proxy provider associated with | ||||
| a domain name and reporting abuse, requesting reveal, or otherwise | ||||
| contacting the provider. | ||||
| -----END FORM----- | -----END FORM----- | |||
| -----BEGIN FORM----- Value: domainNameCertification Description: | -----BEGIN FORM----- | |||
| Tasks within the scope of this purpose include a Certification | ||||
| Authority (CA) issuing an X.509 certificate to a subject identified | ||||
| by a domain name. -----END FORM----- | ||||
| -----BEGIN FORM----- Value: individualInternetUse Description: Tasks | Value: technicalIssueResolution | |||
| within the scope of this purpose include identifying the organization | ||||
| using a domain name to instill consumer trust, or contacting that | ||||
| organization to raise a customer complaint to them or file a | ||||
| complaint about them. -----END FORM----- | ||||
| -----BEGIN FORM----- Value: businessDomainNamePurchaseOrSale | Description: Tasks within the scope of this purpose include (but | |||
| Description: Tasks within the scope of this purpose include making | are not limited to) working to resolve technical issues, including | |||
| purchase queries about a domain name, acquiring a domain name from a | email delivery issues, DNS resolution failures, and web site | |||
| registrant, and enabling due diligence research. -----END FORM----- | functional issues. | |||
| -----BEGIN FORM----- Value: academicPublicInterestDNSRResearch | ||||
| Description: Tasks within the scope of this purpose include academic | ||||
| public interest research studies about domain names published in the | ||||
| registration data service, including public information about the | ||||
| registrant and designated contacts, the domain name's history and | ||||
| status, and domain names registered by a given registrant (reverse | ||||
| query). -----END FORM----- | ||||
| -----BEGIN FORM----- Value: legalActions Description: Tasks within | -----END FORM----- | |||
| the scope of this purpose include investigating possible fraudulent | ||||
| use of a registrant's name or address by other domain names, | -----BEGIN FORM----- | |||
| investigating possible trademark infringement, contacting a | ||||
| registrant/licensee's legal representative prior to taking legal | Value: domainNameCertification | |||
| action and then taking a legal action if the concern is not | ||||
| satisfactorily addressed. -----END FORM----- | Description: Tasks within the scope of this purpose include a | |||
| Certification Authority (CA) issuing an X.509 certificate to a | ||||
| subject identified by a domain name. | ||||
| -----BEGIN FORM----- Value: regulatoryAndContractEnforcement | ||||
| Description: Tasks within the scope of this purpose include tax | ||||
| authority investigation of businesses with online presence, Uniform | ||||
| Dispute Resolution Policy (UDRP) investigation, contractual | ||||
| compliance investigation, and registration data escrow audits. | ||||
| -----END FORM----- | -----END FORM----- | |||
| -----BEGIN FORM----- Value: | -----BEGIN FORM----- | |||
| criminalInvestigationAndDNSAbuseMitigation Description: Tasks within | ||||
| the scope of this purpose include reporting abuse to someone who can | Value: individualInternetUse | |||
| investigate and address that abuse, or contacting entities associated | ||||
| with a domain name during an offline criminal investigation. | Description: Tasks within the scope of this purpose include | |||
| identifying the organization using a domain name to instill | ||||
| consumer trust, or contacting that organization to raise a | ||||
| customer complaint to them or file a complaint about them. | ||||
| -----END FORM----- | -----END FORM----- | |||
| -----BEGIN FORM----- Value: dnsTransparency Description: Tasks within | -----BEGIN FORM----- | |||
| the scope of this purpose involve querying the registration data made | ||||
| public by registrants to satisfy a wide variety of use cases around | Value: businessDomainNamePurchaseOrSale | |||
| informing the general public. -----END FORM----- | ||||
| Description: Tasks within the scope of this purpose include making | ||||
| purchase queries about a domain name, acquiring a domain name from | ||||
| a registrant, and enabling due diligence research. | ||||
| -----END FORM----- | ||||
| -----BEGIN FORM----- | ||||
| Value: academicPublicInterestDNSRResearch | ||||
| Description: Tasks within the scope of this purpose include | ||||
| academic public interest research studies about domain names | ||||
| published in the registration data service, including public | ||||
| information about the registrant and designated contacts, the | ||||
| domain name's history and status, and domain names registered by a | ||||
| given registrant (reverse query). | ||||
| -----END FORM----- | ||||
| -----BEGIN FORM----- | ||||
| Value: legalActions | ||||
| Description: Tasks within the scope of this purpose include | ||||
| investigating possible fraudulent use of a registrant's name or | ||||
| address by other domain names, investigating possible trademark | ||||
| infringement, contacting a registrant/licensee's legal | ||||
| representative prior to taking legal action and then taking a | ||||
| legal action if the concern is not satisfactorily addressed. | ||||
| -----END FORM----- | ||||
| -----BEGIN FORM----- | ||||
| Value: regulatoryAndContractEnforcement | ||||
| Description: Tasks within the scope of this purpose include tax | ||||
| authority investigation of businesses with online presence, | ||||
| Uniform Dispute Resolution Policy (UDRP) investigation, | ||||
| contractual compliance investigation, and registration data escrow | ||||
| audits. | ||||
| -----END FORM----- | ||||
| -----BEGIN FORM----- | ||||
| Value: criminalInvestigationAndDNSAbuseMitigation | ||||
| Description: Tasks within the scope of this purpose include | ||||
| reporting abuse to someone who can investigate and address that | ||||
| abuse, or contacting entities associated with a domain name during | ||||
| an offline criminal investigation. | ||||
| -----END FORM----- | ||||
| -----BEGIN FORM----- | ||||
| Value: dnsTransparency | ||||
| Description: Tasks within the scope of this purpose involve | ||||
| querying the registration data made public by registrants to | ||||
| satisfy a wide variety of use cases around informing the general | ||||
| public. | ||||
| -----END FORM----- | ||||
| 9. Implementation Status | 9. Implementation Status | |||
| NOTE: Please remove this section and the reference to RFC 7942 prior | NOTE: Please remove this section and the reference to RFC 7942 prior | |||
| to publication as an RFC. | to publication as an RFC. | |||
| This section records the status of known implementations of the | This section records the status of known implementations of the | |||
| protocol defined by this specification at the time of posting of this | protocol defined by this specification at the time of posting of this | |||
| Internet-Draft, and is based on a proposal described in RFC 7942 | Internet-Draft, and is based on a proposal described in RFC 7942 | |||
| [RFC7942]. The description of implementations in this section is | [RFC7942]. The description of implementations in this section is | |||
| skipping to change at page 26, line 23 ¶ | skipping to change at page 27, line 22 ¶ | |||
| It is up to the individual working groups to use this information as | It is up to the individual working groups to use this information as | |||
| they see fit". | they see fit". | |||
| Version -09 of this specification introduced changes that are | Version -09 of this specification introduced changes that are | |||
| incompatible with earlier implementations. Implementations that are | incompatible with earlier implementations. Implementations that are | |||
| consistent with this specification will be added as they are | consistent with this specification will be added as they are | |||
| identified. | identified. | |||
| 9.1. Editor Implementation | 9.1. Editor Implementation | |||
| * Location: https://procuratus.net/rdap/ | Location: https://procuratus.net/rdap/ | |||
| * Description: This implementation is a functionally-limited RDAP | Description: This implementation is a functionally-limited RDAP | |||
| server that supports only the path segments described in this | server that supports only the path segments described in this | |||
| specification. It uses the "jumbojett/OpenID-Connect-PHP" library | specification. It uses the "jumbojett/OpenID-Connect-PHP" library | |||
| found on GitHub, which appears to no longer be under active | found on GitHub, which appears to no longer be under active | |||
| development. The library was modified to add support for the | development. The library was modified to add support for the | |||
| device authorization grant. Session variable management is still | device authorization grant. Session variable management is still | |||
| a little buggy. Supported OPs include Google (Gmail) and Yahoo. | a little buggy. Supported OPs include Google (Gmail) and Yahoo. | |||
| * Level of Maturity: This is a "proof of concept" research | Level of Maturity: This is a "proof of concept" research | |||
| implementation. | implementation. | |||
| * Coverage: This implementation includes all of the features | Coverage: This implementation includes all of the features | |||
| described in this specification. | described in this specification. | |||
| * Version compatibility: Version -11 of this specification. | Version compatibility: Version -11+ of this specification. | |||
| * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com | Contact Information: Scott Hollenbeck, shollenbeck@verisign.com | |||
| 9.2. Verisign Labs | 9.2. Verisign Labs | |||
| * Responsible Organization: Verisign Labs | Responsible Organization: Verisign Labs | |||
| * Location: https://rdap.verisignlabs.com/ | Location: https://rdap.verisignlabs.com/ | |||
| * Description: This implementation includes support for domain | Description: This implementation includes support for domain | |||
| registry RDAP queries using live data from the .cc and .tv country | registry RDAP queries using live data from the .cc and .tv country | |||
| code top-level domains and the .career generic top-level domain. | code top-level domains and the .career generic top-level domain. | |||
| Three access levels are provided based on the authenticated | Three access levels are provided based on the authenticated | |||
| identity of the client: | identity of the client: | |||
| 1. Unauthenticated: Limited information is returned in response | 1. Unauthenticated: Limited information is returned in response | |||
| to queries from unauthenticated clients. | to queries from unauthenticated clients. | |||
| 2. Basic: Clients who authenticate using a publicly available | 2. Basic: Clients who authenticate using a publicly available | |||
| identity provider like Google Gmail or Microsoft Hotmail will | identity provider like Google Gmail or Microsoft Hotmail will | |||
| receive all of the information available to an unauthenticated | receive all of the information available to an unauthenticated | |||
| client plus additional registration metadata, but no | client plus additional registration metadata, but no | |||
| personally identifiable information associated with entities. | personally identifiable information associated with entities. | |||
| 3. Advanced: Clients who authenticate using a more restrictive | 3. Advanced: Clients who authenticate using a more restrictive | |||
| identity provider will receive all of the information | identity provider will receive all of the information | |||
| available to a Basic client plus whatever information the | available to a Basic client plus whatever information the | |||
| server operator deems appropriate for a fully authorized | server operator deems appropriate for a fully authorized | |||
| client. Currently supported identity providers include those | client. Currently supported identity providers include those | |||
| developed by Verisign Labs | developed by Verisign Labs | |||
| (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC | (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC | |||
| (https://www.mojeid.cz/). | (https://www.mojeid.cz/). | |||
| * Level of Maturity: This is a "proof of concept" research | Level of Maturity: This is a "proof of concept" research | |||
| implementation. | implementation. | |||
| * Coverage: This implementation includes all of the features | Coverage: This implementation includes all of the features | |||
| described in this specification. | described in this specification. | |||
| * Version compatibility: Version -07 of this specification. | Version compatibility: Version -07 of this specification. | |||
| * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com | Contact Information: Scott Hollenbeck, shollenbeck@verisign.com | |||
| 9.3. Viagenie | 9.3. Viagenie | |||
| * Responsible Organization: Viagenie | Responsible Organization: Viagenie | |||
| * Location: https://auth.viagenie.ca | Location: https://auth.viagenie.ca | |||
| * Description: This implementation is an OpenID identity provider | Description: This implementation is an OpenID identity provider | |||
| enabling users and registries to connect to the federation. It | enabling users and registries to connect to the federation. It | |||
| also includes a barebone RDAP client and RDAP server in order to | also includes a barebone RDAP client and RDAP server in order to | |||
| test the authentication framework. Various level of purposes are | test the authentication framework. Various level of purposes are | |||
| available for testing. | available for testing. | |||
| * Level of Maturity: This is a "proof of concept" research | Level of Maturity: This is a "proof of concept" research | |||
| implementation. | implementation. | |||
| * Coverage: This implementation includes most features described in | Coverage: This implementation includes most features described in | |||
| this specification as an identity provider. | this specification as an identity provider. | |||
| * Version compatibility: Version -07 of this specification. | Version compatibility: Version -07 of this specification. | |||
| * Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca | Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca | |||
| 10. Security Considerations | 10. Security Considerations | |||
| Security considerations for RDAP can be found in RFC 7481 [RFC7481]. | Security considerations for RDAP can be found in RFC 7481 [RFC7481]. | |||
| Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 | Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 | |||
| [RFC6749] can be found in their reference specifications. OpenID | [RFC6749] can be found in their reference specifications. OpenID | |||
| Connect defines optional mechanisms for robust signing and encryption | Connect defines optional mechanisms for robust signing and encryption | |||
| that can be used to provide data integrity and data confidentiality | that can be used to provide data integrity and data confidentiality | |||
| services as needed. | services as needed. | |||
| skipping to change at page 31, line 32 ¶ | skipping to change at page 32, line 32 ¶ | |||
| 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 local 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 | ||||
| formatting changes due to a move to xml2rfc-v3 markup. | ||||
| 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. 56 change blocks. | ||||
| 150 lines changed or deleted | 216 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/ | ||||