--- 1/draft-ietf-regext-rdap-openid-06.txt 2021-06-28 06:13:53.723463567 -0700 +++ 2/draft-ietf-regext-rdap-openid-07.txt 2021-06-28 06:13:53.775464862 -0700 @@ -1,19 +1,19 @@ REGEXT Working Group S. Hollenbeck Internet-Draft Verisign Labs -Intended status: Standards Track January 5, 2021 -Expires: July 9, 2021 +Intended status: Standards Track 28 June 2021 +Expires: 30 December 2021 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect - draft-ietf-regext-rdap-openid-06 + draft-ietf-regext-rdap-openid-07 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,81 +31,80 @@ 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 July 9, 2021. + This Internet-Draft will expire on 30 December 2021. Copyright Notice Copyright (c) 2021 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 and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + 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 + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4 3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5 3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. RDAP Authentication and Authorization Steps . . . . . 6 3.1.3.1. Provider Discovery . . . . . . . . . . . . . . . 6 3.1.3.2. Authentication Request . . . . . . . . . . . . . 6 3.1.3.3. End-User Authorization . . . . . . . . . . . . . 7 3.1.3.4. Authorization Response and Validation . . . . . . 7 3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 7 - 3.1.3.6. Delivery of User Information . . . . . . . . . . 7 + 3.1.3.6. Delivery of User Information . . . . . . . . . . 8 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 8 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9 - 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9 + 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 4.1. Client Authentication Request and Response . . . . . . . 10 4.2. Token Request and Response . . . . . . . . . . . . . . . 10 - 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 11 + 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 12 4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14 - 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14 + 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 15 4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15 - 5. Clients with Limited User Interfaces . . . . . . . . . . . . 15 + 5. Clients with Limited User Interfaces . . . . . . . . . . . . 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 + 6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8.1. Authentication and Access Control . . . . . . . . . . . . 22 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 24 - 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 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 @@ -281,21 +280,26 @@ protocol. The Implicit Flow is more commonly used by clients implemented in a web browser using a scripting language; it is 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]. Other parameters MAY be included. + 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" from the query + component of the end user's RDAP request. Passing "login_hint" + 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 @@ -373,49 +377,50 @@ Value strings contain at least one character and no more than 64 characters. Description: a one- or two-sentence description of the meaning of the purpose value, how it might be used, and/or how it should be interpreted by clients and servers. This registry is operated under the "Specification Required" policy defined in RFC 5226 ([RFC5226]). The set of initial values used to populate the registry as described in Section 6.3 are taken from the - final report [1] produced by the Expert Working Group on gTLD + final report (https://www.icann.org/en/system/files/files/final- + report-06jun14-en.pdf) produced by the Expert Working Group on gTLD Directory Services chartered by the Internet Corporation for Assigned Names and Numbers (ICANN). 3.1.4.2. Do Not Track There are also communities of RDAP users and operators who wish to make and validate claims about a user's wish to not have their queries logged, tracked, or recorded. For example, a law enforcement agent may wish to be able to assert that their queries are part of a criminal investigation and should not be tracked due to a risk of query exposure compromising the investigation, and a server operator will need to be able to receive and validate that claim. These needs can be met by defining and using an additional "do not track" claim. The "do not track" ("dnt") claim can be used to identify an End-User that is authorized to perform queries without the End-User's association with those queries being logged, tracked, or recorded by the server. Client use of the "dnt" claim is OPTIONAL. Server operators MUST NOT log, track, or record any association of the query and the End-User's identity if the End-User is successfully - identified and authorized, the "dnt" claim is present, and the value - of the claim is "true". + identified and authorized, the "dnt" claim is present, the value of + the claim is "true", and accepting the claim complies with local + regulations regarding logging and tracking. The "dnt" value is represented as a JSON boolean literal. An example: {"dnt" : true} - No special query tracking processing is required if this claim is not present or if the value of the claim is "false". Use of this claim MUST be limited to End-Users who are granted "do not track" priviliges in accordance with service policies and regulations. Specification of these policies and regulations is beyond the scope of this document. 4. Protocol Parameters This specification adds the following protocol parameters to RDAP: @@ -518,22 +520,21 @@ A refresh token is requested using a "tokens" path segment and two query parameters. The first query parameter includes a key value of "id" and a value component that contains the client identifier issued by an OP. The second query parameter includes a key value of "refresh" and a value component of "true". A value component of "false" MUST be processed to return a result that is consistent with not including a "refresh" parameter at all as described in Section 4.2. An example using "refresh=true": - https://example.com/rdap/tokens?id=user.idp.example - &refresh=true + https://example.com/rdap/tokens?id=user.idp.example&refresh=true The response to this query MUST contain all of the response elements described in Section 4.2. In addition, the response MUST contain a name-value pair that represents a refresh token. The name-value pair includes a key value of "refresh_token" and a Base64url-encoded value that represents the refresh token. Example refresh token request response (the encoded tokens have been abbreviated for clarity): @@ -548,22 +549,22 @@ Figure 2 Once acquired, a refresh token can be used to refresh an access token. An access token is refreshed using a "tokens" path segment and two query parameters. The first query parameter includes a key value of "id" and a value component that contains the client identifier issued by an OP. The second query parameter includes a key value of "refresh_token" and a Base64url-encoded value that represents the refresh token. An example: - https://example.com/rdap/tokens?id=user.idp.example - &refresh_token=eyJ0...f3jE + https://example.com/rdap/ + tokens?id=user.idp.example&refresh_token=eyJ0...f3jE In addition to any core RDAP response elements, the response to this query MUST contain four name-value pairs, in any order, representing a returned Refresh Token and Access Token. The Refresh Token is represented using a key value of "refresh_token". The Access Token is represented using a key value of "access_token". The access token type is represented using a key value of "token_type" and a value of "bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749 [RFC6749]. The lifetime of the access token is represented using a key value of "expires_in" and a numerical value that describes the @@ -586,23 +587,22 @@ Access and refresh tokens can be revoked as described in RFC 7009 [RFC7009] by sending a request to an RDAP server that contains a "tokens/revoke" path segment and two query parameters. The first query parameter includes a key value of "id" and a value component that contains the client identifier issued by an OP. The second query parameter includes a key value of "token" and a Base64url- encoded value that represents either the current refresh token or the associated access token. An example: - https://example.com/rdap/tokens/revoke?id=user.idp.example - &token=f735...d30c - + https://example.com/rdap/tokens/ + revoke?id=user.idp.example&token=f735...d30c Note that this command will revoke both access and refresh tokens at the same time. In addition to any core RDAP response elements, the response to this query MUST contain a description of the result of processing the revocation request within the RDAP "notices" data structure. Example token revocation success: "notices" : [ @@ -698,23 +698,24 @@ "rdap_openidc_level_0" ] Figure 6 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. + command line user interface such as curl (http://curl.haxx.se/) or + wget (https://www.gnu.org/software/wget/). 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 Authorization Grant 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. @@ -739,72 +740,71 @@ Here are two examples using the curl and wget utilities. Start by authenticating with the OP: https://example.com/rdap/tokens?id=user.idp.example Save the token information and pass it to the RP along with the URI representing the RDAP query. Using curl (encoded tokens have been abbreviated for clarity: - curl -H "Authorization: Bearer eyJ0...NiJ9"\ - -k https://example.com/rdap/domain/example.com\ - ?id_token=eyJ0...EjXk + curl -H "Authorization: Bearer eyJ0...NiJ9"\-k + https://example.com/rdap/domain/example.com\?id_token=eyJ0...EjXk - curl -k https://example.com/rdap/domain/example.com\ - ?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 + curl -k https://example.com/rdap/domain/ + example.com\?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 Using wget: - wget --header="Authorization: Bearer eyJ0...NiJ9"\ - https://example.com/rdap/domain/example.com\ - ?id_token=eyJ0...EjXk + wget --header="Authorization: Bearer + eyJ0...NiJ9"\https://example.com/rdap/domain/ + example.com\?id_token=eyJ0...EjXk - wget https://example.com/rdap/domain/example.com\ - ?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 + wget https://example.com/rdap/domain/ + example.com\?id_token=eyJ0...EjXk&access_token=eyJ0...NiJ9 Refresh tokens can be useful to automated or command line clients who wish to continue a session without explicitly re-authenticating an end user. See Section 4.3 for more information. 6. IANA Considerations 6.1. RDAP Extensions Registry IANA is requested to register the following value in the RDAP Extensions Registry: - Extension identifier: rdap_openidc_level_0 - Registry operator: Any - Published specification: This document. - Contact: IESG - Intended usage: This extension describes a federated + * Extension identifier: rdap_openidc_level_0 + * Registry operator: Any + * Published specification: This document. + * Contact: IESG + * Intended usage: This extension describes a federated authentication method for RDAP using OAuth 2.0 and OpenID Connect. 6.2. JSON Web Token Claims Registry IANA is requested to register the following values in the JSON Web Token Claims Registry: - Claim Name: "purpose" - Claim Description: This claim describes the stated purpose for + * Claim Name: "purpose" + * Claim Description: This claim describes the stated purpose for submitting a request to access a protected RDAP resource. - Change Controller: IESG - Specification Document(s): Section 3.1.4.1 of this document. + * Change Controller: IESG + * Specification Document(s): Section 3.1.4.1 of this document. - Claim Name: "dnt" - Claim Description: This claim contains a JSON boolean literal that + * Claim Name: "dnt" + * Claim Description: This claim contains a JSON boolean literal that describes an End-User's "do not track" preference for identity tracking, logging, or recording when accessing a protected RDAP resource. - Change Controller: IESG - Specification Document(s): Section 3.1.4.2 of this document. + * Change Controller: IESG + * Specification Document(s): Section 3.1.4.2 of this document. 6.3. RDAP Query Purpose Registry IANA is requested to create a new protocol registry to manage RDAP query purpose values. This registry should appear under its own heading on IANA's protocol listings, using the same title as the name of the registry. The information to be registered and the procedures to be followed in populating the registry are described in Section 3.1.4.1. @@ -825,109 +825,90 @@ Required information: See Section 3.1.4.1. Review process: "Specification Required" as described in RFC 5226 [RFC5226]. Size, format, and syntax of registry entries: See Section 3.1.4.1. Initial assignments and reservations: - -----BEGIN FORM----- - Value: domainNameControl - Description: Tasks within the scope of this purpose include creating - and managing and monitoring a registrant's own domain 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. - -----END FORM----- + -----BEGIN FORM----- Value: domainNameControl Description: Tasks + within the scope of this purpose include creating and managing and + monitoring a registrant's own domain 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. -----END FORM----- - -----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. + -----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----- - -----BEGIN FORM----- - Value: technicalIssueResolution - Description: Tasks within the scope of this purpose include (but are - not limited to) working to resolve technical issues, including email - delivery issues, DNS resolution failures, and web site functional - issues. + -----BEGIN FORM----- Value: technicalIssueResolution Description: + Tasks within the scope of this purpose include (but are not limited + to) working to resolve technical issues, including email delivery + issues, DNS resolution failures, and web site functional issues. -----END FORM----- - -----BEGIN FORM----- - Value: domainNameCertification - 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. - -----END FORM----- + -----BEGIN FORM----- Value: domainNameCertification 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. -----END FORM----- - -----BEGIN FORM----- - Value: individualInternetUse - 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----- + -----BEGIN FORM----- Value: individualInternetUse 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----- - -----BEGIN FORM----- - Value: businessDomainNamePurchaseOrSale + -----BEGIN FORM----- Value: businessDomainNamePurchaseOrSale 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----- + registrant, and enabling due diligence research. -----END FORM----- - -----BEGIN FORM----- - Value: academicPublicInterestDNSRResearch + -----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----- + 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 + -----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. + -----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----- + -----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----- 7. Implementation Status NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 [RFC7942]. The description of implementations in this section is @@ -942,28 +923,27 @@ According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 7.1. Verisign Labs - Responsible Organization: Verisign Labs - Location: https://rdap.verisignlabs.com/ - Description: This implementation includes support for domain + * Responsible Organization: Verisign Labs + * Location: https://rdap.verisignlabs.com/ + * Description: This implementation includes support for domain registry RDAP queries using live data from the .cc and .tv country code top-level domains and the .career generic top-level domain. Three access levels are provided based on the authenticated identity of the client: - 1. Unauthenticated: Limited information is returned in response to queries from unauthenticated clients. 2. Basic: Clients who authenticate using a publicly available identity provider like Google Gmail or Microsoft Hotmail will receive all of the information available to an unauthenticated client plus additional registration metadata, but no personally identifiable information associated with entities. 3. Advanced: Clients who authenticate using a more restrictive identity provider will receive all of the information available to a Basic client plus whatever information the @@ -965,40 +945,40 @@ client plus additional registration metadata, but no personally identifiable information associated with entities. 3. Advanced: Clients who authenticate using a more restrictive identity provider will receive all of the information available to a Basic client plus whatever information the server operator deems appropriate for a fully authorized client. Currently supported identity providers include those developed by Verisign Labs (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC (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. - Coverage: This implementation includes all of the features + * Coverage: This implementation includes all of the features described in this specification. - Contact Information: Scott Hollenbeck, shollenbeck@verisign.com + * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 7.2. Viagenie - Responsible Organization: Viagenie - Location: https://auth.viagenie.ca - Description: This implementation is an OpenID identity provider + * Responsible Organization: Viagenie + * Location: https://auth.viagenie.ca + * Description: This implementation is an OpenID identity provider enabling users and registries to connect to the federation. It also includes a barebone RDAP client and RDAP server in order to test the authentication framework. Various level of purposes are available for testing. - Level of Maturity: This is a "proof of concept" research + * Level of Maturity: This is a "proof of concept" research implementation. - Coverage: This implementation includes most features described in + * Coverage: This implementation includes most features described in this specification as an identity provider. - Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca + * Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca 8. Security Considerations Security considerations for RDAP can be found in RFC 7481 [RFC7481]. Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 [RFC6749] can be found in their reference specifications. OpenID Connect defines optional mechanisms for robust signing and encryption that can be used to provide data integrity and data confidentiality services as needed. Security services for ID Tokens and Access Tokens (with references to the JWT specification) are described in @@ -1012,26 +992,26 @@ policy. For example, a client who provides an email address (and nothing more) might be entitled to receive a subset of the information that would be available to a client who provides an email address, a full name, and a stated purpose. Development of these access control policies is beyond the scope of this document. 9. Acknowledgements The author would like to acknowledge the following individuals for their contributions to the development of this document: Tom - Harrison, Russ Housley, Rhys Smith, Jaromir Talir, and Alessandro - 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. + Harrison, Russ Housley, Mario Loffredo, Rhys Smith, Jaromir Talir, + and Alessandro 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 [OIDC] OpenID Foundation, "OpenID Connect", . [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating errata set 1", November 2014, @@ -1079,27 +1059,27 @@ Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the - Registration Data Access Protocol (RDAP)", RFC 7480, - DOI 10.17487/RFC7480, March 2015, + Registration Data Access Protocol (RDAP)", STD 95, + RFC 7480, DOI 10.17487/RFC7480, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the - Registration Data Access Protocol (RDAP)", RFC 7481, - DOI 10.17487/RFC7481, March 2015, + Registration Data Access Protocol (RDAP)", STD 95, + RFC 7481, DOI 10.17487/RFC7481, March 2015, . [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, . [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, DOI 10.17487/RFC7483, March 2015, @@ -1131,46 +1111,40 @@ [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, . -10.3. URIs - - [1] https://www.icann.org/en/system/files/files/final-report- - 06jun14-en.pdf - - [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. 03: Updated OAuth 2.0 Device Authorization Grant description and reference due to publication of RFC 8628. 04: Updated OAuth 2.0 token exchange description and reference due to publication of RFC 8693. Corrected the RDAP conformance identifier to be registered with IANA. 05: Keepalive refresh. 06: Keepalive refresh. + 07: Added "login_hint" description to Section 3.1.3.2. Added some + text to Section 3.1.4.2 to note that "do not track" requires + compliance with local regulations. Author's Address Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 - USA + United States of America Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/