Org Assumptions

Liaison Response

Recommendation 1.4.3 states that the Accreditation Authority “MUST validate Identity Credentials and Signed Assertions, in addition to the information contained in the request, facilitate the decision to accept or reject the Authorization of an SSAD request.” ICANN org interprets it to mean that the “request” mentioned in this recommendation refers to the accreditation request, and not the nonpublic registration data request. Please confirm that our understanding is correct.

Yes. Rec 1 describes accreditation process

Recommendation 13.1.4 states that the Central Gateway Manager “MUST respond only to requests for a specific domain name…” whereas the Recommendation 13.3.2 states that the CGM “MUST support the ability of a Requestor to submit multiple domain names in a single request.” Implementation Guidance 13.5 also states “it must be possible for Requestors to submit multiple requests at the same time.” Recommendation 13.1.4 could be interpreted to be in conflict with Recommendation 13.3.2 and Implementation Guidance 13.5 in terms of how many disclosure requests can be included in a single request. 

ICANN org’s interpretation is that a single request can contain disclosure requests for multiple domain names as long as all the domain names are individually specified in a fully qualified format. In other words, the Central Gateway Manager should not allow any sort of “catch all” requests, such as a request concerning all domain names that have “apple” in the name, or that are owned by a particular registrant. Please confirm that our understanding is correct.

Yes.

There isn’t contradiction. Multiple name request option should facilitate SSAD work, but multiple should be “reasonable”. It should be determined at the initial stage of implementation, and possibly corrected as a result of experience gained by operating SSAD.

Recommendation 10.14 states that “Response Targets and Compliance Targets MUST be reviewed, at a minimum, after every six months in the first year, thereafter annually (depending on the outcome of the first review).” ICANAN org’s interpretation of this recommendation is that such a review is expected to be done across all contracted parties and not review individual contracted parties. This review is meant to be conducted by the GNSO Standing Committee. 

Yes. In light of 18.2.2

Recommendations 13.3.6 states that the “SSAD MUST be able to save the history of the different disclosure requests…” ICANN org’s interpretation is that this recommendation applies to not only the Central Gateway Manager, but also to other parties, such as the Accreditation Authorities and the Contracted Parties. Please confirm that our understanding is correct.

Rec 13 specifically describes Query policy where both CGM and CP are involved.

Rec 15 requires logging (and saving) info on Accreditation.

Recommendation 14.2 states that “Requestors of the SSAD data should primarily bear the costs of maintaining this system,” whereas the Recommendation 14.4 states that the “SSAD SHOULD NOT be considered a profit-generating platform for ICANN or the contracted parties. Funding for the SSAD should be sufficient to cover costs…” ICANN org’s interpretation of these recommendations is that the SSAD user fees should cover the operating cost of only the Accreditation Authorities, Identity Providers, and Central Gateway Manager, and does not cover any  costs that contracted parties may incur. Please confirm that our understanding is correct.

One should separate development and running costs of SSAD.

Running costs consist of accreditation and query. These also can be separated.

Query costs should be predominantly covered by requestors and not be source of profit neither by ICANN Org or CPs. Hence, fees should cover cost of both involved, but be reasonable. ICANN and CPs may decide to subsidize SSAD running activity as it is part of smooth functioning of DNS.

May be mentioned in webinar

Recommendation 2 lays out the requirements for governmental accreditation authorities, but it does not indicate whether government entities requiring access to non-public gTLD registration data may only be accredited via these governmental accreditation authorities. Footnote 13 seems to limit the Intergovernmental Organizations (IGOs) to only use the hosting country’s Accreditation Authority. ICANN org’s interpretation is that governmental entities are required to use an Accreditation Authority from their country/territory. This means, if there are no such Accreditation Authorities established within their country/territory, those entities cannot be accredited via the Accreditation Authority that is to be established for non-governmental entities. Please confirm that our understanding is correct.

Yes, it is right. Governments either can organize accreditation within their jurisdiction, or pool resources and entrust an IGO to organize it for number of countries.

Nevertheless, there should be full technical compatibility of respective accreditation systems.

Recommendations 7.1.1 states that “Requestors MAY also submit data verification requests on the basis of Registered Name Holder (RNH) consent that has been obtained by the Requestor (and is at the sole responsibility of that Requestor), for example to validate the RNH’s claim of ownership of a domain name registration, or contract with the Requestor.” ICANN org’s interpretation is that the given the parenthetical of “and is at the sole responsibility of that Requestor.” Please confirm that our understanding is correct.

Not sure what is meant by “request on the basis of RNH consent is automatically approved”.

Requestor needs to provide Identity Credential and Signed Assertions. If accepted, requestor can submit query.