Farrell Folly started work on this review of RFC 7481. I've collected his findings and completed the review. Section 3.1, Access Control: "Information returned to a client can be clearly marked with a status value (see Section 10.2.2 of [RFC7483]) that identifies the access granted to the client." Possible requirement: An RDDS must be able to return information that identifies the access granted to the client. Associated charter question(s): Users/Purposes: Who should have access to gTLD registration data and why? Gated Access: What steps should be taken to control data access for each user/purpose? Section 3.2, Authentication: "RDAP clients and servers MUST implement the authentication framework specified in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]." "If the "basic" scheme is used, HTTP over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while in transit..." "Servers MUST support either Basic or Digest authentication; they are not required to support both. Clients MUST support both to interoperate with servers that support one or the other." "transports for RDAP must either provide a TLS-protected transport (e.g., HTTPS) or a mechanism that provides an equivalent level of server authentication" Possible requirement: An RDDS must be able to support client authentication using HTTP Basic and Digest authentication. Possible requirement: Connections between RDDS clients and RDDS servers must be encrypted to prevent inadvertent disclosure of information to passive eavesdropping attacks. Possible requirement: RDDS servers must be able to authenticate themselves to clients using HTTPS or a mechanism that provides an equivalent level of server authentication. Associated charter question(s): Gated Access: What steps should be taken to control data access for each user/purpose? Privacy: What steps are needed to protect data and privacy? Section 3.2.1, Federated Authentication: "Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP" Possible requirement: Federated authentication systems used by an RDDS must be fully supported by HTTP. Associated charter question(s): Gated Access: What steps should be taken to control data access for each user/purpose? Privacy: What steps are needed to protect data and privacy? Section 3.3, Authorization: "If such varying degrees of access are supported, an RDAP server MUST provide granular access controls (that is, per registration data object) in order to implement authorization policies." Possible requirement: An RDDS must provide granular access controls in order to implement authorization policies. Associated charter question(s): Gated Access: What steps should be taken to control data access for each user/purpose? Privacy: What steps are needed to protect data and privacy? Section 3.5, Data Confidentiality "HTTP over TLS MUST be used to protect all client-server exchanges unless operational constraints make it impossible to meet this requirement." Possible requirement: An RDDS must use HTTP over TLS to protect all client-server exchanges. Section 3.6, Data Integrity: "If the policy of the server operator requires message integrity for client-server data exchanges, HTTP over TLS MUST be used to protect those exchanges." Possible requirement: An RDDS must be able to provide message integrity for client-server data exchanges using HTTP over TLS. Associated charter question(s): Privacy: What steps are needed to protect data and privacy? Data Accuracy: What steps should be taken to improve data accuracy? Section 4, Privacy Threats Associated with Registration Data: "RDAP data structures allow servers to indicate via status values when data returned to clients has been made private, redacted, obscured, or registered by a proxy." Possible requirement: An RDDS must be able to identify data elements that has been made private, redacted, obscured, or registered by a proxy. Associated charter question(s): Privacy: What steps are needed to protect data and privacy? Scott