The purpose of this document is to carry out Task 8 of the RDS PDP WG Phase 1 work plan . As noted in that plan, the bulk of the WG’s work will involve recommending requirements for registration directory services.

Recognizing that the Board recommended that the EWG Final Report should be the starting point for this PDP and that EWG efforts, although not policy development, were very comprehensive with extensive and thorough consideration of public input, this document identifies possible requirements for registration data and directory services from the EWG Final Report along with possible requirements obtained from additional Key Inputs such as the sources identified by input-gathering sub-teams on Data, Purpose and Privacy and in the PDP Issue Report , and possible requirements suggested by SG/C/SO/AC Inputs and WG Members .

After possible requirements are gathered into a comprehensive and inclusive list, which is compiled without debate on the merits of each of the possible requirements, the WG will design a very systematic approach to maximize efficiency in discussing and attempting to reach consensus on recommended requirements for registration directory services. These requirements will help the WG reach an informed decision about if and why a next-generation system is needed to replace today’s WHOIS system.

Organization

The possible requirements listed in this document are organized as follows:

  1. Possible Requirements that map to one or more of the eleven (11) questions in the charter. Note that the same requirement may address multiple questions.
  2. Possible Requirements that may not map to any question identified in the charter.
  3. Possible Foundational Questions that must be answered based on all other requirements.

As stated above, all of the possible requirements in this document are derived from cited Key Input documents (listed in Annex A), supplemented by any additional possible requirements suggested by WG members or SGs, Cs, SOs and ACs during outreach.

After the WG confirms that this list of possible requirements is sufficiently complete to serve as the foundation for WG deliberation, the WG should continue through its work plan until reaching Task 12 where it will systematically consider each possible requirement individually with the goal of trying to reach as strong a consensus as possible as to whether the WG supports the possible requirement , including how it is worded.

The grouping of the requirements into the 11 charter questions should not be seen as fixed. The WG should feel free to move possible requirements under different questions and even to include a given requirement under more than one question if that seems useful, as long as the duplication is noted.

The order of the possible requirements within the various sections in this document is primarily based on the order in which the 11 questions are posed in the WG’s charter. The WG may decide to change the order to provide a more useful presentation but this should be done with full consideration of the reasons why the order was established in the framework. Due to interdependencies, WG deliberation will likely be iterative, especially on fundamental questions pertaining to purpose, data, and privacy.

Numbering

Possible requirements are numbered using the notation [QQ-D#-R#] for ease of use and scalability as this list evolves. Specifically, “QQ” identifies the associated question as follows:

FQ Foundational Questions: Questions to be answered based on all other requirements

OQ Other Questions: Questions that may not fit within the 11 charter questions

UP Users/Purposes: Who should have access to gTLD registration data and why?

GA Gated Access: What steps should be taken to control data access for each user/purpose?

DA Data Accuracy: What steps should be taken to improve data accuracy?

DE Data Elements: What data should be collected, stored, and disclosed?

PR Privacy: What steps are needed to protect data and privacy?

CX Coexistence: What steps should be taken to enable coexistence ?

CM Compliance: What steps are needed to enforce these policies?

SM System Model: What system requirements must be satisfied by any implementation?

CS Cost: What costs will be incurred and how must they be covered?

BE Benefits: What benefits will be achieved and how will they be measured?

RI Risks: What risks do stakeholders face and how will they be reconciled?
 

This “QQ” will be followed by “D##” which identifies by number a key input document from Annex A.

Finally, “R##” sequentially numbers within each document all possible requirements. For example, [UP-D01-R03] is the third possible user/purpose requirement extracted from the EWG Final Report [01] , while [DE-D01-R04] is the fourth possible data element requirement taken from that same document.

Possible requirements are not necessarily quoted verbatim from key input documents, but rather phrased as needed to describe a possible requirement for gTLD registration directory services or registration data. In particular, possible fundamental requirements should not be specific to today’s WHOIS system or a next-generation replacement, since the goal is to enable WG deliberation and consensus as the basis for answering foundational questions posed by the WG charter.

Users/Purposes (UP)

The following possible requirements address the charter question on Users and Purposes (UP):
Who should have access to gTLD registration data & why?

The process framework for this question (below) can be applied to categorize possible requirements into three phases:

In the grid below, we identify the possible requirement for WG deliberation, any prerequisites or dependencies contained in that possible requirement , and whether the possible requirement therefore falls into Phase 1, 2, or 3. Policies designed to meet Phase 1 policy requirements should be considered in Phase 2 , while implementation or coexistence guidance for Phase 2 policies should be considered in Phase 3 . In addition, an initial attempt has been made to group similar requirements by code (C) and keyword (K) , allowing the table to be easily re-sorted or filtered – see Annex B for definitions.

QQ-D#-R#

Possible Requirement – USERS/PURPOSES

Prerequisites/Dependencies

Ph

C

K

[UP-D01-R01]

“In support of ICANN’s mission to coordinate the global Internet’s system of unique identifiers, and to ensure the stable and secure operation of the Internet’s unique identifier system, information about gTLD domain names is necessary to promote trust and confidence in the Internet for all stakeholders.” (p. 16, Section IIb, Purpose)

None

1

A

a

[UP-D01-R02]

“gTLD registration data [must be] collected, validated and disclosed for permissible purposes only.” (p. 21, p. 31 Principle 6)

None

1

A

a

[UP-D01-R03]

gTLD registration directory services must “accommodate in some manner all identified permissible purposes”, including the following users and permissible purposes. (pp. 21-25, 27-29)

Precedes [UP-D01-R04 to R14], Depends on Permissible Purposes, Permissible Users

1

A

a

[UP-D01-R04]

* Domain Name Control – “Creating, managing and monitoring a Registrant’s own domain name (DN), including creating the DN, updating information about the DN, transferring the DN, renewing the DN, deleting the DN, maintaining a DN portfolio, and detecting fraudulent use of the Registrant’s own contact information.”

Supports [UP-D01-R03]

1

EA

e

[UP-D01-R05]

* Personal Data Protection – “Identifying the accredited Privacy/Proxy Provider or Secure Protected Credential Approver associated with a DN and reporting abuse, requesting reveal, or otherwise contacting that Provider.”

Supports [UP-D01-R03]

1

D

g

[UP-D01-R06]

* Technical Issue Resolution – “Working to resolve technical issues associated with domain name use, including email delivery issues, DNS resolution failures, and website functional issues, by contacting technical staff responsible for handling these issues.”

Supports [UP-D01-R03]

1

DA

b

[UP-D01-R07]

* Domain Name Certification – “Certification Authority (CA) issuing an X.509 certificate to a subject identified by a domain name needing to confirm that the DN is registered to the certificate subject.”

Supports [UP-D01-R03]

1

A, BA

a, c

[UP-D01-R08]

* Individual Internet Use – “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.”

Supports [UP-D01-R03]

1

EA, DA

e, f

[UP-D01-R09]

* business Domain Name Purchase or Sale – “Making purchase queries about a DN, acquiring a DN from another Registrant, and enabling due diligence research.”

Supports [UP-D01-R03]

1

CA

j

[UP-D01-R10]

* Academic/Public-Interest DNS Research – “Academic public-interest research studies about domain names published in [gTLD registration directory services], including public information about the Registrant and designated contacts, the domain name’s history and status, and DNs registered by a given Registrant.”

Supports [UP-D01-R03]

1

CA

i

[UP-D01-R11]

* Legal Actions – “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. ”

Supports [UP-D01-R03]

1

CA

j

[UP-D01-R12]

* Regulatory and Contractual Enforcement – “Tax authority investigation of businesses with online presence, UDRP investigation, contractual compliance investigation, and registration data escrow audits.”

Supports [UP-D01-R03]

1

CA

i

[UP-D01-R13]

* Criminal Investigation & DNS Abuse Mitigation – “Reporting abuse to someone who can investigate and address that abuse, or contacting entities associated with a domain name during an offline criminal investigation.”

Supports [UP-D01-R03]

1

DA, CC

b, q

[UP-D01-R14]

* DNS Transparency – “Querying the registration data made public by Registrants to satisfy a wide variety of needs to inform the general public.”

Supports [UP-D01-R03]

1

BA

c

[UP-D01-R15]

* gTLD registration directory services must support active deterrence of known malicious activities to the extent other requirements are satisfied. (See paragraph c on page 25.)

None

1

DA

b

[UP-D01-R16]

“All purposes/contacts must be codified by policymakers through a defined process for adding, changing, or deleting purposes.” (p.37)

None

1

IA, F

d, h

[UP-D01-R17]

Since it is likely that further [permissible purposes] will be identified over time, any [gTLD registration directory service] must be designed with extensibility in mind.

None

1

A, F

a, h

[UP-D01-R18]

gTLD registration directory services must provide the “ability to determine all domains registered by a given entity (commonly referred to as Reverse WHOIS).” (p. 26)

Depends on Permissible Purposes involving this functionality

2

BA, EA

c, e

[UP-D01-R19]

gTLD registration directory services must provide the “The ability to determine historical domain name registration information (commonly referred to as WhoWas).”

Depends on Permissible Purposes involving this functionality

2

BA, CA

c, i

[UP-D01-R20]

ICANN must publish, in one place, a user-friendly policy describing the purpose and permissible uses of registration data, to clearly inform Registrants why this data is being collected and how it will be handled and used.

Depends on Permissible Purposes, Why data is collected, How data will be handled/ used, Policies to be defined in P2

3

A, IA

a, d

[UP-D01-R21]

There must be clearly defined permissible/impermissible uses of gTLD registration data and directory services.

None

1

IA

d

[UP-D01-R22]

gTLD registration directory services must support defined permissible purposes,
including uses that involve [UP-D01-R23 to R26]

Precedes [UP-D01-R23 to R26], Depends on Permissible Purposes

2

A

a

[UP-D01-R23]

* [Must support] Identifying the Registrant and contacts designated for a given purpose;

Supports [UP-D01-R22], Depends on Permissible Purposes involving this functionality

2

EA

e

[UP-D01-R24]

* [Must support] Communicating with contacts designated for a given purpose;

Supports [UP-D01-R22], Depends on Permissible Purposes involving this functionality

2

DA

f

[UP-D01-R25]

* [Must support] Using data published by Registries about Domain Names; and

Supports [UP-D01-R22], Depends on Permissible Purposes involving this functionality

2

BA

c

[UP-D01-R26]

* [Must support] Searching portions of registration data required for a given purpose.

Supports [UP-D01-R22], Depends on Permissible Purposes involving this functionality

2

BA

c

[UP-D01-R27]

gTLD registration directory services must be designed with the ability to accommodate new users and permissible purposes that are likely to emerge over time.

Precedes [UP-D01-R26 to R31]

1

F

h

[UP-D01-R28]

* An application process must be defined.

Supports [UP-D01-R27]

2

F

h

[UP-D01-R29]

* Applications must be reviewed against defined criteria.

Supports [UP-D01-R27]

2

F

h

[UP-D01-R30]

* Applications that pass review must be evaluated and approved by a multistakeholder review board as determined by a policy development process.

Supports [UP-D01-R27]

3

F

h

[UP-D01-R31]

* Approved applications must be added to the gTLD registration directory services privacy policy and scheduled for implementation periodically (e.g., quarterly, annually) as defined by policy.

Supports [UP-D01-R27], Depends on Policies to be defined in P2

3

F

h

[UP-D01-R33]

All permissible purposes must be mapped to specific contact data needed for that specific purpose. (p.36)

Depends on Permissible Purposes, Data Element PR(s) for Contacts

2

A

a

[UP-D01-R34]

gTLD registration directory services must meet contact data requirements associated with permissible purposes through the following principles 8-14 on pp. 35-36.

Precedes [UP-D01-R35 to R41], Depends on Permissible Purposes

1

A

a

[UP-D01-R35]

* Purpose-based contact data must be provided for every registered domain name which makes public the union of data elements that are mandatory. [See DE possible requirements.]

Supports [UP-D01-R34], Depends on Data Element PR(s) for Contacts

1

A

a

[UP-D01-R36]

* All mandatory purpose-based contact data must be syntactically accurate and operationally reachable to meet the needs of every codified permissible purpose.

Supports [UP-D01-R34], Depends on Data Accuracy PR(s) for Contacts

1

DA

f

[UP-D01-R37]

* During domain name registration, the Registrant must be informed of all permissible purposes and given an opportunity to publish contact data for each purpose, including replacing the Registrant’s contact data for any or all purposes.

Supports [UP-D01-R34], Depends on Data Element PR(s) for Contacts

1

EA

e

[UP-D01-R38]

* A domain name must not be activated (put into the global DNS) until valid contact data is provided for every applicable purpose.

Supports [UP-D01-R34], Depends on Data Accuracy PR(s) for Contacts

1

DA

f

[UP-D01-R39]

* If contact data becomes invalid for its designated purpose, a process that provides the Registrant with the ability to specify a new valid contact must ensue, allowing reasonable notification and time for update to occur. [See DA possible requirements].

Supports [UP-D01-R34], Depends on Data Element PR(s) for Contacts

1

DA

f

[UP-D01-R40]

* A process and policies must be developed enabling Registrant-designated contacts to opt-in/opt-out of having their data published as contacts for domain names, to support the rights of persons and entities to accept or reject responsibility for serving in specific roles for particular domain registrations.

Supports [UP-D01-R34], Depends on Data Element PR(s) for Contacts

2

A, IA

a, d

[UP-D01-R41]

* Any system for providing purpose-based contact data must be flexible and allow for new purposes and contact types to be created and published.

Supports [UP-D01-R34], Depends on Data Element PR(s) for Contacts

1

A, F

a, h

[UP-D01-R42]

gTLD registration directory services must allow registrants to optionally supply “designated administrative, technical, accredited Privacy/Proxy Provider, and business contacts” to be made accessible when appropriate for those specific purposes.

Depends on Permissible Purposes, Privacy PR(s) for P/P Providers

2

ID

g

[UP-D01-R43]

“. . . the [gTLD registration directory service] portal [must] make the definitions for every purpose-based contact type readily accessible to users (for example, using hover-over pop-up definitions) to clearly indicate that contacts are published to handle inquiries for permissible purposes, and that a point of contact must be designated to cover those purposes.” (p.57)

Depends on Permissible Purposes

2,3

A

a

[UP-D02-R01]

"There is a critical need for a policy asserting the purpose of collecting and maintaining registration data. This policy should address the operational concerns of the parties who collect, maintain or use this data as it relates to ICANN's remit."

None

1

IA

d

[UP-D02-R02]

"Law enforcement has a legitimate need to access the real identity of the responsible party(ies) for a domain name."

None

1

DA

b

[UP-D02-R03]

"Security practitioners have a legitimate need to access the real identity of those responsible for a domain name."

None

1

DA

b

[UP-D05-R01]

"The WHOIS protocol has no provisions for strong security. WHOIS lacks mechanisms for access control, integrity, and confidentiality. Accordingly, WHOIS-based services should only be used for information which is non-sensitive and intended to be accessible to everyone." (From Section 5: Security Considerations) This text implies that there should be a requirement to provide services for access control, integrity, and confidentiality. It also suggests that [gTLD registration directory services] should not be used to access sensitive information.

Same as [GA-D05-R01] [PR-D05-R01], Depends on Access PR(s) for Public Access

1,3

AB, EA, IA

u, l, d

[UP-D06-R01]

In providing query-based public access to registration data as required by [RAA] Subsections 3.3.1 and 3.3.4, Registrar shall not impose terms and conditions on use of the data provided, except as permitted by any Specification or Policy established by ICANN. Unless and until ICANN establishes a different Consensus Policy, Registrar shall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission by e-mail, telephone, postal mail, facsimile or other means of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient’s own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations.

Depends on Lawful Permissible Purposes

1

IA

d

[UP-D06-R02]

In the event that ICANN determines, following analysis of economic data by an economist(s) retained by ICANN (which data has been made available to Registrar), that an individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and services by third parties, Registrar shall provide third-party bulk access to the data subject to public access under [RAA] Subsection 3.3.1 under the following terms and conditions: [detailed in [UP-D06-R03 to R07]

Precedes [UP-D06-R03 to R07], Depends on Access PR(s) for Bulk Access

1

CA, BA

i, c

[UP-D06-R03]

* Registrar shall make a complete electronic copy of the data available at least one (1) time per week for download by third parties who have entered into a bulk access agreement with Registrar.

Supports [UP-D06-R02], Depends on Access PR(s) for Bulk Access

2,3

CA, BA

i, c

[UP-D06-R04]

* Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data.

Supports [UP-D06-R02], Depends on Access PR(s) for Bulk Access

2,3

CA, BA

i, c

[UP-D06-R05]

* Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support any marketing activities, regardless of the medium used. Such media include but are not limited to e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts

Supports [UP-D06-R02], Depends on Access PR(s) for Bulk Access

2

CA, BA

i, c

[UP-D06-R06]

* Registrar's access agreement shall require the third party to agree not to use the data to enable high-volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations.

Supports [UP-D06-R02], Depends on Access PR(s) for Bulk Access

2

EA, BA

I, c

[UP-D06-R07]

* Registrar's access agreement must require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties.

Supports [UP-D06-R02], Depends on Access PR(s) for Bulk Access

2

CA, BA

i, c

[UP-D06-R08]

From 3.3.7: To comply with applicable statutes and regulations and for other reasons, ICANN may adopt a Consensus Policy establishing limits (a) on the Personal Data concerning Registered Names that Registrar may make available to the public through a public-access service described in [RAA] Subsection 3.3 and (b) on the manner in which Registrar may make such data available. Registrar shall comply with any such Consensus Policy.

Access PR(s) for Public Access

2

IA

d

[UP-D06-R09]

Rights in Data. Registrar disclaims all rights to exclusive ownership or use of the data elements listed in [RAA] Subsections 3.2.1.1 through 3.2.1.3 for all Registered Names submitted by Registrar to the Registry Database for, or sponsored by Registrar in, each gTLD for which it is Accredited. Registrar does not disclaim rights in the data elements listed in [RAA] Subsections 3.2.1.4 through 3.2.1.6 and Subsections 3.3.1.3 through 3.3.1.8 concerning active Registered Names sponsored by it in each gTLD for which it is Accredited, and agrees to grant non-exclusive, irrevocable, royalty-free licenses to make use of and disclose the data elements listed in [RAA] Subsections 3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 for the purpose of providing a service or services (such as a Whois service under Subsection 3.3.4) providing interactive, query-based public access. Upon a change in sponsorship from Registrar of any Registered Name in each gTLD for which it is Accredited, Registrar acknowledges that the registrar gaining sponsorship shall have the rights of an owner to the data elements listed in [RAA] Subsections 3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 concerning that Registered Name, with Registrar also retaining the rights of an owner in that data. Nothing in this Subsection prohibits Registrar from (1) restricting bulk public access to data elements in a manner consistent with this Agreement and any Specifications or Policies or (2) transferring rights it claims in data elements subject to the provisions of this Subsection 3.5.

Depends on Access PR(s) for Public Access, Data Element PR(s) for collection of listed elements

2

EA

m

[UP-D06-R10]

From 3.7.7.7: Registrar shall agree that it will not process the Personal Data collected from the Registered Name Holder in a way incompatible with the purposes and other limitations about which it has provided notice to the Registered Name Holder in accordance with [RAA] Subsection 3.7.7.4.

Depends on Permissible Purposes, Data Element PR(s) for collection of Personal Data, Privacy PR(s) stating limitations

1

A

a

[UP-D06-R11]

Handling by ICANN of Registrar-Supplied Data. before receiving any Personal Data from Registrar, ICANN shall specify to Registrar in writing the purposes for and conditions under which ICANN intends to use the Personal Data. ICANN may from time to time provide Registrar with a revised specification of such purposes and conditions, which specification shall become effective no fewer than thirty (30) days after it is provided to Registrar. ICANN shall not use Personal Data provided by Registrar for a purpose or under conditions inconsistent with the specification in effect when the Personal Data was provided. ICANN shall take reasonable steps to avoid uses of the Personal Data by third parties inconsistent with the specification.

Depends on Permissible Purposes, Data Element PR(s) for collection of Personal Data, Privacy PR(s) stating conditions

2, 3

A

a

[UP-D07-R01]

From Specification 4, Section 1.10: "Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this [New gTLD Registry Agreement] section [as detailed in [UP-D07-R02 to R07]

Precedes [UP-D07-R02 to R07], Similar to [GA-D01-R19] [DE-D32-R04], Depends on Permissible Purposes involving this functionality

2

CA

i

[UP-D07-R02]

* From Section 1.10.1: Registry Operator will offer searchability on the web-based Directory Service.

Supports [UP`-D07-R01], Depends on Permissible Purposes involving this functionality

2

CA

i

[UP-D07-R03]

* From Section 1.10.2: Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.).

Supports [UP-D07-R01], Depends on Permissible Purposes involving this functionality

2

CA

i

[UP-D07-R04]

* From Section 1.10.3: Registry Operator will offer exact-match capabilities, at least, on the following fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records).

Supports [UP-D07-R01], Depends on Permissible Purposes involving this functionality

2

CA

i

[UP-D07-R05]

* From Section 1.10.4: Registry Operator will offer boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT.

Supports [UP-D07-R01], Depends on Permissible Purposes involving this functionality

2

CA

i

[UP-D07-R06]

* From Section 1.10.5: Search results will include domain names matching the search criteria.

Supports [UP-D07-R01], Depends on Permissible Purposes involving this functionality

2

CA

i

[UP-D07-R07]

* From Section 1.10.6: Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies.

Supports [UP-D07-R01], Depends on Permissible Purposes involving this functionality

2

CA

j

[UP-D08-R01]

[gTLD directory services must support] Legal Actions --- investigating possible legal claims arising from use of a domain name, including contacting registrant or its legal representative.

Variant of [UP-D01-R11]

1

A, IA

a, d

[UP-D08-R02]

[gTLD directory services must support] Providing a public record of domain name ownership, accessible by the public for any lawful use.

Variant of [UP-D01-R14]

1

A

a

[UP-D09-R01]

In Recommendations 2 -4, the WHOIS Policy Review Team (WHOIS RT) recommends that the ICANN board oversee the creation of a single [gTLD registration data] policy document, and reference it in subsequent versions of agreements with Contracted Parties. In doing so, ICANN should clearly document the current [and recommended next-generation?] gTLD WHOIS policy as set out in the gTLD Registry and Registrar contracts and GNSO Consensus Policies and Procedure.

Depends on Policies to be defined in P2

3

A

a

[UP-D13-R01]

based on the review of ICANN’s procedure for handling WHOIS conflicts with privacy law, the following User/Purpose-related requirements from past accreditation agreements are unchanged: Registrars must notify registrants of: 1) the purposes for the collection of any personal data, and 2) the intended recipients of the data.

Depends on Permissible Purposes, Permissible Users, Data Element PR(s)

1

DA

b

[UP-D14-R01]

The 2013 RAA Data Retention Waiver and Discussion Document lists and describes all data elements that can be collected by the registrars in accordance with the 2013 RAA and it provides reasons / legitimate purposes for that collection and retention. The following possible User/Purpose requirement stems from this document: Registrars should have access to standard data elements.

Related to [DE-D14-R01], Depends on standard data elements such as those defined by [DE-D06-R08] and Permissible Purposes

1

A

a

[UP-D14-R02]

According to the 2013 RAA Data Retention Waiver and Discussion Document, the public community should have access to WHOIS Information (described in the WHOIS Specification) in order to mitigate abuse, address hijacking, theft and slamming.

Depends on WHOIS Specification

1

CA

j

[UP-D14-R03]

According to the 2013 RAA Data Retention Waiver and Discussion Document, registrars should have access to and be able to collect records of communications with the registrant regarding the registration (log files including communication sources, IP, ISP, behaviour on the website, method of transmission, source IP address, HTTP header, email, Skype handle associated with communication) in order to mitigate fraud prevention, for billing disputes, for commercial purposes.

None

1

EA, A

m, a

[UP-D16-R01]

Under the current ICANN UDRP and URS policies for new gTLDs, contact data published in WHOIS is required to identify registrants for legal purposes. The UDRP and URS policies rely on contact data that is published publicly in [gTLD registration directory services], where potential complainants can see it, and so UDRP and URS dispute resolution service providers can use the data to administrate required communications.

Related to [UP-D01-R12], Depends on Access PR(s) for Public Access, Data Element PR(s) for Contacts

1

IB

k

[UP-D18-R01]

based on the WHOIS Inter-Registrar Transfer Policy, Section I.A.4.5: “For purposes of facilitating transfer requests, Registrars should provide and maintain a unique and private email address for use only by other Registrars and the Registry:

Depends on Data Element PR(s)

2

IB

k

[UP-D18-R02]

based on the WHOIS Inter-Registrar Transfer Policy, Section I.A.4.6:

Depends on Data Element PR(s)

2

IB

k

[UP-D18-R03]

based on the WHOIS Inter-Registrar Transfer Policy, Section I.A.5.5 to I.A.5.6:

Depends on Data Element PR(s)

2

IB

k

[UP-D18-R04]

based on the WHOIS Inter-Registrar Transfer Policy, Section I.b.1.1: “In general, registrants must be permitted to update their registration/WHOIS data and transfer their registration rights to other registrants freely.”

Depends on Data Element PR(s), Data Accuracy PR(s)

1

IB

k

[UP-D19-R01]

based on the ICANN Governmental Advisory Committee (GAC) proposed principles and recommendations related to gTLD WHOIS services on the basis of general public policy issues, gTLD WHOIS [that is, registration directory] services should reflect and respect the following functions: [detailed in [UP-D19-R02 to R09]

Precedes [UP-D19-R02 to R09]

1

IA

d

[UP-D19-R02]

* [Must reflect] Providing "a lookup service to internet users" (para 3.1 and para 2.1)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality

1

DA, A

f, a

[UP-D19-R03]

* [Must reflect] "Providing contact points for network operators and administrators, including ISPs, and certified computer incident response teams" "to support the security and stability of the internet" (para 3.1 and para 2.1.1)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality, Data Element PR(s) for Contacts

1

DA, A

b, a

[UP-D19-R04]

* [Must reflect] "Allowing users to determine the availability of domain names" (para 3.1 and para 2.1.2)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality, Data Element PR(s) for Ops

1

BA, A

c, a

[UP-D19-R05]

* [Must reflect] "Assisting law enforcement authorities (which may include non-governmental entities) in investigations, in enforcing national and international law" (para 3.1 and para 2.1.3)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality

1

CA, A

j, a

[UP-D19-R06]

* [Must reflect] "Assisting in combating against abusive use of ICTs, such as illegal and other acts motivated by racisms (…) including child pornography (…)" (para 3.1 and para 2.1.4)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality

1

CA, A

j, a

[UP-D19-R07]

* [Must reflect] "Facilitating clearance of trademarks and countering intellectual property infringements in accordance with applicable national laws and international treaties" (para 3.1 and para 2.1.5)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality

1

CA, A

j, a

[UP-D19-R08]

* [Must reflect] "Helping users to identify persons or entities responsible for content or services online" in contribution to user confidence in the Internet (para 3.1 and para 2.1.6)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality, Data Element PR(s) for RegID

1

BA, DA, A

c, b, a

[UP-D19-R09]

* [Must reflect] "Assisting businesses, other organizations and users in combating fraud and general compliance with relevant laws" (para 3.1 and para 2.1.7)

Supports [UP-D19-R01], Depends on Permissible Purposes involving this functionality, Data Accuracy PR(s) antifraud

1

CA, A

j, a

[UP-D21-R01]

In sum, from the Article 29 WP’s comments on ICANN’s procedures for handling WHOIS conflicts with privacy law (and related correspondence), we could draw out the following possible Purpose requirements: [detailed in [UP-D21-R02 to R04]

Precedes [UP-D21-R02 to R04]

1

A

a

[UP-D21-R02]

* Need a well-defined purpose for processing/use of data;

Supports [UP-D21-R01], Depends on Privacy PR(s) for Processing/Use

1

A, O

a, j

[UP-D21-R03]

* Domain name Point of Contact needs to be in a position to face the legal and technical responsibilities of domain operation; and

Supports [UP-D21-R01], Depends on Data Element PR(s) for Contacts

1

BA, DA

c, b

[UP-D21-R04]

* Bulk access to WHOIS data for direct marketing should be limited.

Supports [UP-D21-R01], Depends on Access PR(s) for Bulk Access, Same as [UP-D22-R04]

1

CA

i, j

[UP-D21-R05]

According to Article 29 WP’s comments on ICANN’s procedures for handling WHOIS conflicts with privacy law (and related correspondence), “Purpose definition is a central element in determining whether a specific processing or use of personal data is in accordance with EU data protection legislation.”

Depends on Definition of personal data such as [DE-D26-R09]

1

A

a

[UP-D21-R06]

“Article 29 WP acknowledges the legitimacy of the purpose of the making available of some personal data through the WHOIS services ...[t]his publicity is necessary in order to put the person running a Website in a position to face the legal and technical responsibilities which are inherent to the running of such a site.”

None

1

DA, EA

b, e

[UP-D22-R01]

In sum, from the Article 29 WP’s Opinion 2/2003, we could draw out the following possible Purpose requirements: [detailed in [UP-D22-R02 to R05]

Precedes [UP-D22-R02 to R05]

1

A

a

[UP-D22-R02]

* Need a well-defined purpose;

Supports [UP-D22-R01], Depends on Privacy PR(s) for Processing/Use

1

A, CA

a, j

[UP-D22-R03]

* Data collected should be relevant (and not excessive) for defined purpose;

Supports [UP-D22-R01], Depends on Data Element PR(s)

1

A

a

[UP-D22-R04]

* Bulk access to WHOIS data for direct marketing should be limited;

Supports [UP-D22-R01], Depends on Access PR(s) for Bulk Access, Same as [UP-D21-R04]

1

CA

i, j

[UP-D22-R05]

* Data subjects should be provided with unambiguous and informed consent.

Supports [UP-D22-R01], Depends on Privacy PR(s) for Consent

1

EA

l

[UP-D22-R06]

According to the Article 29 WP’s Opinion 2/2003, “From the data protection viewpoint it is essential to determine in very clear terms what is the purpose of the WHOIS and which purpose(s) can be considered as legitimate and compatible to the original purpose.”

Depends on Original Purpose

1

A

a

[UP-D22-R07]

In the Article 29 WP’s Opinion 2/2003, the WP states “its support for ... limitation of bulk access for direct marketing issues.”

Depends on Access PR(s) for Bulk Access

1

EA

I

[UP-D23-R01]

“Specification of purpose is an essential first step in applying data protection laws and designing data protection safeguards for any processing operation. Indeed, specification of the purpose is a pre-requisite for applying other data quality requirements, including the adequacy, relevance, proportionality and accuracy of the data collected and the requirements regarding the period of data retention. The principle of purpose limitation is designed to establish the boundaries within which personal data collected for a given purpose may be processed and may be put to further use. The principle has two components: the data controller must only collect data for specified, explicit and legitimate purposes, and once data are collected, they must not be further processed in a way incompatible with those purposes.” p.4

Depends on Permissible Purposes, Data Accuracy PR(s), Data Element PR(s)

1

A

a

[UP-D23-R02]

“When we share personal data with others, we usually have an expectation about the purposes for which the data will be used. There is a value in honouring these expectations and preserving trust and legal certainty, which is why purpose limitation is such an important safeguard, a cornerstone of data protection. Indeed, the principle of purpose limitation inhibits 'mission creep', which could otherwise give rise to the usage of the available personal data beyond the purposes for which they were initially collected.” p.4

Same as [DE-D23-R01], Depends on Permissible Purposes, Privacy PR(s) on personal data

1

A

a

[UP-D23-R03]

“On the other hand, data that have already been gathered may also be genuinely useful for other purposes, not initially specified. Therefore, there is also a value in allowing, within carefully balanced limits, some degree of additional use. The prohibition of ‘incompatibility’ in Article 6(1)(b) does not altogether rule out new, different uses of the data – provided that this takes place within the parameters of compatibility.” p.4

Depends on Permissible Purposes, Privacy PR(s) on personal data

1

A

a

[UP-D23-R04]

“The principle of purpose limitation - which includes the notion of compatible use - requires that in each situation where further use is considered, a distinction be made between additional uses that are 'compatible', and other uses, which should remain 'incompatible'. The principle of purpose limitation is designed to offer a balanced approach: an approach that aims to reconcile the need for predictability and legal certainty regarding the purposes of the processing on one hand, and the pragmatic need for some flexibility on the other.” p.5

Depends on Permissible Purposes, Privacy PR(s) on personal data

1

A

a

[UP-D23-R05]

Council of Europe “CoE Resolution (73) 22 requires the information to be 'appropriate and relevant with regard to the purpose for which it has been stored' and - in the absence of 'appropriate authorisation' - prohibits its use 'for purposes other than those for which it has been stored' as well as its 'communication to third parties'.” p.8.

Depends on Permissible Purposes, Access PR(s) for authorization, Privacy PR(s) on personal data

1

A

a

[UP-D23-R06]

“When applying data protection law, it must first be ensured that the purpose is specific, explicit and legitimate. This is a prerequisite for other data quality requirements, including adequacy, relevance and proportionality (Article 6(1)(c)), accuracy and completeness (Article 6(1)(d)) and requirements regarding the duration of retention (Article 6(1)(e)).” p. 12

Depends on Permissible Purposes, Data Accuracy PR(s), Access PR(s) for authorization, Privacy PR(s) on personal data

1

A

a

[UP-D23-R07]

“In cases where different purposes exist from the beginning and different kinds of data are collected and processed simultaneously for these different purposes, the data quality requirements must be complied with separately for each purpose.” p. 12

Depends on Permissible Purposes, Data Accuracy PR(s), Data Element PR(s)

1

A

a

[UP-D23-R08]

“If personal data are further processed for a different purpose: the new purposes must be specified (Article 6(1)(b)), and it must be ensured that all data quality requirements (Articles 6(1)(a) to (e)) are also satisfied for the new purposes.” p. 12 [detailed in [UP-D23-R09 to R10]

Precedes [UP-D23-R09 to R10], Depends on Permissible Purposes, Data Accuracy PR(s)

1

F

h

[UP-D23-R09]

* “First building block: purpose specification. Collection for 'specified, explicit and legitimate' purpose”

Supports [UP-D23-R08], Depends on Permissible Purposes

1

A

a

[UP-D23-R10]

* “Second building block: compatible use. Article 6(1)(b) of the Directive also introduces the notions of 'further processing' and 'incompatible' use, and requires that further processing must not be incompatible with the purposes for which personal data were collected.” In particular, Article 6(1)(b) requires that personal data should not be 'further processed in a way incompatible' with those purposes and recital 28 states that the 'purposes of processing further to collection shall not be incompatible with the purposes as they were originally specified'.” p.12

Supports [UP-D23-R08], Depends on Permissible Purposes, Original Purpose, Privacy PR(s) on personal data

1

F

h

[UP-D23-R11]

“Transparency: There is a strong connection between transparency and purpose specification. When the specified purpose is visible and shared with stakeholders such as data protection authorities and data subjects, safeguards can be fully effective. Transparency ensures predictability and enables user control.” p. 13

Depends on Permissible Purposes, Privacy PR(s)

1

AA

ad

[UP-D23-R12]

“Predictability: If a purpose is sufficiently specific and clear, individuals will know what to expect: the way data are processed will be predictable. This brings legal certainty to the data subjects, and also to those processing personal data on behalf of the data controller. Predictability is also relevant when assessing the compatibility of further processing activities. In general, further processing cannot be considered predictable if it is not sufficiently related to the original purpose and does not meet the reasonable expectations of the data subjects at the time of collection, based on the context of the collection.” p. 13

Depends on Permissible Purposes, Original Purpose, Privacy PR(s)

1

A, IA

a, d

[UP-D23-R13]

“User control: User control is only possible when the purpose of data processing is sufficiently clear and predictable. If data subjects fully understand the purposes of the processing, they can exercise their rights in the most effective way. For instance, they can object to the processing or request the correction or deletion of their data.” p. 14

Depends on Permissible Purposes, Privacy PR(s)

1

A, EA

a, e

[UP-D23-R14]

“Personal data must be collected for explicit purposes. The purposes of collection must not only be specified in the minds of the persons responsible for data collection. They must also be made explicit. In other words, they must be clearly revealed, explained or expressed in some intelligible form. It follows from the previous analysis that this should happen no later than the time when the collection of personal data occurs.” p.17

Depends on Permissible Purposes, Data Element PR(s) on Collection, Privacy PR(s) on personal data

1

A, IA

a, d

[UP-D23-R15]

“Purpose limitation [in the EU Data Protection Directive] protects data subjects by setting limits on how data controllers are able to use their data while also offering some degree of flexibility for data controllers.” Executive Summary, p. 3

Depends on Permissible Purposes, Privacy PR(s) for Processing/Use

1

IA

d

[UP-D23-R16]

“Processing of personal data in a way incompatible with the purposes specified at collection is against the law and therefore prohibited. The data controller cannot legitimise incompatible processing by simply relying on a new legal ground in Article 7. The purpose limitation principle can only be restricted subject to the conditions set forth in Article 13 of the Directive.”

Depends on Permissible Purposes, Privacy PR(s) for Processing/Use

1

A

a

[UP-D25-R01]

Council of Europe's Treaty 108 on Data Protections – Convention on the Protection of Individuals with regard to Automatic Processing of Personal Data (signed by 48 countries in Western and Eastern Europe and around the world) [could possibly confer requirements on a gTLD directory service]

Same as [PR-D25-R01]

1

IA

d

[UP-D25-R02]

Council of Europe's Treaty 108 on Data Protections outlaws the processing of "sensitive" data on a person's race, politics, health, religion, sexual life, criminal record, etc., in the absence of proper legal safeguards. (Note: this protects an array of groups and organizations with missions, mandates and projects around race, politics, heath, religion, sexual orientation, prison support and rehabilitation, etc.)

Depends on Privacy PR(s)

1

IA

d

[UP-D25-R03]

Council of Europe's Treaty 108 on Data Protections specifies in Article 5, Quality of data that personal data undergoing automatic processing shall be:

a. obtained and processed fairly and lawfully;

b. stored for specified and legitimate purposes and not used in a way incompatible with those purposes;

c. adequate, relevant and not excessive in relation to the purposes for which they are stored;

d. accurate and, where necessary, kept up to date;

e. preserved in a form which permits identification of the data subjects for no longer than is required for the purpose for which those data are stored.”

Same as [PR-D25-R03], Depends on Permissible Purposes, Data Accuracy PR(s), Definition of personal data such as [DE-D26-R09]

1

A, EA

a, m

[UP-D26-R01]

According to the European Data Protection Directive (1995 ), whereas data-processing systems are designed to serve man; whereas they must, whatever the nationality or residence of natural persons, respect their fundamental rights and freedoms, notably the right to privacy, and contribute to economic and social progress, trade expansion and the well-being of individuals; p.2

Same as [PR-D26-R01] [BE-D26-R01], Depends on Definition of personal data such as [DE-D26-R09]

1

IA, EC, EA

d, ab, ba

[UP-D26-R02]

According to the Directive (20 ), whereas the fact that the processing of data is carried out by a person established in a third country must not stand in the way of the protection of individuals provided for in this Directive; whereas in these cases, the processing should be governed by the law of the Member State in which the means used are located, and there should be guarantees to ensure that the rights and obligations provided for in this Directive are respected in practice;

Same as [CM-D26-R05], Depends on Law of the Member State

1

IA

d

[UP-D26-R03]

According to the Directive (26 ), whereas the principles of protection must apply to any information concerning an identified or identifiable person; whereas, to determine whether a person is identifiable, account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person; whereas the principles of protection shall not apply to data rendered anonymous in such a way that the data subject is no longer identifiable; whereas codes of conduct within the meaning of Article 27 may be a useful instrument for providing guidance as to the ways in which data may be rendered anonymous and retained in a form in which identification of the data subject is no longer possible;

Same as [PR-D26-R04], Depends on Permissible Purposes, Definition of personal data such as [DE-D26-R09]

1

A, IA

a, d

[UP-D26-R04]

According to the Directive (28 ), whereas any processing of personal data must be lawful and fair to the individuals concerned; whereas, in particular, the data must be adequate, relevant and not excessive in relation to the purposes for which they are processed; whereas such purposes must be explicit and legitimate and must be determined at the time of collection of the data; whereas the purposes of processing further to collection shall not be incompatible with the purposes as they were originally specified;

Same as [DE-D26-R05], Depends on Permissible Purposes, Original Purpose, Definition of personal data such as [DE-D26-R09]

1

A, IA

a, d

[UP-D26-R05]

According to the Directive (29 ), whereas the further processing of personal data for historical, statistical or scientific purposes is not generally to be considered incompatible with the purposes for which the data have previously been collected provided that Member States furnish suitable safeguards; whereas these safeguards must in particular rule out the use of the data in support of measures or decisions regarding any particular individual;

Depends on Definition of personal data such as [DE-D26-R09], Definition of Suitable Safeguards

1

A, IA

a, d

[UP-D26-R06]

According to the Directive (30 ), whereas, in order to be lawful, the processing of personal data must in addition be carried out with the consent of the data subject or be necessary for the conclusion or performance of a contract binding on the data subject, or as a legal requirement, or for the performance of a task carried out in the public interest or in the exercise of official authority, or in the legitimate interests of a natural or legal person, provided that the interests or the rights and freedoms of the data subject are not overriding….subject to the provisions allowing a data subject to object to the processing of data regarding him, at no cost and without having to state his reasons;

Same as [PR-D26-R05], Depends on Definition of personal data such as [DE-D26-R09], Privacy PR(s) on Legal and Natural Persons

1

A, IA

a, d

[UP-D26-R07]

According to the Directive (31 ), whereas the processing of personal data must equally be regarded as lawful where it is carried out in order to protect an interest which is essential for the data subject's life;

Depends on Definition of personal data such as [DE-D26-R09]

1

A, DA, IA

a, b, d

[UP-D26-R08]

According to the Directive (33 ), whereas data which are capable by their nature of infringing fundamental freedoms or privacy should not be processed unless the data subject gives his explicit consent; whereas, however, derogations from this prohibition must be explicitly provided for in respect of specific needs, in particular where the processing of these data is carried out for certain health-related purposes by persons subject to a legal obligation of professional secrecy or in the course of legitimate activities by certain associations or foundations the purpose of which is to permit the exercise of fundamental freedoms;

Same as [PR-D26-R06] [DE-D26-R06], Depends on Privacy PR(s) for Consent, Depends on referenced Permissible Purposes

1

IA

d

[UP-D26-R09]

According to the Directive (39 ), whereas certain processing operations involve data which the controller has not collected directly from the data subject; whereas, furthermore, data can be legitimately disclosed to a third party, even if the disclosure was not anticipated at the time the data were collected from the data subject; whereas, in all these cases, the data subject should be informed when the data are recorded or at the latest when the data are first disclosed to a third party;

Same as [GA -D26-R02] [PR -D26-R07] [SM-D26-R04]

1

BA

c

[UP-D26-R10]

According to the Directive (41 ), whereas any person must be able to exercise the right of access to data relating to him which are being processed, in order to verify in particular the accuracy of the data and the lawfulness of the processing; whereas, for the same reasons, every data subject must also have the right to know the logic involved in the automatic processing of data concerning him, at least in the case of the automated decisions referred to in Article 15 (1); whereas this right must not adversely affect trade secrets or intellectual property and in particular the copyright protecting the software; whereas these considerations must not, however, result in the data subject being refused all information;

Same as [GA-D26-R03] [DA-D26-R02]

1

EA

e

[UP-D26-R11]

According to the Directive (50 ), whereas exemption or simplification could be provided for in cases of processing operations whose sole purpose is the keeping of a register intended, according to national law, to provide information to the public and open to consultation by the public or by any person demonstrating a legitimate interest;

Depends on National Law, Legitimate Interest,
Permissible Purpose

1

BA

c

[UP-D26-R12]

According to the Directive (5 1), whereas, nevertheless, simplification or exemption from the obligation to notify shall not release the controller from any of the other obligations resulting from this Directive;

None

1

EA

l

[UP-D26-R13]

According to the Directive (56 ), whereas cross-border flows of personal data are necessary to the expansion of international trade; whereas the protection of individuals guaranteed in the Community by this Directive does not stand in the way of transfers of personal data to third countries which ensure an adequate level of protection; whereas the adequacy of the level of protection afforded by a third country must be assessed in the light of all the circumstances surrounding the transfer operation or set of transfer operations;

Same as [GA-D26-R04] [CS-D26-R04], Depends on Definition of personal data such as [DE-D26-R09], Privacy PR(s) on Adequacy

1

EA

m

[UP-D26-R14]

As used in the Directive , [data] 'controller' means the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; where the purposes and means of processing are determined by national or Community laws or regulations, the controller or the specific criteria for his nomination may be designated by national or Community law;

Depends on Definition of personal data such as [DE-D26-R09], National or Community Law

1

EA

m

[UP-D26-R15]

As used in the Directive , [data] 'processor' means a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller;

Depends on Definition of Controller such as [UP-D26-R14], Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D26-R16]

As used in the Directive , 'third party' means any natural or legal person, public authority, agency or any other body other than the data subject, the controller, the processor and the persons who, under the direct authority of the controller or the processor, are authorized to process the data;

Depends on Definition of Controller such as [UP-D26-R14], Definition of Processor such as [UP-D26-R15]

1

EA

m

[UP-D26-R17]

As used in the Directive , [data] 'recipient' means a natural or legal person, public authority, agency or any other body to whom data are disclosed, whether a third party or not; however, authorities which may receive data in the framework of a particular inquiry shall not be regarded as recipients;

None

1

BA

c

[UP-D26-R18]

As used in the Directive , 'the data subject's consent' means any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed.

Depends on Definition of personal data such as [DE-D26-R09]

1

EA

l

[UP-D26-R19]

According to the Directive , Member States shall provide that personal data must be [handled as detailed in [UP-D26-R20 to R24]

Precedes [UP-D26-R20 to R24], Depends on Definition of personal data such as [DE-D26-R09]

1

IA

d

[UP-D26-R20]

* [personal data must be] processed fairly and lawfully;

Supports [UP-D26-R19], Related to [PR-D25-R03], Depends on Applicable Law

1

IA

d

[UP-D26-R21]

* [personal data must be] collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes. Further processing of data for historical, statistical or scientific purposes shall not be considered as incompatible provided that Member States provide appropriate safeguards;

Supports [UP-D26-R19], Similar to [UP-D23-R01], Depends on Permissible Purposes

1

A

a

[UP-D26-R22]

* [personal data must be] adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed;

Supports [UP-D26-R19], Similar to [UP-D23-R01], Depends on Permissible Purposes

1

EA

r

[UP-D26-R23]

* [personal data must be] accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that data which are inaccurate or incomplete, having regard to the purposes for which they were collected or for which they are further processed, are erased or rectified;

Supports [UP-D26-R19], Depends on Data Accuracy PR(s)

1

DB

n

[UP-D26-R24]

* [personal data must be] kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the data were collected or for which they are further processed. Member States shall lay down appropriate safeguards for personal data stored for longer periods for historical, statistical or scientific use.

Supports [UP-D26-R19]

1

IA, EA

d, m

[UP-D26-R25]

According to the Directive Article 7, Member States shall provide that personal data may be processed only if: [conditions detailed in [UP-D26-R26 to R31]

Precedes [UP-D26-R26 to R31], Depends on Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D26-R26]

* [personal data may be processed only if] the data subject has unambiguously given his consent

Supports [UP-D26-R25]

1

EA

l

[UP-D26-R27]

* [personal data may be processed only if] processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract

Supports [UP-D26-R25]

1

EA

l

[UP-D26-R28]

* [personal data may be processed only if] processing is necessary for compliance with a legal obligation to which the controller is subject

Supports [UP-D26-R25], Depends on Obligations of Data Controllers [DE-D29-R01]

1

CA

j

[UP-D26-R29]

* [personal data may be processed only if] processing is necessary in order to protect the vital interests of the data subject

Supports [UP-D26-R25]

1

DA

b

[UP-D26-R30]

* [personal data may be processed only if] processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed

Supports [UP-D26-R25], Depends on Controller’s Authority

1

DA

b

[UP-D26-R31]

* [personal data may be processed only if] processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection under [the Directive ] Article 1 (1).

Supports [UP-D26-R25], Depends on Legitimate Interests, Fundamental Rights and Freedoms

1

IA, EA

d, m

[UP-D26-R32]

According to the Directive , Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life.

[This requirement] shall not apply where:]

(a) the data subject has given his explicit consent to the processing of those data, except where the laws of the Member State provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject's giving his consent; or

(b) processing is carried out in the course of its legitimate activities with appropriate guarantees by a foundation, association or any other non-profit-seeking body with a political, philosophical, religious or trade-union aim and on condition that the processing relates solely to the members of the body or to persons who have regular contact with it in connection with its purposes and that the data are not disclosed to a third party without the consent of the data subjects; or

(c) the processing relates to data which are manifestly made public by the data subject or is necessary for the establishment, exercise or defence of legal claims.

Depends on Definition of personal data such as [DE-D26-R09], Data Element PR(s)

1

EA

m

[UP-D26-R33]

According to the Directive , processing of data relating to offences, criminal convictions or security measures may be carried out only under the control of official authority, or if suitable specific safeguards are provided under national law, subject to derogations which may be granted by the Member State under national provisions providing suitable specific safeguards. However, a complete register of criminal convictions may be kept only under the control of official authority.

Depends on National Law, Official Authority

1

A, IA

a, d

[UP-D26-R34]

According to the Directive , where the data have not been obtained from the data subject, Member States shall provide that the controller or his representative must at the time of undertaking the recording of personal data or if a disclosure to a third party is envisaged, no later than the time when the data are first disclosed provide the data subject with at least the following information, except where he already has it:

(a) the identity of the controller and of his representative, if any;

(b) the purposes of the processing;

(c) any further information such as

  • the categories of data concerned,
  • the recipients or categories of recipients,
  • the existence of the right of access to and the right to rectify the data concerning him in so far as such further information is necessary, having regard to the specific circumstances in which the data are processed, to guarantee fair processing in respect of the data subject.

[The above requirement] shall not apply where, in particular for processing for statistical purposes or for the purposes of historical or scientific research, the provision of such information proves impossible or would involve a disproportionate effort or if recording or disclosure is expressly laid down by law. In these cases Member States shall provide appropriate safeguards.

Same as [GA-D26-R07], Depends on Permissible Purposes, Permissible Users, Access PR(s), Data Element PR(s), Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D26-R35]

According to the Directive Article 25, Member States shall provide that the transfer to a third country of personal data which are undergoing processing or are intended for processing after transfer may take place only if, without prejudice to compliance with the national provisions adopted pursuant to the other provisions of this Directive, the third country in question ensures an adequate level of protection.

Depends on Privacy PR(s) on Adequacy

1

EA

m

[UP-D27-R01]

According to the European Data Protection Supervisor, Registrar Accreditation Agreement (RAA) gTLD registration data element specifications “should only require collection of personal data, which is genuinely necessary for the performance of the contract between the Registrar and the Registrant (e.g. billing) or for other compatible purposes such as fighting fraud related to domain name registration.”

Depends on Permissible Purposes, Data Element PR(s) - RAA, Definition of personal data such as [DE-D26-R09]

1

A, IA

a, d

[UP-D27-R02]

According to the European Data Protection Supervisor, personal data should only be collected to perform the contract between Registrar and Registrant, and that it should be retained no longer than is necessary for these purposes. “This data should be retained for no longer than is necessary for these purposes. It would not be acceptable for the data to be retained for longer periods or for other, incompatible purposes, such as law enforcement purposes or to enforce copyright.”

Depends on Definition of personal data such as [DE-D26-R09], Data Element PR(s) on Retention

1

J

o

[UP-D28-R01]

“The people or bodies that collect and manage personal data are called "data controllers". They must respect EU law when handling the data entrusted to them.” (Note: they manage the data for the purpose for which it was collected.)

Same as [PR-D28-R01], Similar to [UP-D26-R14], Depends on Definition of personal data such as [DE-D26-R09], EU Law

1

EA

m

[UP-D28-R02]

“The privacy rights of individuals supplying their personal data must be respected by anyone collecting and processing that data. The Data Protection Directive lays down a series of rights and duties in relation to personal data when it is collected and processed.”

Variant of [GA-D28-R01], Depends on Definition of personal data such as [DE-D26-R09], Data Protection Directive

1

A, IA

a, d

[UP-D28-R03]

The EU Privacy Directive “refers to the persons or entities which collect and process personal data as ‘data controllers’. For instance, a medical practitioner is usually the controller of his patients' data; a company is the controller of data on its clients and employees; a sports club is controller of its members' data and a library of its borrowers' data.” [gTLD registration directory services? must] ensure that Uses/Purposes are consistent with those allowed by law and the purpose for which the data was collected.

Same as [PR-D28-R02], Depends on Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D28-R04]

“Data controllers determine 'the purposes and the means of the processing of personal data'. This applies to both public and private sectors.”

Same as [PR-D28-R03] [OQ-D28-R01] , Depends on Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D28-R05]

“Data controllers must respect the privacy and data protection rights of those whose personal data is entrusted to them. They must:

  • collect and process personal data only when this is legally permitted;
  • respect certain obligations regarding the processing of personal data;
  • respond to complaints regarding breaches of data protection rules;
  • collaborate with national data protection supervisory authorities.

Same as [PR-D28-R04], Depends on Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D30-R01]

The WP29 recalls its long-standing position that massive and indiscriminate surveillance of individuals can never be considered as proportionate and strictly necessary in a democratic society, as is required under the protection offered by the applicable fundamental rights. Additionally, comprehensive oversight of all surveillance programmes is crucial. pg. 4

Same as [RI-D30-R02] [SM-D30-R01]

1

AB

p

[UP-D30-R02]

The requirement for a third country to ensure an adequate level of data protection was further defined by the CJEU in Schrems…It also indicated that the wording ‘adequate level of protection’ must be understood as “requiring the third country in fact to ensure, by reason of its domestic law or its international commitments, a level of protection of fundamental rights and freedoms that is essentially equivalent to that guaranteed within the European Union by virtue of the Directive read in the light of the Charter” pg.10

Same as [GA-D30-R01] [PR-D30-R05] [ CM-D30-R03]

1

A, IA

a, d

[UP-D30-R03]

The WP29 has already explained the way it applied the core EU data protection principles to transfers of personal data to third countries in its Working Document 12 ‘Transfers of personal data to third countries: Applying Articles 25 and 26 of the EU data protection directive’. The WP29 tried to find the equivalent safeguards which ensure a level of protection equivalent to the principles guaranteed in the Directive, notably regarding purpose limitation, data quality and proportionality, transparency, security, rights of access, rectification and opposition, data retention and restrictions on onward transfers. pg. 11

Same as [DE-D30-R01] [PR-D30-R06] [ CM-D30-R04], Depends on Definition of personal data such as [DE-D26-R09], EU Data Protection Directive [D29]

1

EA

m

[UP-D30-R04]

WP29 stresses that any interference with the fundamental rights to private life and data protection need to be justifiable in a democratic society. The CJEU criticised the fact that the Safe Harbour decision did not contain any finding regarding the existence, in the United States, of rules adopted by the State intended to limit any interference. Nor does it refer to the existence of effective legal protection against interference of that kind.pg 11

Same as [GA-D30-R02] [GA-D30-R03] [DE-D30-R03] [PR-D30-R07] [CX-D30-R02] [SM-D30-R02] [RI-D30-R03]

1

IA

d

[UP-D30-R05]

In order to evaluate if any interference would be justifiable in a democratic society, the assessment was conducted in light of the European jurisprudence on fundamental rights which sets four essential guarantees for intelligence activities [as detailed in [UP-D30-R06 to R08]

Precedes [UP-D30-R06 to R08], Same as [GA-D30-R04] [PR-D30-R08] [ SM-D30-R03]

1

IA

d

[UP-D30-R06]

* Processing should be in accordance with the law and based on clear, precise and accessible rules: this means that anyone who is reasonably informed should be able to foresee what might happen with her/his data where they are transferred;

Supports [UP-D30-R05], Similar to [UP-D30-R21], Depends on Laws and Rules

1

A, EA

a, l

[UP-D30-R07]

* Necessity and proportionality with regard to the legitimate objectives pursued need to be demonstrated: a balance needs to be found between the objective for which the data are collected and accessed and the rights of the individual;

Supports [UP-D30-R05], Depends on Permissible Purposes, Rights of the Individual

1

EA

r

[UP-D30-R08]

* An independent oversight mechanism should exist, that is both effective and impartial: this can either be a judge or another independent body, as long as it has sufficient ability to carry out the necessary checks;

Supports [UP-D30-R05]

1

IA

d

[UP-D30-R09]

Effective remedies need to be available to the individual: anyone should have the right to defend her/his rights before an independent body. pg. 12

None

1

EC, IA

ab, d

[UP-D30-R10]

Scope of application of the EU data protection framework and, in particular, of the Directive 95/46/EC principles: The WP29 recalls that under the EU data protection legal framework, and in particular under the Directive (Article 4(1)), Member States laws apply not only to the processing operations carried out by data controllers established on their territory, but also where data controllers (although not established in the EU), make use of equipment situated on EU territory, in particular for the collection of personal data. As a consequence, EU Member State law applies to any processing that takes place prior to the transfer to the U.S., either in the context of activities of an organisation established in the EU or through the use of equipment situated in the EU used by an organisation not established in the EU. pg. 12

Same as [DE-D30-R04] [ CM-D30-R06] [SM-D30-R04], Depends on Definition of personal data such as [DE-D26-R09], EU Directive (Article 4(1))

1

EC

ab

[UP-D30-R11]

It is therefore crucial to clarify in the Principles that in case of such contradiction, the provisions of the data processing contract and particularly the instructions of the organization transferring the data out of the EU will prevail. Without such clarification, the Principles could be interpreted and applied in a manner that offers too much control capacities to the Shield Agent and this would put the EU data exporter at risk of violating his obligations as a data controller under EU data protection law to which it is subject when transferring data to a Shield organisation acting as an Agent. In addition, this lack of clarity gives the impression that the processor might reuse the data as he wishes.pg 16

Depends on Obligations of Data Controllers [DE-D29-R01]

1

EC, EA

ab, m

[UP-D30-R12]

Annex II, I.5. provides, among others, for exemptions from the Principles when data covered by the Privacy Shield is used for reasons of national security, public interest, law enforcement, or following statute, government regulation or case law which creates conflicting obligations or explicit authorisations. Without full knowledge of U.S. law at both the Federal and at state level, it is difficult for the WP29 to assess the scope of this exemption and to consider whether those limitations are justifiable in a democratic society. It would be essential that the European Commission also includes in its draft adequacy decision an analysis of the level of protection where those exemptions would apply. pg. 17

Same as [PR-D30-R11] [CM-D30-R09]

1

ID

g

[UP-D30-R13]

The Data Retention Limitation principle (Article 6(1)e of the Directive) is a fundamental principle in EU data protection law imposing that personal data must only be kept as long as necessary to achieve the purpose for which the data have been collected or for which they are further processed.pg 17

Same as [DE-D30-R09], Depends on Permissible Purposes, Definition of personal data such as [DE-D26-R09]

1

IA

d

[UP-D30-R14]

Moreover, the WP29 emphasises that a general right to object (on compelling grounds relating to the data subject’s particular situation), being understood as a right to ask to terminate the processing about one's data whenever the individual has compelling legitimate grounds relating to his particular situation, should be offered within the Privacy Shield. The WP29 strongly recommends that the draft adequacy decision makes clear that the right to object should exist at any given moment, and that this objection is not limited to the use of the data for direct marketing. pg. 20

Same as [PR-D30-R12], Depends on Privacy Shield

1

EA

m

[UP-D30-R15]

It should be clarified that in any case, the Choice principle cannot be used to circumvent the Purpose limitation principle. Choice should be applicable only where the purpose is materially different but still compatible since the processing for incompatible purpose is prohibited (Annex II, II.5.a). It has to be clarified that the right to opt-out cannot enable the organisation to use data for incompatible purposes.pg 20

Same as [PR-D30-R13], Depends on Compatible Purposes, Privacy PR(s) on Choice and Limitation of Purpose

1

IA

d

[UP-D30-R16]

The WP29 recommends also inserting a clear reference to the Purpose Limitation principle (Annex II, II.5) within the conditions for onward transfers to a third party controller (Annex II, II.3.a). This would make clear that onward transfers may not take place where the third party controller will process data for an incompatible purpose. pg. 21

Depends on Compatible Purposes

1

 

m

[UP-D30-R17]

The WP29 notes that the Accountability for Onward Transfer principle (Annex II, II.3) explains that personal data may be transferred to a third party acting as an Agent only for limited and specified purposes, but does not explicitly say that these limited and specified purposes have to be compatible with the initial purposes for which the data were collected as well as with the instructions of the controller. More clarity is needed on this point. pg. 21

Depends on Permissible Purposes, Definition of personal data such as [DE-D26-R09]

1

EA

m

[UP-D30-R18]

PPD-28 imposes limits on the use of signals intelligence collected in bulk as regards the purpose of the use. These six purposes for which data can be collected in ‘bulk’, including counter-terrorism and other forms of serious (transnational) crimes. The WP29’s analysis suggests that the purpose limitation is rather wide (and possibly too wide) to be considered as targeted.pg.38

Depends on PPD-28 Bulk Collection Purposes

1

A, CC

a, q

[UP-D30-R19]

The WP29 recalls that it has consistently considered that massive and indiscriminate collection of data in any case cannot be regarded as proportionate.pg. 39

None

1

EA

r

[UP-D30-R20]

WP29 notes that also targeted data processing, or processing that is ‘as tailored as feasible’, can still be considered to be massive. Whether or not such massive data collection should be allowed or not is currently subject to proceedings before the CJEU. For this reason, the WP29 shall not make a final assessment as to the legality of targeted, but massive data processing. However, it stresses that if targeted, but massive data processing would be allowed, the targeting principles should apply to both the collection and the subsequent use of the data, and cannot be limited to just the use…The WP29 is, at this stage, not convinced these purposes are sufficiently restricted to ensure the data collection is indeed restricted to what is necessary and proportional. pg.40

None

1

EA

m

[UP-D30-R21]

4.2.1 Access by law enforcement authorities to personal data should be in accordance with the law and based on clear, precise and accessible rules. pg.53

Same as [GA-D30-R07], Similar to [UP-D30-R06], Depends on Definition of personal data such as [DE-D26-R09], Laws and Rules

1

CC

q

[UP-D30-R22]

Since all applicable rules to limit access by law enforcement authorities to data transferred under the Privacy Shield are based on the Constitution, on statutory law and on transparent policies of the Department of Justice, a presumption of accessibility of these rules is taken into account by the WP29. However, the clarity and precision of the rules can only be assessed in each individual type of procedure and request for access. The WP29 therefore regrets to note that, based on the available details in Annex VII to the Privacy Shield and the findings in the draft decision, such an assessment cannot be done at this moment. pg 53

Same as [GA-D30-R08], Depends on Constitution, Law, DoJ Policies, Privacy Shield

1, 2

CC

q

[UP-D30-R23]

Necessity and proportionality with regard to the legitimate objectives pursued need to be demonstrated. The WP29 duly notes that requesting access to data for law enforcement purposes can be considered to pursue a legitimate objective. For instance, Article 8(2) ECHR accepts interferences to the right to the protection for private life by a public authority “in the interests of (…) public safety, (…) for the prevention of disorder or crime”. However, such interferences are only acceptable when they are necessary and proportionate pg.53

None

1

CC, EA

q, r

[UP-D30-R24]

According to the settled case-law of the CJEU, the principle of proportionality requires that the legislative measures proposing interferences with the rights to private life and to the protection of personal data “be appropriate for attaining the legitimate objectives pursued by the legislation at issue and do not exceed the limits of what is appropriate and necessary in order to achieve those objectives.” Therefore, the assessment of necessity and proportionality is always done in relation to a specific measure envisaged by legislation. pg. 54

Same as [GA-D30-R09] [DE-D30-R11] [PR-D30-R15], Depends on Definition of personal data such as [DE-D26-R09], Legitimate Objectives

1, 2

EA

r

[UP-D30-R25]

The first concern is that the language used in the draft adequacy decision does not oblige organisations to delete data if they are no longer necessary. This is an essential element of EU data protection law to ensure that data is kept for no longer than necessary to achieve the purpose for which the data were collected pg.57

Depends on Permissible Purpose

1

J

o

[UP-D59-R01]

According to the GAC, law enforcement should be defined as follows: “Law Enforcement Authority” is defined as “law enforcement, consumer protection, quasi-governmental or other similar authorities designated from time to time by the national or territorial government of the jurisdiction in which the privacy or proxy service provider is established or maintains a physical office.”

None

1

CC

q

[UP-D59-R02]

To the extent this definition could be viewed as suggesting that P/P service providers need only respond to law enforcement authorities within their own jurisdiction, the PSWG urges the P/P WG to consider revising this definition. Malicious conduct involving domains often takes place across borders and the definition of law enforcement should recognize the multi-jurisdictional aspects of investigative and enforcement activities in order to promote protecting the public no matter where they are located. If such revisions are made, the Working Group should consider a requirement that a P/P service consult with its local law enforcement authorities in the event it receives a request from a foreign authority (to ensure that the local authorities believe that the request is a proper request from a recognized foreign authority).

Depends on [UP-D59-R01]

1

CC, ID

q, g

[UP-D59-R03]

There is a need for confidentiality in ongoing LEA investigations.

None

1

CC

q

[UP-D62-R01]

There should be RDS access provided to LEAs

None

1

CC

q

[UP-D62-R02]

When using a domain name from a person perspective, I wish my data would not be available to marketing purposes

None

1

AB

u

[UP-D62-R03]

When I buy something on the web, I would like to be able to access the registration data for the web page I am using to know it is the real company

None

1

AB

u

[UP-D62-R04]

There are a lot of third parties (not just LEAs) who have legitimate reasons for access to avoid their rights being infringed upon

None

1

AB

u

[UP-D62-R05]

Related to TM Clearinghouse notices, when notices are received, analysis that is performed includes going to see who is the registrant - this often eliminates the need for further action (~60-70%)

None

1

AB

u

[UP-D63-R01]

According to Outreach #2 Responses from the RySG, Requestors must show a valid reason for requesting PII (including name, phone number, address) of a   registrant. For the majority of requestors, PII data is not needed and should be anonymized.

None

1

AB

u

[UP-D63-R02]

A list of parties who will have full access/grant access to RDS data should be created.

None

1

AB

u

[UP-D63-R03]

Procedures of granting full access should be established and published to affected parties (Registries/Registrars). (consider reclassifying this as GA)

None

1

AB

u

See Additional Key Inputs for this charter question ( hyperlinked on this Wiki page ) which may be consulted as a potential source of possible requirements. The PDP WG may also identify additional sources by themselves or through community outreach.

Gated Access (GA)

The following possible requirements address the charter question on Gated Access (GA):
What steps should be taken to control data access for each user/purpose?

The process framework for this question (below) can be applied to categorize possible requirements into three phases:

In the grid below, we identify the possible requirement for WG deliberation, any prerequisites or dependencies contained in that possible requirement , and whether the possible requirement therefore falls into Phase 1, 2, or 3. Policies designed to meet Phase 1 policy requirements should be considered in Phase 2 , while implementation or coexistence guidance for Phase 2 policies should be considered in Phase 3 . In addition, an initial attempt has been made to group similar requirements by code (C) and keyword (K) , allowing the table to be easily re-sorted or filtered – see Annex B for definitions.

QQ-D#-R#

Possible Requirement

Prerequisites/Dependencies

Ph

C

K

[GA-D01-R01]

“gTLD registration data must be collected, validated, and disclosed for permissible purposes only, with some data elements being accessible only to authenticated requestors that are then held accountable for appropriate use.” (Permissible Purpose Principle 6 on page 31, relevant to both UP and GA Questions)

DEPENDENCIES NOT YET ADDED TO THIS COLUMN EXCEPT WHERE PRs ARE DUPLICATES

1

A

a

[GA-D01-R02]

“Every Registrant must have the ability to access all public and gated information published in the [gTLD registration directory services] about their domain name, including designated contact data.” (Permissible Purpose Principle 7 on page 31, relevant to both UP and GA Questions)

Similar to [UP-D01-R02]

1

EA

e

[GA-D01-R03]

To maximize Registrant privacy, Registrant-supplied data must be gated by default, except where there is a compelling need for public access that exceeds resulting risk.

Similar to [UP-D01-R04]

1

AB

s

[GA-D01-R04]

Registrants can opt into making any gated Registrant-supplied data public with informed consent. (Data Disclosure Principle 35 on page 45)

 

1

AB

s

[GA-D01-R05]

* gTLD registration directory services must make data accessible only in conformance with specified Data Access Principles (41-55 on pages 58-61), as follows:

Precedes [GA-D01-R06 to R13]

1

AB

s

[GA-D01-R06]

* A minimum set of data elements, at least in line with the most stringent privacy regime, must be accessible by unauthenticated users.

Supports [GA-D01-R05]

1

EA, AB

d, s

[GA-D01-R07]

* Multiple levels of authenticated data access must be supported, consistent with stated permissible purposes.

Supports [GA-D01-R05]

1

AB

t

[GA-D01-R08]

* gTLD registration directory services user access credentials must be tied to an auditable accreditation process.

Supports [GA-D01-R05]

2

AB

u

[GA-D01-R09]

* Access must be non-discriminatory (i.e., the process must create a level playing field for all requestors, within the same purpose).

Supports [GA-D01-R05]

1

BA

c

[GA-D01-R10]

* The gTLD registration directory service must deter misuse and promote accountability;

Supports [GA-D01-R05]

1

AD

au

[GA-D01-R11]

* All gTLD registration data element access must be based on a stated purpose;

Supports [GA-D01-R05]

1

A, IA

a, d

[GA-D01-R12]

* Access to gated data elements must be limited to authenticated requestors that assert a permissible purpose; and

Supports [GA-D01-R05]

1

AB

u

[GA-D01-R13]

* Requestors must be able to apply for and receive credentials for use in future authenticated data access queries.

Supports [GA-D01-R05]

2

AB

u

[GA-D01-R14]

Some type of accreditation must be applied to requestors of gated access to gTLD registration data:

Precedes [GA-D01-R15 to R17]

1

AB

u

[GA-D01-R15]

* When accredited Requestors query data, their purpose must be stated every time a request is made.

Supports [GA-D01-R14]

2

A

a

[GA-D01-R16]

* Different [access] terms and conditions may be applied to different purposes.

Supports [GA-D01-R14]

1

IA, J

d, av

[GA-D01-R17]

* If accredited requestors violate terms and conditions, penalties must apply.

Supports [GA-D01-R14]

1

L

v

[GA-D01-R18]

To raise the standard of gTLD registration data protection, all directory services queries/responses must make use of commonly-available message encryption and authentication measures to protect the confidentiality and integrity of data in transit.

 

1

G

x

[GA-D01-R19]

To meet the needs of authenticated users with permissible purposes, the gTLD registration directory must provide a Reverse Query service that searches public and gated data elements for a specified value and returns a list of all domain names that reference that value.

Similar to [UP-D07-R01] [DE-D32-R04]

1

BA

c

[GA-D01-R20]

To meet the needs of authenticated users with permissible purposes, the directory service must provide a WhoWas service that returns historical snapshots of public and gated data elements for specified domain names, limited to the historical data available.

 

1

BA

c

[GA-D01-R21]

The gTLD registration directory service must support innovative services that make use of gTLD registration data elements, as follows.

Precedes [GA-D01-R22 to R23]

1

BA

c

[GA-D01-R22]

* Third parties must be able to provide existing and future innovative services – including Reverse Queries and WhoWas – using public data elements and held to terms and conditions of gTLD registration data use.

Supports [GA-D01-R21]

1

BA

c

[GA-D01-R23]

* In the event that third parties offer innovative services involving gated data elements, those third parties must be accredited and held to terms and conditions of gTLD registration data use.

Supports [GA-D01-R21]

1

BA, AB

c, u

[GA-D01-R24]

All disclosures of gated data elements must occur through defined gTLD registration directory service access methods (including those described above). The entire registration data set for all gTLDs (or the entire Registry data set for a single gTLD) must not be exported in bulk form for uncontrolled access.

Supports [GA-D01-R21]

1

AB

s

[GA-D01-R25]

Disclosures may occur through interactive display and other gTLD registration directory service access methods.

Precedes [GA-D01-R26 to R30]

2

AB

u

[GA-D01-R26]

* To make data easier to find and access in a consistent manner, a central point of access (e.g., web portal) must be offered.

Supports [GA-D01-R25]

2

AB

u

[GA-D01-R27]

* Secure access to public gTLD registration data must be available to all requestors through an unauthenticated query method (at minimum, via secure website).

Supports [GA-D01-R25]

1, 2

AB

t

[GA-D01-R28]

* Secure access to gated gTLD registration data must be supported through secure web and other access methods and formats based on authenticated requestor and purpose.

Supports [GA-D01-R25]

1, 2

AB

u

[GA-D01-R29]

* Requestors must be able to obtain authoritative data from the gTLD registration directory service in real-time when needed.

Supports [GA-D01-R25]

2

AB

u

[GA-D01-R30]

* The gTLD registration directory service must accommodate automation for large-scale lookups for various use cases and permissible purposes.

Supports [GA-D01-R25]

1

CA

i, j

[GA-D01-R31]

To be truly global, the gTLD registration directory service must accommodate the display of registration data in multiple languages, scripts and character sets, including Internationalized domain names (IDNs).

Related to [GA-D42-R03] [DA-D02-R02] [DE-D09-R01] [DE-D02-R01]

1

F

y

[GA-D01-R32]

The gTLD registration directory service should support all future GNSO-defined transliteration policies for gTLDs.

 

1

F

y

[GA-D01-R33]

The gTLD registration directory service should enable collection and display of registration data elements in local languages.

 

1

F

y

[GA-D01-R34]

“All access must be purpose-based, returning only data elements permitted for the stated purpose.” (bottom of p.62)

 

1

A

a

[GA-D01-R35]

“. . for each [gTLD registration directory services] user community identified [under the Charter question on Users/Purposes] desiring access to gated data for permissible purposes, community experts must be consulted to confirm EWG-identified registration data purposes, the data elements that must be accessible for that purpose, and possible User Accreditors.” (top of p.63)

 

1

AB

a, u

[GA-D01-R36]

“Non-accredited, unauthenticated access to non-gated (i.e., public) data must be possible in real-time.”

 

1

AB

t

[GA-D01-R37]

“Accreditation of [gTLD registration directory service] users for access to [registration data] does not have to happen in real-time for all use cases and/or requesters.”

 

1

AB

u

[GA-D01-R38]

“[gTLD registration directory services] must only apply the minimum accreditation scheme necessary to provide users access to gated data elements for the stated purpose.”

 

2

AB

u

[GA-D01-R39]

“There must be no requirement to pre-approve or provide credentials to every potential user of [gTLD registration directory services.] A request and fulfilment process can be created for each type of accredited user (i.e., [gTLD registration directory services] user community).”

 

2

AB

u

[GA-D01-R40]

Accreditation for [gTLD registration directory services] users seeking access to data for permissible purposes could be granted in various ways as determined by data access policy. For example, None (i.e., unauthenticated access to public data only), self-accreditation by the person/entity requesting the data, or accreditation by some trusted third party.

 

3

AB

u

[GA-D01-R41]

Whenever possible, any third party accreditation process must leverage existing accreditation processes within each user community that needs credentialing.

 

3

AB

u

[GA-D01-R42]

“Third party accreditation processes must be vetted by an authority responsible for implementing and enforcing [gTLD registration directory services] user accreditation policy (for example, ICANN, a multistakeholder panel) and reviewed on a periodic basis.”

 

3

AB

u

[GA-D01-R43]

“Any organization serving as a [gTLD registration directory service] user accreditor must have a signed agreement with ICANN and/or the registration directory service provider to offer such accreditation processes under agreed-upon guidelines, and establish a framework to allow for due process, accountability, security, fair access, and adherence to applicable law.”

 

1, 2

AB

u

[GA-D01-R44]

Accreditors must take on defined sets of responsibilities, such as establishing criteria for membership, setting credentialing requirements, defining and enforcing terms and conditions of membership, providing functions such as user account creation, credential issuance, suspension and revocation, lifecycle user account management, and associated processes such as dispute handling and ToC enforcement.

 

2

AB

u

[GA-D01-R45]

Accreditors that wish to participate in handling gTLD registration directory services requests for data on behalf of their members must be able to do so in ways that enable auditing and abuse complaint resolution and hold parties responsible for compliant usage and accountable in the event of abuse.

 

2

AB

u

[GA-D01-R46]

[gTLD registration directory services] must provide real-time access to credentialed requestors via multiple methods. Access credentials issued during accreditation must be suitable for use with all defined access methods.

 

2

AB

u

[GA-D01-R47]

“best practices may be defined for credential management; Accreditors must be expected to adhere to best practices.”

 

2

AB

u

[GA-D01-R48]

gTLD registration directory services “must require individual credentials for authenticated access.”

 

1

AB

u

[GA-D01-R49]

“Authenticated access [to gTLD registration data] must not be transitive (i.e., an authenticated user shall not share gated data with others outside of its accreditation).”

 

2

AB

u

[GA-D01-R50]

“A process for responsible revelation of gated data to further the original purpose it was requested for must be created and enforced.”

Depends on Original Purpose

2

AB

s

[GA-D01-R51]

“An organization seeking access to [gTLD registration] data must be able to apply for user accreditation and have all people using the registration directory service in their organization covered by that one accreditation, [accepting responsibility] for managing accredited access within its own organization.”

 

3

AB

u

[GA-D01-R52]

“Audits and data analytics must be used to identify abuse of the system and access credentials.”

 

2

L

z

[GA-D01-R53]

“An appeals process must be defined to allow [gTLD registration directory services] users to refute abuse allegations when seeking to reactive/reinstate access credentials.”

 

2

AB

u

[GA-D01-R54]

“Every Registrant must receive a credential to be able to examine their own contact data as stored by the [gTLD registration directory service] in relation to domain names that are registered to them.”

 

1, 2

AB

u, e

[GA-D01-R55]

“A process for adding additional accreditors that either supplement current processes or offer new, innovative ways to provide user accreditation for approved purposes of the [gTLD registration directory service] must be established.”

 

3

AB

u

[GA-D04-R01]

If there is gated access, the [gTLD registration directory service] must feature strong encryption.

 

1

G

x

[GA-D04-R02]

The [gTLD registration directory service] must not be engineered to contain any back-doors. by introducing a technical input into an encryption product that would enable any party, even authorities, access to data, would also make encrypted data vulnerable to criminals, terrorists and foreign intelligence services, among others. This would have an undesirable consequence for the security of data stored in the [gTLD registration directory service].

Should this be duplicated as [SM-D04-R01]?

1

G

x

[GA-D05-R01]

"The WHOIS protocol has no provisions for strong security. WHOIS lacks mechanisms for access control, integrity, and confidentiality. Accordingly, WHOIS-based services should only be used for information which is non-sensitive and intended to be accessible to everyone." (From Section 5: Security Considerations) This text implies that there should be a requirement to provide services for access control, integrity, and confidentiality. It also suggests that [gTLD registration directory services] should not be used to access sensitive information.

Same as [UP-D05-R01] [PR-D05-R01], Depends on Access PR(s) for Public Access

1, 3

AB

u, l, d

[GA-D08-R01]

Accredited Requestors may pre-identify purposes that will apply to all or some of their queries over a specified time frame.

Variant of [GA-D01-R15]

3

AB

u

[GA-D08-R02]

Other than in exceptional circumstances, accreditation of users for access to [gTLD registration] data should take place in real time.

Variant of [GA-D01-R37]

3

AB

u

[GA-D08-R03]

A process for responsible sharing of gated [gTLD registration] data within an accredited requester organization, with its affiliates, with its clients, or with similar third parties must be created and enforced.

Variant of [GA-D01-R50]

3

AB

u

[GA-D18-R01]

based on the WHOIS Inter-Registrar Transfer Policy, Section I.A.1.1: “The Administrative Contact and the Registered Name Holder, as listed in the Losing Registrar's or applicable Registry's (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. Registrars may use WHOIS data from either the Registrar of Record or the relevant Registry for the purpose of verifying the authenticity of a transfer request; or from another data source as determined by a consensus policy.”

 

1

IB

k

[GA-D19-R01]

based on the ICANN Governmental Advisory Committee (GAC) proposed principles, gTLD [registration directory] services "should provide (…) data (…) in a manner that (…) facilitates continuous, timely and world-wide access" (para 3.3, sub 2)

 

1

AB

u

[GA-D26-R01]

According to the Directive (18 ), whereas, in order to ensure that individuals are not deprived of the protection to which they are entitled under this Directive, any processing of personal data in the Community must be carried out in accordance with the law of one of the Member States; whereas, in this connection, processing carried out under the responsibility of a controller who is established in a Member State should be governed by the law of that State;

Same as [CM-D26-R03], Depends on Definition of personal data such as [DE-D26-R09]

1

EA

m, ab

[GA-D26-R02]

According to the Directive (39 ), whereas, certain processing operations involve data which the controller has not collected directly from the data subject; whereas, furthermore, data can be legitimately disclosed to a third party, even if the disclosure was not anticipated at the time the data were collected from the data subject; whereas, in all these cases, the data subject should be informed when the data are recorded or at the latest when the data are first disclosed to a third party;

Same as [UP-D26-R09] [PR -D26-R07] [SM-D26-R04]

1

BA, IA

c, at

[GA-D26-R03]

According to the Directive (41 ), whereas, any person must be able to exercise the right of access to data relating to him which are being processed, in order to verify in particular the accuracy of the data and the lawfulness of the processing; whereas, for the same reasons, every data subject must also have the right to know the logic involved in the automatic processing of data concerning him, at least in the case of the automated decisions referred to in Article 15 (1); whereas this right must not adversely affect trade secrets or intellectual property and in particular the copyright protecting the software; whereas these considerations must not, however, result in the data subject being refused all information;

Same as [UP-D26-R10, [DA-D26-R02]

1

EA

e

[GA-D26-R04]

According to the Directive (56 ), whereas, cross-border flows of personal data are necessary to the expansion of international trade; whereas the protection of individuals guaranteed in the Community by this Directive does not stand in the way of transfers of personal data to third countries which ensure an adequate level of protection; whereas the adequacy of the level of protection afforded by a third country must be assessed in the light of all the circumstances surrounding the transfer operation or set of transfer operations;

Same as [UP-D26-R13] [CS-D26-R04], Depends on Definition of personal data such as [DE-D26-R09], Privacy PR(s) on Adequacy

1

EA

m

[GA-D26-R05]

According to the Directive (57 ), whereas, on the other hand, the transfer of personal data to a third country which does not ensure an adequate level of protection must be prohibited;

Same as [DE-D26-R08], Depends on Definition of personal data such as [DE-D26-R09]

1

EA

m

[GA-D26-R06]

According to the Directive (58 ), whereas, provisions should be made for exemptions from this prohibition in certain circumstances where the data subject has given his consent, where the transfer is necessary in relation to a contract or a legal claim, where protection of an important public interest so requires, for example in cases of international transfers of data between tax or customs administrations or between services competent for social security matters, or where the transfer is made from a register established by law and intended for consultation by the public or persons having a legitimate interest; whereas in this case such a transfer should not involve the entirety of the data or entire categories of the data contained in the register and, when the register is intended for consultation by persons having a legitimate interest, the transfer should be made only at the request of those persons or if they are to be the recipients;

Same as [DE-D26-R08], Depends on Legitimate Interest

1

EA

m

[GA-D26-R07]

According to the Directive , where the data have not been obtained from the data subject, Member States shall provide that the controller or his representative must at the time of undertaking the recording of personal data or if a disclosure to a third party is envisaged, no later than the time when the data are first disclosed provide the data subject with at least the following information, except where he already has it:

(a) the identity of the controller and of his representative, if any;

(b) the purposes of the processing;

(c) any further information such as

  • the categories of data concerned,
  • the recipients or categories of recipients,
  • the existence of the right of access to and the right to rectify the data concerning him
    in so far as such further information is necessary, having regard to the specific circumstances in which the data are processed, to guarantee fair processing in respect of the data subject.

[The above requirement] shall not apply where, in particular for processing for statistical purposes or for the purposes of historical or scientific research, the provision of such information proves impossible or would involve a disproportionate effort or if recording or disclosure is expressly laid down by law. In these cases Member States shall provide appropriate safeguards.

Same as [UP-D26-R34], Depends on Permissible Purposes, Permissible Users, Access PR(s), Data Element PR(s), Definition of personal data such as [DE-D26-R09]

1

EA

m

[GA-D28-R01]

The definition of a Data Controller under the EU Privacy Directive requires that the Data Controller ensure that “the privacy rights of individuals supplying their personal data must be respected by anyone collecting and processing that data.” [This definition requires that any] gates created [must] ensure that a Registrant in the EU or other data protection country has their data processed through the gates in accordance with their national laws, e.g., EU Data Protection Directive .

Variant of [UP-D28-R02], Depends on Definition of personal data such as [DE-D26-R09], Data Protection Directive

1

A, IA, EA

a, d, m

[GA-D29-R01]

Each data controller must respect the following rules as set out in the Directive : Personal Data must be processed legally and fairly.

Depends on Definition of personal data such as [DE-D26-R09]

1

IA, EA

d, m

[GA-D30-R01]

The requirement for a third country to ensure an adequate level of data protection was further defined by the CJEU in Schrems…It also indicated that the wording ‘adequate level of protection’ must be understood as “requiring the third country in fact to ensure, by reason of its domestic law or its international commitments, a level of protection of fundamental rights and freedoms that is essentially equivalent to that guaranteed within the European Union by virtue of the Directive read in the light of the Charter” pg.10

Same as [UP-D30-R02] [PR-D30-R05] [ CM-D30-R03]

1

A, IA

a, d

[GA-D30-R02]

WP29 stresses that any interference with the fundamental rights to private life and data protection need to be justifiable in a democratic society. The CJEU criticised the fact that the Safe Harbour decision did not contain any finding regarding the existence, in the United States, of rules adopted by the State intended to limit any interference. Nor does it refer to the existence of effective legal protection against interference of that kind.pg 11

Same as [UP-D30-R04] [GA-D30-R03] [DE-D30-R03] [PR-D30-R07] [CX-D30-R02] [SM-D30-R02] [RI-D30-R03]

1

IA

d

[GA-D30-R03]

WP29 stresses that any interference with the fundamental rights to private life and data protection need to be justifiable in a democratic society. The CJEU criticised the fact that the Safe Harbour decision did not contain any finding regarding the existence, in the United States, of rules adopted by the State intended to limit any interference. Nor does it refer to the existence of effective legal protection against interference of that kind.pg 11

Same as [UP-D30-R04] [GA-D30-R02] [DE-D30-R03] [PR-D30-R07] [CX-D30-R02] [SM-D30-R02] [RI-D30-R03] – delete duplicate?

1

IA

d

[GA-D30-R04]

In order to evaluate if any interference would be justifiable in a democratic society, the assessment was conducted in light of the European jurisprudence on fundamental rights which sets four essential guarantees for intelligence activities as listed in [UP-D30-R05]

Same as [UP-D30-R05] [PR-D30-R08] [ SM-D30-R03]

1

IA

d

[GA-D30-R05]

Privacy Shield documents make use of terminology that is not consistent with the vocabulary generally used in the EU when dealing with data protection. This is not necessarily a problem, as long as it is clear what the corresponding terminology under EU law (and under U.S. law) would be. The WP29 regrets to note however this is not the case, including in the draft adequacy decision. For example, the word ‘access’ is used in chapter 3 of the draft adequacy decision in a sense that implies the collection of personal data, instead of allowing someone to see data that is already collected. Access by companies to the data and the individuals’ right of access are two separate notions that should not be confused. pg. 13

Related to [UP-D26-R10], Depends on Definition of personal data such as [DE-D26-R09]

1

EA, EC

m, ab

[GA-D30-R06]

The Privacy Shield does not provide any legal guarantees where individuals are subject to a decision which produces legal effects concerning or significantly affecting them and which is based solely on automated processing of data intended to evaluate certain personal aspects relating to them, such as their performance at work, creditworthiness, reliability, conduct, etc. The necessity to provide for legal guarantees for automated decisions (producing legal effects or significantly affecting the individual) in order to provide an adequate level of protection has already been underlined by the WP29 in its Working Document 12.pg 18

 

1

EA, EC

m, ab

[GA-D30-R07]

4.2.1 Access by law enforcement authorities to personal data should be in accordance with the law and based on clear, precise and accessible rules. pg.53

Same as [UP-D30-R21], Similar to [UP-D30-R06], Depends on Definition of personal data such as [DE-D26-R09], Laws and Rules

1

CC

q

[GA-D30-R08]

Since all applicable rules to limit access by law enforcement authorities to data transferred under the Privacy Shield are based on the Constitution, on statutory law and on transparent policies of the Department of Justice, a presumption of accessibility of these rules is taken into account by the WP29. However, the clarity and precision of the rules can only be assessed in each individual type of procedure and request for access. The WP29 therefore regrets to note that, based on the available details in Annex VII to the Privacy Shield and the findings in the draft decision, such an assessment cannot be done at this moment. pg 53

Same as [UP-D30-R22], Depends on Constitution, Law, DoJ Policies, Privacy Shield

1, 2

CC

q

[GA-D30-R09]

According to the settled case-law of the CJEU, the principle of proportionality requires that the legislative measures proposing interferences with the rights to private life and to the protection of personal data “be appropriate for attaining the legitimate objectives pursued by the legislation at issue and do not exceed the limits of what is appropriate and necessary in order to achieve those objectives” Therefore, the assessment of necessity and proportionality is always done in relation to a specific measure envisaged by legislation. pg. 54

Same as [UP-D30-R24] [DE-D30-R11] [PR-D30-R15], Depends on Definition of personal data such as [DE-D26-R09] , Legitimate Objectives

1, 2

EA

r

[GA-D32-R01]

The specifications below are recommended requirements for registries. These requirements include an independently-tested, functioning Database and Communications System that:

Precedes [GA-D32-R02 to R03], Should this be duplicated as [SM-D32-R01]?

1

AB, G

u, x

[GA-D32-R02]

* Allows multiple competing registrars to have secure access (with encryption and authentication) to the database on an equal (first-come, first-served) basis. (may also apply to System Model)

Supports [GA-D32-R01], Should this be duplicated as [SM-D32-R02]?

1

AB

u

[GA-D32-R03]

* Provides free access to the software and customer interface that a registrar would need to register new second-level domain names. (may also apply to System Model charter question)

Supports [GA-D32-R02], Should this be duplicated as [SM-D32-R03]?

1

G

x

[GA-D32-R04]

The specifications below are recommended requirements for registrars. These requirements include a functioning Database and Communications System that supports secure access (with encryption and authentication) to the registry. (may also apply to Privacy charter question)

Should this be duplicated as [PR-D32-R01]?

1

G

x

[GA-D34-R01]

[gTLD registration directory services policies must consider this question:] How can we ensure in a centralized [or any other] Gated Access environment that law enforcement and lawyers and others seeking access to personal and/or sensitive data who are operating legally within the scope of their jurisdiction and authority?

 

1, 2

CA, CC

j, q

[GA-D34-R02]

[gTLD registration directory services policies must consider this question:] In a Gated Access environment, how can we prevent access to the personal and/or sensitive data by those seeking to investigate matters that are not crimes or illegalities in the country of the Registrant or Registrar?

 

1, 2

AB, IA

s, d

[GA-D34-R03]

[gTLD registration directory services policies must consider this question:] In a Gated Access environment, how can we ensure that those who abuse their access to massive amounts of data are prosecuted, and by someone other than the Registrant, who is unlikely to have the resources to address such matters. How does ICANN take on responsibility for the gTLD registration directory service, and liability for any abuses or misuses?

 

1, 2

AB, L, IA

s, v, d

[GA-D42-R01]

RFC 7482, Section 7, Security Considerations, specifies "Search functionality typically requires more server resources (such as memory, CPU cycles, and network bandwidth) when compared to basic lookup functionality. This increases the risk of server resource exhaustion and subsequent denial of service due to abuse. This risk can be mitigated by developing and implementing controls to restrict search functionality to identified and authorized clients." This provides a possible requirement: A registration directory service must provide features to identify and authorize clients.

 

1, 3

AB, L

u, v, z

[GA-D42-R02]

RFC 7482, Section 7, Security Considerations, specifies "Search functionality also increases the privacy risk of disclosing object relationships that might not otherwise be obvious." This provides a possible requirement: A registration directory service must provide features to restrict information returned to clients on a "need to know" basis.

Precedes [GA-D42-R03 to R04]

1

?

?

[GA-D42-R03]

* A registration directory service must include features that address the deficiencies of WHOIS, including lack of standardized command structures, lack of standardized output and error structures, lack of support for internationalization and localization, and lack of support for user identification, authentication, and access control.

Supports [GA-D42-R02], Related to [GA-D01-R31 to R33] [DA-D02-R02] [DE-D09-R01] [DE-D02-R01]

1

F

y

[GA-D42-R04]

* A registration directory service must be able to support queries for reverse DNS metadata by domain, name servers by name, registrars by name, and entities (such as contacts) by identifier.

Supports [GA-D42-R02]

1

BA

c

[GA-D41-R01]

RFC 7481: Security Services for the Registration Data Access Protocol (RDAP), Section 3.1, Access Control, specifies that "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." This provides a possible requirement: A registration directory service must be able to return information that identifies the access granted to the client. (May also be related to Users/Purposes)

Should this be duplicated as [UP-D41-R01]?

1

A, AB

a, u

[GA-D41-R02]

RFC 7481, Section 3.2, Authentication, specifies that "RDAP clients and servers MUST implement the authentication framework specified in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]." This provides a possible requirement: Registration directory service servers must be able to authenticate themselves to clients using HTTPS or a mechanism that provides an equivalent level of server authentication. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R01]?

3

AB

u

[GA-D41-R03]

RFC 7481, Section 3.2, Authentication, specifies that "If the "basic" scheme is used, HTTP over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while in transit..." This provides a possible requirement: Connections between registration directory service clients and registration directory service servers must be encrypted to prevent inadvertent disclosure of information to passive eavesdropping attacks. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R02]?

1

AB

u

[GA-D41-R04]

RFC 7481, Section 3.2, Authentication, specifies that "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." (May also be related to Privacy)

Should this be duplicated as [PR-D41-R03]?

2

AB

u

[GA-D41-R05]

RFC 7481, Section 3.2, Authentication, specifies that "transports for RDAP must either provide a TLS-protected transport (e.g., HTTPS) or a mechanism that provides an equivalent level of server authentication." This provides a possible requirement: A registration directory service must be able to support client authentication using HTTP basic and Digest authentication. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R04]?

2

AB

u

[GA-D41-R06]

RFC 7481, Section 3.2.1, Federated Authentication, specifies that "Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP." This provides a possible requirement: Federated authentication systems used by A registration directory service must be fully supported by HTTP. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R05]?

3

AB

u

[GA-D41-R07]

RFC 7481, Section 3.3, Authorization, specifies that "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." This provides a possible requirement: A registration directory service must provide granular access controls in order to implement authorization policies. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R06]?

2

AB

u

[GA-D41-R08]

RFC 7481, Section 3.5, Data Confidentiality, specifies that “HTTP over TLS MUST be used to protect all client-server exchanges unless operational constraints make it impossible to meet this requirement." This provides a possible requirement: A registration directory service must use HTTP over TLS to protect all client-server exchanges. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R07]?

3

AB

u

[GA-D50-R01]

According to the Singapore GAC Communiqué of February 11, 2015, the ICANN board should amend the current process for requests to release two-letter codes to establish an effective notification mechanism, so that relevant governments can be alerted as requests are initiated. (Page 5)

Relevance to RDS?

?

?

?

[GA-D50-R02]

The ICANN board should extend the comment period referred to by [GA-D50-R01] to 60 days.

Relevance to RDS?

?

?

?

[GA-D50-R03]

The changes recommended by [GA-D50-R01] and [GA-D50-R02] should be implemented before proceeding with pending and future requests [to release two-letter codes]; a list of GAC Members who intend to agree to all requests and do not require notification should be published on the GAC website. (Page 6)

Relevance to RDS?

?

?

?

[GA-D54-R01]

According to SAC051, the ICANN community should develop a uniform and standard framework for accessing registration data that would provide mechanisms to define and implement a range of credential services.

 

1

AB

s, t, u

[GA-D54-R02]

The ICANN community should develop a uniform and standard framework for accessing registration data that would provide mechanisms to define and implement a range of access control capabilities.

 

1

AB

s, t, u

[GA-D61-R01]

According to Carlton Samuels’ blog on building a better WHOIS for individual registrants, [there should be] no anonymous public access to gTLD registration data.

 

1

AB

s, t

[GA-D61-R02]

Access should be “limited to those with a need to know, and requestors who access data will be held accountable for proper use.”

 

1

AB

s

[GA-D61-R03]

[There should be] “Registrants will have more flexibility and control over what data is public.”

 

1

H

as


See Additional Key Inputs for this charter question ( hyperlinked on this Wiki page ) which may be consulted as a potential source of possible requirements. The PDP WG may also identify additional sources by themselves or through community outreach.

Data Accuracy (DA)

The following possible requirements address the charter question on Data Accuracy (DA):
What steps should be taken to improve data accuracy?

The process framework for this question (below) can be applied to categorize possible requirements into three phases:

 

In the grid below, we identify the possible requirement for WG deliberation, any prerequisites or dependencies contained in that possible requirement , and whether the possible requirement therefore falls into Phase 1, 2, or 3. Policies designed to meet Phase 1 policy requirements should be considered in Phase 2 , while implementation or coexistence guidance for Phase 2 policies should be considered in Phase 3 . In addition, an initial attempt has been made to group similar requirements by code (C) and keyword (K) , allowing the table to be easily re-sorted or filtered – see Annex B for definitions.

QQ-D#-R#

Possible Requirement

Prerequisites/Dependencies

Ph

C

K

[DA-D01-R01]

“Standard validation [must be applied] to all gTLD registration data. In addition to periodic checks, validation would occur at the time of collection, with an option to pre-validate blocks of contact data for reuse in multiple domain name registrations.” (top of p.69)

DEPENDENCIES NOT YET ADDED TO THIS COLUMN EXCEPT WHERE PRs ARE DUPLICATES

1, 2

DB

n, aa

[DA-D01-R02]

“The [gTLD registration directory services] ecosystem must include a pre-validated Contact Directory, conceptually separate from the Domain Name Directory, to promote the quality and reusability of data elements used to contact domain name Registrants and people or organizations that can be designated by Registrants as contacts for various purposes associated with a domain name registration, and to deter the fraudulent use of personal data.” (top of p.69)

Depends on Definition of personal data such as [DE-D26-R09]

1

DB, EA

n, aa, e

[DA-D01-R03]

[gTLD registration directory services must support a] Pre-validation process (Section b on pp.71-72)

 

1

DB

aa

[DA-D01-R05]

[gTLD registration directory services must support an] Accuracy, Audit & Remediation Process (Section c on pp. 72-73)

 

1

L

z

[DA-D01-R06]

[gTLD registration directory services must include an] Operational Framework for Contact IDs (Section d on pp. 74-75)

 

1, 2

DA

b

[DA-D01-R07]

[gTLD registration directory services must have specified] Principles for Interaction between Contact Holders & Validators 83-89 (pp. 75-76)

Precedes [DA-D01-R08 to R14]

2

DB

ae

[DA-D01-R08]

* [To create and maintain] any given Contact, a Contact Holder may choose any Validator.

Supports [DA-D01-R07]

1

DB

ae

[DA-D01-R09]

* Oversight and accountability policies related to the management of Contacts must be developed.

Supports [DA-D01-R07]

1

DA

b, f

[DA-D01-R10]

* Contact Holders must be able to modify the contact information…through the issuing Validator.

Supports [DA-D01-R07]

1

DA, DB

f, ae

[DA-D01-R11]

* Validators must use Contact Holder authentication to deter unauthorized modification of contact information. Validators may offer multiple levels of Contact Holder authentication.

Supports [DA-D01-R07]

2

AB, DB

u, ae

[DA-D01-R12]

* Contact Holders must be able to choose providers based on cost/benefit propositions tied to ease-of-use, security, costs, and other logical business factors.

Supports [DA-D01-R07]

1

BB

ac

[DA-D01-R13]

* Validators must publish their policies on authentication in a manner that can be utilized globally for reputation management [to] encourage better accuracy and accountability.

Supports [DA-D01-R07]

2

DB, IA

ae, d

[DA-D01-R14]

* Validators must be able to validate contact information submitted in the Contact Holder’s native language [to] improve accuracy of native-language data and support scalability of the domain name registration system into a multi-lingual environment.

Supports [DA-D01-R07]

1

DA

af

[DA-D01-R15]

[gTLD registration directory services must have specified] Principles for Contact Validation 90-104 (pp.76-78)

Precedes [DA-D01-R16 to R29]

1

DA

b

[DA-D01-R16]

* All contact data elements must be validated at a syntactic level. This represents a base-level of validation that must be achievable by any entity in the industry.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R17]

* All mandatory contact data elements for a particular purpose must be validated operationally before that contact can be included in domain name registration data for that purpose.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R18]

* A Contact Holder must be able to voluntarily seek optional higher levels of validation (e.g., optional identity validation), bearing associated costs in return for perceived benefits (e.g., greater consumer confidence in domain names registered to identity-validated entities).

Supports [DA-D01-R15]

2

DA, F

af, aj

[DA-D01-R19]

* Given costs involved with optional identity validation, a low-cost mechanism for economically disadvantaged Contact Holders to receive optional identity validation is desirable.

Supports [DA-D01-R15]

3

DA, KA

af, ag

[DA-D01-R20]

* In order to preserve associations and allow for a correction process, contact data can have a status of “inaccurate” and remain in the system.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R21]

* Validation Status of contact data must be tracked and published as appropriate [in the registration directory service], along with the most recent time the validation status was determined.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R22]

* Third parties may file inaccuracy reports to challenge the Validation Status of contact data, triggering a standard remediation process that may result in the contact being flagged as “inaccurate” and in further consequences for domain names using that contact data.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R23]

* Active domains cannot have a mandatory contact with an “inaccurate” status without some sort of remediation.

Supports [DA-D01-R15]

1

DA

af

[DA-D01-R24]

* A minimum level of cross-field validation must be checked for all contact data elements associated with contacts where cross-field validation is applicable (e.g. physical address).

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R25]

* Revalidation of contact data must be carried out on a regular basis to ensure data is accurate at the declared level.

Supports [DA-D01-R15]

1

DA

af

[DA-D01-R26]

* If a Contact Holder provides optional data elements, those elements must be at least syntactically validated. Optional data elements must not be validated beyond syntax unless the Contact requests and presumably pays for any costs associated with such validation.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R27]

* The level of validation achieved beyond syntactical validation for data elements that can be operationally- or (optionally) identity-validated must be recorded and maintained by the Validator.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R28]

* The Validator must determine and publish [in the gTLD registration directory service] the overall validation status achieved by each contact.

Supports [DA-D01-R15]

2

DB

ae

[DA-D01-R29]

* For any data element that has undergone validation, the timestamp of that validation must also be recorded and maintained.

Supports [DA-D01-R15]

2

DA

af

[DA-D01-R30]

[gTLD registration directory services must offer an optional] Unique Contact Data Capability (Section g on p.78)

 

2

DA

f, ah

[DA-D01-R31]

“To allow for much greater accuracy across such a diverse space and ease-of-use for such contacts, it is desirable to provide mechanisms to allow easy use of such contacts by multiple Registrants; for example, a web hosting company providing their NOC’s unique ID for “technical” and “abuse” contacts for domains controlled by their customers.” (bottom of p.69) [Also included as a possible benefits requirement]

 

3

DA

f, ah

[DA-D01-R32]

“. . when such an entity needs to update their contact information to reflect a new address/phone number or a merger/acquisition, it must be easy to update that information in one place and have that reflected to all domains associated with that contact data set (as designated by a unique identifier).” (Top of p.70) [Also included as a possible benefits requirement]

 

1

DA

f, ah

[DA-D02-R01]

"An accuracy policy should define each data element and require that it be examined and indicate for each element a method for determining the level of accuracy of the data."

 

1

DB

n

[DA-D02-R02]

"Policies with respect to the accuracy of registration data should apply equally to all registration data without regard to whether it is internationalized or ASCII registration data."

Related to [GA-D01-R31 to R33] [GA-D42-R03] [DE-D09-R01] [DE-D02-R01]

1

DB

n

[DA-D06-R01]

Upon receiving any updates to the data elements listed in [RAA] Subsections 3.3.1.2, 3.3.1.3, and 3.3.1.5 through 3.3.1.8 from the Registered Name Holder, Registrar shall promptly update its database used to provide the public access described in [RAA] Subsection 3.3.1.

 

2

F

h

[DA-D06-R02]

Registrar shall comply with the obligations specified in the [gTLD registration directory service] Accuracy Program Specification. In addition, notwithstanding anything in the Accuracy Program Specification to the contrary, Registrar shall abide by any Consensus Policy requiring reasonable and commercially practicable (a) verification, at the time of registration, of contact information associated with a Registered Name sponsored by Registrar or (b) periodic re-verification of such information. Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy.

 

2

DB

n

[DA-D08-R01]

All mandatory contact data elements for a particular purpose must be validated operationally before the corresponding registration is activated.

Variant of [DA-D01-R17]

1, 2

DA

af

[DA-D09-R01]

The WHOIS RT recommends fulfillment of data accuracy objectives over time. Specifically [as detailed in [DA-D09-R02 to R04]

Precedes [DA-D09-R02 to R04]

1

DB

n

[DA-D09-R02]

* The [WHOIS RT] notes that the focus of its recommendations is on the desired outcome that ICANN work to improve the accuracy of [gTLD registration] data. [Data] validation or verification would be one possible means to achieve this objective, whereas our intention is to allow latitude in how the objective is achieved.

Supports [DA-D09-R01]

1

DB, DA

n, af

[DA-D09-R03]

* based on review of a study on data accuracy that ICANN asked the National Opinion Research Council of the University of Chicago to provide (“NORC WHOIS Data Accuracy Study 2009/10”), the WHOIS RT recommended that ICANN pursue a “contactability standard” for data accuracy in the WHOIS – enough accurate data elements for the Registrant to be contacted (minimal data elements).

Supports [DA-D09-R01]

2

DB, DA

n, af

[DA-D09-R04]

* In Recommendation 6, the WHOIS RT recommended that ICANN should take appropriate measures to reduce the number of WHOIS registrations that fall into the accuracy groups Substantial Failure and Full Failure (as defined by the NORC Data Accuracy Study, 2009/10) by 50% within 12 months and by 50% again over the following 12 months. (Refer to the NORC study for definitions of Substantial and Full Failure.)

Supports [DA-D09-R01]

2

DB

n

[DA-D10-R01]

In SAC058, a report to the ICANN board from the Security and Stability Advisory Committee (SSAC) concerning the issue of domain name registration data quality, the SSAC examines the feasibility and suitability of improving registration data accuracy through validation, offering the following possible Data Accuracy requirements.

 

1

DB, DA

n, af

[DA-D10-R02]

[ICANN should] identify [registration data] validation techniques that can be automated and develop policies that incent the development and deployment of those techniques. (Page 4)

 

1

DA

af

[DA-D10-R03]

To improve registration data accuracy, there needs to be 1) an incentive for the registrant to submit accurate data, or 2) efforts by registry / registrar to follow up and check the accuracy of the submitted data; or 3) both. (Page 5)

 

1

DB

n

[DA-D10-R04]

[As further detailed below, registration data should undergo] Syntactic Validation: Assess [registration] data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use. (Page 7)

 

2

DA

af

[DA-D10-R05]

[As further detailed below, registration data should undergo] Operational Validation: Assess that [registration] data correspond to the intended use in their routine functions (e.g. check that an email address or phone number can receive email or phone calls, check that a postal address can receive postal mail, etc.). (Page 8)

 

2

DA

af

[DA-D10-R06]

[As further detailed below, registration data should undergo] Identity Validation: Assess that [registration] data corresponds to the real world identity of the registrant entity. (Page 8)

 

2

DA

af

[DA-D10-R07]

[ICANN should] Determine the length of time before the validation of changes to contact information must be repeated. (Page 8-9)

 

1

DA

af

[DA-D10-R08]

Name validation should be implemented as follows:

  • Syntactic Validation: To achieve effective syntactic validation of a name as one of the contact information elements, the script (or writing system) used for a name element must be known. If it is, confirming that the syntax conforms to the script is possible and can be automated. However, the language of a name cannot be determined precisely as many languages share the same script. (Page 9)
  • Operational Validation: Create exception lists for auditing purposes in order to facilitate the process of operational validation of names because names in the world are diverse and it may not be possible to operationally verify a name automatically. (Page 10)
  • Identity Validation: Require the submission of physical documentation issued by a government authority to verify that registration data contact information corresponds to a real world entity. (Page 10)

 

2

DA

af

[DA-D10-R09]

Email address validation should be implemented as follows:

  • Syntactic Validation: Syntax for a valid email address (defined as per RFC 5322) and syntax for a valid internationalized email address (defined as per PRFs 6530-33) should be checked automatically. (Page 10)
  • Operational Validation: Having in mind that an email address is defined as a string composed of a Left Hand Side (LHS) and Right Hand Side (RHS) separated by the at-symbol (@), verify that an email address is operational implementing several checks (e.g. with respect to the RHS check that the domain name exist in the DNS while with respect to the LHS check that the endpoint SMTP accepts an email message for the recipient specified at the LHS). (Page 10)
  • An effective verification technique of an email address is to attempt to deliver an email message that requires explicit user action. In this technique, an email address should not be considered valid until the user receives and performs some action described in the email, such as clicking on a web link or replying to the message in a specified way. Note that sometimes anti-spam measures could still block these verification emails. (Page 11)
  • Identity Validation: In order to verify that an email address is used exclusively by a particular registrant, contact the registrant using an out-of-band method, i.e., contacting the registrant without using email (e.g. two possibilities are using the postal information or the telephone information to contact the registrant). (Page 11)

 

2

DA

af

[DA-D10-R10]

Telephone number validation should be implemented as follows:

  • Syntactic Validation: Perform automatic checks to determine if a telephone number complies with the E.164 standard (E.164 is an ITU-T recommendation that defines the international public telecommunication numbering plan used in the PSTN and some other data networks). (Page 11)
  • Operational Validation: Verify E.164 formatted PSTN addresses (telephone numbers) by leveraging PSTN databases. (Page 11)
  • Use the Short Message Service (SMS) to verify a phone number (works only for cellular numbers). (Page 12)
  • Identity Validation: In order to verify that a telephone number is used exclusively by a particular registrant, contact the registrant using an out-of-band method, i.e., contacting the registrant without using the telephone number (e.g. two possibilities are using the postal information or the email address to contact the registrant). (Page 12)

 

2

DA

af

[DA-D10-R11]

Postal address validation should be implemented as follows:

  • Syntactic Validation: The EPP standard defines an opaque container and loose constraints that can support internationalized postal addresses.
  • Operational Validation: Verify postal addresses by leveraging postal databases. There are about 200 such databases in the world with about 20 (G20 major economies) being highly accurate. (Page 13)
  • Deliver a postal message to a postal address in order to verify with a high level of certainty that the postal address is valid. (Page 13)
  • Identity Validation: In order to verify that a postal address is used exclusively by a particular registrant, contact the registrant using an out-of-band method, i.e., contacting the registrant without using the postal address (e.g. two possibilities are using the telephone number or the email address to contact the registrant). (Page 13)

 

2

DA

af

[DA-D11-R01]

The accuracy of [gTLD registration data] must be assessed by asking the following questions. Answers in the negative indicate inaccurate data.   The criteria are based on the obligations contained in the 2009 and 2013 RAA.[as detailed in [DA-D11-R02 to R04]

Precedes [DA-D11-R02 to R04]

3

DB

n

[DA-D11-R02]

* Phase One: Syntax Validation must be performed on gTLD registration data elements that are email addresses, as follows: Does the email address only contain permissible characters? (i.e., as provided for within the RFC 5322) Is there presence of an “@” symbol in the email address? Is there presence of a domain component? Is the domain component in a TLD, which is resolvable on the Internet? (see IANA’s Root Zone Database: http://www.iana.org/domains/root/db ) Is the domain component syntactically valid? (i.e., the component following the “@” symbol meets requirements) Is there presence of local component? (i.e., the characters preceding the “@” symbol)

Supports [DA-D11-R01]

3

DA

af

[DA-D11-R03]

* Phase One: Syntax Validation must be performed on gTLD registration data elements that are telephone numbers, as follows: Is there presence of a phone number? (not required for registrant field for 2009 RAA) Is there presence of a country code? Is the country code syntactically valid? (not required for 2009 RAA) Does the phone number contain at least the minimum allowed digits based on the country code? Does the phone number contain an appropriate amount of digits based on the country code? Does the phone number only contain permissible numbers and formatting characters? if there is an extension does it only contain permissible numbers and formatting characters?

Supports [DA-D11-R01]

3

DA

af

[DA-D11-R04]

* Phase One: Syntax Validation must be performed on gTLD registration data elements that are postal addresses, as follows: Is there presence of a postal address? Is there presence of a country? Is the country identifiable? Is the country provided in the Country field? (not required for 2009 RAA) Is the country syntactically valid? (i.e., meets ISO 3166-1: Alpha 2-code format) (not required for 2009 RAA) If the country uses a postal code system, is the code syntactically valid and in the right field? If a country requires a state or province, is a state listed and is it syntactically valid? (not required for 2009 RAA) Is there presence of a city? Is there presence of a street?

Supports [DA-D11-R01]

3

DA

af

{DA-D12-R01]

Data in the [gTLD registration directory service] must be synchronized, i.e., updated in an immediate and accurate manner so that all data sets (e.g., registrar and registry) are exact duplicates. (sec. 5.7)

 

1, 2

DB, F

n, ai

[DA-D12-R02]

The [gTLD registration directory service] must include features to reduce the risk of inconsistencies between data sets held by different parties (i.e., synchronization failures). (sec. 5.7)

 

1

F

ai

[DA-D12-R03]

The [gTLD registration directory service] must specify the single data set (among multiple data sets) to be relied upon in case of doubt (i.e., the authoritative data). (sec. 5.8) [may also relate to Users/Purposes]

Should this be duplicated as [UP-D12-R01]?

1

F, AC

ai, aj

[DA-D12-R04]

To the extent the [gTLD registration directory service] involves a hierarchical database structure, it must specify the single database within that structure that holds the data that is assumed to be the final authority regarding the question of which record shall be considered accurate and reliable in case of conflicting records (i.e., the authoritative data). (sec. 5.8) [may also relate to Users/Purposes]

Should this be duplicated as [UP-D12-R02]?

3

F, AC

ai, aj

[DA-D15-R01]

ICANN’s Uniform Domain Name Dispute Resolution Policy (UDRP) requires registrant information taken from [gTLD registration directory services] for the disputed domain name to be accurate to meet UDRP-related Data Element requirements - see [DE-D15-R01] through [DE-D15-R03].

Related to [UP-D01-R12]

1

DB

n

[DA-D15-R02]

ICANN’s UDRP makes Domain Registrant liable to provide complete & accurate statements, including contact information, which forms part of Domain WHOIS, by default. Specifically, registrants who apply "to register a domain name​, or to maintain or renew a domain name registration, [must] represent and warrant... that (a) the statements ... made in [their] Registration Agreement are complete and accurate.” (UDRP policy, Paragraph 20)

Related to [UP-D01-R12]

1

DB

n

[DA-D16-R01]

*ICANN’s Uniform Rapid Suspension (URS) policy requires registrant information taken from [gTLD registration directory services] for the disputed domain name to be accurate for proper completion of the Complaint, for proper service of hard copy Notice, and to meet additional URS-related Data Element requirements - see [DE-D16-R01] through [DE-D16-R09].

 

1

DB

n

[DA-D18-R01]

based on the WHOIS Inter-Registrar Transfer Policy, Section I.A.3.7: “Upon denying a transfer request for any of the following reasons, the Registrar of Record must provide the Registered Name Holder and the potential Gaining Registrar with the reason for denial. The Registrar of Record may deny a transfer request only in the following specific instances: Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact. The transfer was requested within 60 days of the creation date as shown in the registry WHOIS record for the domain name.”

 

2

IB

k

[DA-D19-R01]

based on the ICANN Governmental Advisory Committee (GAC) proposed principles, gTLD [registration directory] services "should provide sufficient and accurate data about domain name registrations and registrants (…)" (para 3.3)

Same as [DE-D19-R01]

1

DB

n

[DA-D21-R01]

In sum, from the Article 29 WP’s comments on ICANN’s procedures for handling WHOIS conflicts with privacy law (and related correspondence), we could draw out the following possible requirement: Data should be accurate. Specifically, Article 29 expresses “support for earlier proposals concerning accuracy of the data (which is also one of the principles of the Data Protection Directive) published in WHOIS directories ...”

 

1

DB

n

[DA-D22-R01]

In sum, from the Article 29 WP’s Opinion 2/2003, we could draw out the following possible requirement: Data should be accurate. Specifically, the WP states “its support for the proposals concerning accuracy of the data (which is also one of the principles of the European Data Protection Directive) ...”

 

1

DB

n

[DA-D25-R01]

Council of Europe's Treaty 108 on Data Protections enshrines the individual's right to know that information is stored on him or her and, if necessary, to have it corrected.

 

1

IA

at

[DA-D26-R01]

According to the Directive (38 ), whereas, if the processing of data is to be fair, the data subject must be in a position to learn of the existence of a processing operation and, where data are collected from him, must be given accurate and full information, bearing in mind the circumstances of the collection;

 

1

IA

at

[DA-D26-R02]

According to the Directive (41 ), whereas any person must be able to exercise the right of access to data relating to him which are being processed, in order to verify in particular the accuracy of the data and the lawfulness of the processing; whereas, for the same reasons, every data subject must also have the right to know the logic involved in the automatic processing of data concerning him, at least in the case of the automated decisions referred to in Article 15 (1); whereas this right must not adversely affect trade secrets or intellectual property and in particular the copyright protecting the software; whereas these considerations must not, however, result in the data subject being refused all information;

Same as [UP-D26-R10] [GA-D26-R03]

1

EA

e

[DA-D30-R01]

The Data Integrity and Purpose Limitation principle (Annex II, II.5) also states: “To the extent necessary for those purposes, an organisation must take reasonable steps to ensure that personal data is reliable for its intended use, accurate, complete and current”. The WP29 notes that this is exactly the same wording as used in the Safe Harbour arrangement. The WP29 doubts that the wording “to the extent necessary to these purposes” should be included, since the accuracy of the data in its view should not depend on the purpose of the processing. The WP29 would prefer if this connection is not made in the final adequacy decision.pg24

Depends on Definition of personal data such as [DE-D26-R09]

1

DB

n

[DA-D32-R06]

Updated Ownership, Contact and Use Information. At any time there is a change in ownership, the domain name owner must submit the following information:

  • Up-to-date contact and ownership information; and
  • A description of how the owner is using the domain name, or, if the domain name is not in use, a statement to that effect. (may also apply to Data Elements charter question)

Should this be duplicated as [DE-D32-R05]?

1

DB

f, n

[DA-D41-R01]

RFC 7481, Section 3.6, Data Integrity, specifies that "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." This provides a possible requirement: A registration directory service must be able to provide message integrity for client-server data exchanges using HTTP over TLS. (May also be related to Privacy)

Should this be duplicated as [PR-D41-R02]

3

G

x

[DA-D45-R01]

Incentives for registrants to input accurate gTLD registration data must be provided. These may include: [as detailed by [DA-D45-R02 to R06]

Precedes [DA-D45-R02 to R06]

1

DB

n, s

[DA-D45-R02]

* [Accuracy incentives may include] building a 'gate' between private data and the public. "Make it harder for criminals to access sensitive data by putting all sensitive data behind a series of ‘gates’ which are only accessible to authenticated users with permissible purposes. Registrants [should be] able to control their own personal data [and] determine which data they want behind each gate and which data can be publicly displayed to anonymous requestors."

Supports [DA-D45-R01], Depends on Definition of personal data such as [DE-D26-R09]

1

DA, AB

f, s

[DA-D45-R03]

* [Accuracy incentives may include] Making contact data updates easier and more automatic. "Updating contacts [should be] greatly simplified [by] allowing contact holders to easily update their data and such updates to be automatically applied to every affected domain own by the registrant."

Supports [DA-D45-R01]

1

DA, DB

f, n

[DA-D45-R04]

* [Accuracy incentives may include] Mechanisms to detect invalid gTLD registration data must be provided. These may include:

Supports [DA-D45-R01]

1

DB

n

[DA-D45-R05]

* [Accuracy incentives may include] Validators [to] validate the contact data and give an unique contact ID to contact data which registries or registrars can use obtain [validated] data. "Validators would specialize in collecting, validating, and storing contact data (postal address, email address, phone, fax, SMS numbers, etc.) which shall be made available by the [gTLD registration directory service] only to authorized requestors."

Supports [DA-D45-R01]

1

DB

n

[DA-D45-R06]

* [Accuracy incentives may include] Official proof validation [should be] optional to registrants. "The EWG did not propose that identity validation be required, or that contacts be forced to show government IDs or any other proof of identity when creating a contact. In fact, [the EWG’s] final report supports use of contacts created by accredited privacy and proxy services, so that registrants would still have the option of not entering their own contact data, instead designating a third party willing to serve as a contact for that domain name."

Supports [DA-D45-R01]

2

DB

n

[DA-D49-R01]

According to the Los Angeles GAC Communiqué of October 16, 2014, the ICANN board should provide the GAC with a comprehensive scorecard indicating steps and timelines regarding all streams of work related to the WHOIS accuracy safeguard. (Page 4)

 

2, 3

BB

ac

[DA-D49-R02]

The ICANN board should complete the Pilot study on WHOIS accuracy, including assessment of identity validation, and share the findings in a timely manner for review. (Page 4)

 

2, 3

BB

ac

[DA-D49-R03]

The ICANN board should initiate steps toward Phase 3 (identity verification) of WHOIS, including undertaking a cost-benefit analysis of implementation options. (Page 4)

 

3

BB, KA

ac, ag

[DA-D49-R04]

The ICANN board should commit to defining the process to address and resolve inaccurate WHOIS records and respond to non-compliance reports. (Page 4)

 

3

DB

n

[DA-D50-R01]

According to the Singapore GAC Communiqué of February 11, 2015, requiring Registries to verify and validate the credentials of registrants for domain names in regulated and highly regulated industries should not pose cross-jurisdictional challenges for Registries and Registrars. (Page 4)

 

1

DB, J

n, o

[DA-D50-R02]

The affirmative requirement for verification of credentials at the time of registration goes much further to meeting the goal of mitigating consumer harm and fraud than an after-the-fact complaint system. (Page 4)

 

1

DB

aa

[DA-D51-R01]

According to the Marrakech GAC Communiqué of March 9, 2016, customer data should be validated in compliance with the RAA Cross-Validation requirement, pursuant to RAA WHOIS ACCURACY PROGRAM SPECIFICATION, paragraph 1 "...Registrar will, with respect to both WHOIS information and the corresponding customer account holder contact information related to such Registered Name..." validate the information provided. (Page 10)

 

1

DB

aa

[DA-D52-R01]

In the London GAC Communiqué of June 25, 2014, GAC advises the ICANN board to address 1) the process for verification of WHOIS information; 2) the proactive verification of credentials for registrants of domain names in regulated and highly regulated industries (the relevant Category 1 strings, where Category 1 refers to consumer protection, sensitive strings and regulated markets.); 3) the proactive security checks by registries; 4) the Public Interest Commitments Dispute Resolution Process (PICDRP), which is not defined as to length of procedure or outcome; and 5) discrimination in restricted TLDs.

 

1

DB, DA

n, af

[DA-D53-R01]

In the Singapore GAC Communiqué of March 27, 2014, GAC requests clarification from the New gTLD Program Committee (NGPC) on a number of implementation issues. These relate to the implications of changes in WHOIS verification and checks for the accuracy of WHOIS generally and for law enforcement and end users; security checks to detect risks of harm (eg phishing, malware, botnets etc); compliant mechanisms; verification and validation of Category 1 (consumer protection, sensitive strings and regulated markets) registrants' credentials and the lack of binding nature of the public interest commitments; operation of the Public Interest Commitment Dispute Resolution Procedure; and Category 2 restricted registration policies. (Page 3-4)

 

1

DB, DA

af, n, q, aa

[DA-D53-R02]

Safeguard 1: Should ICANN perform "periodic sampling" of WHOIS data across registries in an effort to identify potentially inaccurate records? (Page 9)

 

1

DB

n, ad

[DA-D53-R03]

Safeguard 3: Should Registry Operators undertake periodic security checks to analyze whether domains in its gTLD are being used for threats to security, such as pharming, phishing, malware and botnets? (Page 10)

Relevance to RDS?

?

?

?

[DA-D53-R04]

Safeguard 5: What Compliant Mechanisms should be developed to ensure that Registry Operators provide a means by which complaints can be submitted related to: WHOIS data inaccuracy, trademark or copyright infringement, counterfeiting, fraudulent or deceptive practices, the use of malware, botnets, phishing, piracy, or other unlawful activities. (Page 10)

 

2

L

z

[DA-D54-R01]

According to SAC051, the ICANN community should develop a uniform and standard framework for accessing registration data that would provide mechanisms to define and implement a range of verification methods.

 

1

AB, DB

s, t, u, n

[DA-D57-R01]

According to GAC Comments on “New gTLD Program Safeguards Against DNS Abuse,” [there should be] data accuracy specifications, including cross field address validation.

 

1

DB

n

[DA-D57-R02]

There should be Requirements to measure the effectiveness of data accuracy specifications.

 

1

DB

n

[DA-D58-R01]

According to the GAC Public Safety Working Group (PSWG) Public Comments to “2013 RAA WHOIS Accuracy Specification Review,” the current 2013 RAA WHOIS Specification is serving its intended purpose and its requirements should be maintained.

 

1

DB

n

[DA-D58-R02]

If there are greater efficiencies or other methods that can be used to reach the goal of accurate WHOIS, the GAC PSWG supports those efforts.

 

2

DB

n

[DA-D58-R03]

Need verification and validation of relevant registrant / [RDS] data before registration.

 

1

DB, DA

aa, af

[DA-D61-R01]

According to Carlton Samuels’ blog on building a better WHOIS for individual registrants, Registrants [should be] responsible for relevant personal/organisation data only and not the contact information of associated organisations such as ISPs, web hosting firms, or registrars. “Registrants and their designated contacts can enter and update their data more easily.”

 

1

DA

f

[DA-D61-R02]

[There should be] increased data accuracy by validating contact upon registration and offering additional identity validation to deter identity fraud by “…performing basic validation of contact data…[and] optional identity validation.”

 

1

DA

af

[DA-D61-R03]

[There should be] Data minimization in collection and accessibility. “Make public the bare minimum dataset: domain name details, contact IDs for the registrant and designated contacts, and registrant’s own e-mail address. by default, all other contact data would be gated...Registrants and contacts can choose to make more data public but would not be required to do so.”

 

1

AB

t

[DA-D62-R01]

The WG should consider whether a domain registration must require verification that there is a real person behind the domain name registration

 

1

DA

af

[DA-D62-R02]

For any registered domain, there should be a valid admin and technical contact and this information should be public, with "as of" date (as minimum)

 

2

DA

af


See Additional Key Inputs for this charter question ( hyperlinked on this Wiki page ) which may be consulted as a potential source of possible requirements. The PDP WG may also identify additional sources by themselves or through community outreach.

Data Elements (DE)

The following possible requirements address the charter question on Data Elements (DE):
What data should be collected, stored, and disclosed?

The process framework for this question (below) can be applied to categorize possible requirements into three phases:

 

In the grid below, we identify the possible requirement for WG deliberation, any prerequisites or dependencies contained in that possible requirement , and whether the possible requirement therefore falls into Phase 1, 2, or 3. Policies designed to meet Phase 1 policy requirements should be considered in Phase 2 , while implementation or coexistence guidance for Phase 2 policies should be considered in Phase 3 . In addition, an initial attempt has been made to group similar requirements by code (C) and keyword (K) , allowing the table to be easily re-sorted or filtered – see Annex B for definitions.

QQ-D#-R#

Possible Requirement

Prerequisites/Dependencies

Ph

C

K

[DE-D01-R01]

The [gTLD registration directory service] must accommodate purpose-driven disclosure of data elements.

Related to [UP-D01-R02]

1

A, AB

a, s

[DE-D01-R02]

Not all [gTLD registration] data collected is to be public; disclosure must depend upon Requestor and Purpose.

Depends on Permissible Users, Permissible Purposes

1

A, AB

a, s

[DE-D01-R03]

Public access to an identified minimum data set must be made available [by the gTLD registration directory service], including contact data published expressly to facilitate communication for this purpose.

Depends on Minimum Data Set such as [DE-D01-R26], Access PR(s) for Public Access

1

AB, DA

t, b

[DE-D01-R04]

Data Elements determined to be more sensitive (after conducting the risk & impact assessment) must be protected by gated access, based upon:

  • Identification of a permissible purpose,
  • Disclosure of requestor/purpose, and
  • Auditing/Compliance to ensure that gated access is not abused.

Depends on Data Set for each Permissible Purpose [DE-D01-R07], Access PR(s) for Gated Access

1

A, AB

a, s

[DE-D01-R05]

Only the data elements permissible for the declared purpose must be disclosed (i.e., returned in responses or searched by Reverse and WhoWas queries).

Related to [DE-D01-R04], Depends on Data Set for each Permissible Purpose [DE-D01-R07], Access PR(s) for Gated Access

1

A

a

[DE-D01-R06]

The only [gTLD registration] data elements that must be collected are those with at least one permissible purpose.

Related to [UP-D23-R14], Depends on Data Set for each Permissible Purpose [DE-D01-R07]

1

A

a

[DE-D01-R07]

Each [gTLD registration] data element must be associated with a set of permissible purposes.

Precedes [DE-D01-R08 to R11], Related to [DE-D01-R04 to R06], Similar to [DE-D01-R09], Depends on Permissible Purposes

1

A

a

[DE-D01-R08]

* An initial set of acceptable uses, permissible purposes, and data element needs are identified [by possible requirements for Users/Purposes.]

Supports [DE-D01-R07], Depends on Permissible Purposes, Permissible Users, Privacy PR(s) for Processing/Use

1

A

a

[DE-D01-R09]

* Each permissible purpose must be associated with clearly-defined data element access and use policies.

Supports [DE-D01-R07], Similar to [DE-D01-R07], Depends on

Privacy PR(s) for Processing/Use

1

A

a

[DE-D01-R10]

* An on-going review process must be defined to consider proposed new purposes and periodically update permissible purposes to reflect approved additions, mapping them to existing data elements.

Supports [DE-D01-R07], Depends on existing Data Elements,

Privacy PR(s) for Processing/Use

2

A, F

a, h

[DE-D01-R11]

* A Policy Definition process must be defined to consider proposed new data elements and, when necessary, update defined data elements, mapping them to existing permissible purposes.

Supports [DE-D01-R07], Related to [DE-D01-R10]

2

F

h

[DE-D01-R12]

The list of minimum data elements to be collected, stored and disclosed must be based on known [permissible purpose] use cases and a risk assessment.

Related to [DE-D01-R26], Depends on Permissible Purposes, Privacy PR(s) for Collection and Processing/Use, Risk PR(s)

1

A

a

[DE-D01-R13]

In support of the overarching legal principles (see Privacy Question), Registrars and Validators should afford domain name Registrants and purpose-based contacts the opportunity, at the time of data collection, to consent to the use of their data for pre-disclosed permissible purposes, in accordance with the data protection laws of their jurisdiction. In formulating the policy, this principle must be addressed in the broader context of these overarching legal principles.

Depends on Data Set for each Permissible Purpose [DE-D01-R07], Privacy PR(s) on Choice and Limitation of Purpose

1

A, EA

a, l

[DE-D01-R14]

To meet basic domain control needs, it must be mandatory for Registries and Registrars to collect and Registrants to provide the following data elements when a domain name is registered:

a. Domain Name

b. DNS Servers

c. Registrant Name

d. Registrant Type

Indicates the kind of entity identified by Registrant Name, for use in applying registration data requirements (e.g., undeclared, privacy/proxy provider, legal person, natural person – further described on pp 42-43)

e. Registrant Contact ID

A unique ID assigned to each Registrant Contact [Name+Address] during validation

f. Registrant Postal Address

Includes Street, City, State/Province, Postal Code, Country (as applicable)

g. Registrant Email Address

h. Registrant Phone

Includes the following data elements: Number, Extension (when applicable)

Similar to [DE-D06-R01] [DE-D07-R02], PR to be defined in P1, each referenced Data Element to be fully defined in P2, Depends on Permissible Purposes involving this data, Privacy PR(s)

1, 2

DA

f

[DE-D01-R15]

To improve both Registrant privacy and contactability, Registrars must collect and Registrants must provide purpose-based contacts for every registered domain name.

Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35], Privacy PR(s) for Collection

1

DA

f

[DE-D01-R16]

Registrants may optionally designate Privacy/Proxy-supplied contacts or authorized third party contacts for specified permissible purposes.

Depends on Privacy PR(s) for P/P Providers

1

ID

g

[DE-D01-R17]

To meet the communication needs associated with each permissible purpose, contacts created through a Validator and subsequently associated with a domain name must satisfy minimum mandatory data element requirements.

Depends on Data Accuracy PR(s) for Validation, Minimum Data Set such as [DE-D01-R26]

1

DA, A, EA

f, a, e

[DE-D01-R18]

If a Registrant does not designate a contact for each mandatory permissible purpose, the Registrant’s own contact data must be used by default. (Note that the Registrant can avoid this by using an accredited Privacy/Proxy service, or by designating other contacts.

Related to [DE-D01-R17], Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35], Privacy PR(s) for Collection

1

DA

f

[DE-D01-R19]

To avoid collecting more data than necessary, all other Registrant-supplied data not enumerated above and used for at least one permissible purpose must be optionally collected at the Registrant’s discretion. Validators, Registries and Registrars must allow for this data to be collected and stored if the Registrant so chooses.

Related to [DE-D01-R14 to R18] [PR-D01-R06], Depends on Privacy PR(s) for Collection and Storage

1

DA

f

[DE-D01-R20]

To maximize Internet stability, the following mandatory data elements must be provided by Registries and Registrars:

a. Registration Status

b. Client Status (Set by Registrar)

c. Server Status (Set by Registry)

d. Registrar

e. Registrar Jurisdiction

f. Registry Jurisdiction

g. Registration Agreement Language

h. Creation Date

i. Registrar Expiration Date

j. Updated Date

k. Registrar URL

l. Registrar IANA Number

m. Registrar Abuse Contact Phone Number

n. Registrar Abuse Contact Email Address

o. URL of Internic Complaint Site

Similar to [DE-D06-R01] [DE-D07-R02], PR to be defined in P1, each referenced Data Element to be fully defined in P2, Depends on Permissible Purposes involving this data, Privacy PR(s)

1, 2

J

an

[DE-D01-R21]

For TLD-specific data elements, the TLD Registry must establish and publish a data collection policy (consistent with these over-arching principles) and be responsible for any validation of those TLD-specific data elements.

Related to [DE-D07-R01], Depends on Privacy PR(s) for Collection, Accuracy PR(s) for Validation

1

IA

d

[DE-D01-R22]

Validators, Registries and Registrars may collect, store, or disclose additional data elements for internal use that is never shared with the [gTLD registration directory service].

None

1

DB

ae

[DE-D01-R23]

To maximize Registrant privacy, Registrant-supplied data must be gated by default, except where there is a compelling need for public access that exceeds resulting risk. Registrants can opt into making any gated Registrant-supplied data public with informed consent.

Depends on Access PR(s), Definition of Registrant-Supplied Data such as [DE-D01-R26],

Privacy PR(s) for Consent

1

AB

s

[DE-D01-R24]

To maximize Internet stability, all Registry or Registrar-supplied registration data must be always public, except where doing so results in unacceptable risk. Registrants can opt into making any public Registry/Registrar-supplied data gated, except as noted below to enable basic domain control.

Depends on Access PR(s) for Public Access, Definition of Registry/Registrar-Supplied Data such as [DE-D01-R20], Risk PR(s)

1

AB

t

[DE-D01-R25]

To maximize reachability, all purpose-based contacts must be public by default. Contact Holders can opt into making any contact data element gated, except [for data elements] required to satisfy the designated purpose.

Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35], Privacy PR(s)

1

DA

b

[DE-D01-R26]

To meet basic domain control needs, the following Registrant-supplied data, which is mandatory to collect and low-risk to disclose, must be included in the minimum public data set:

a. Domain Name

b. DNS Servers

c. Registrant Type

d. Registrant Contact ID

e. Registrant Email Address

f. Tech Contact ID

g. Admin Contact ID

h. Legal Contact ID

i. Abuse Contact ID

j. Privacy/Proxy Provider Contact ID

(mandatory only if Registrant Type = Privacy/Proxy Provider)

k. business Contact ID (mandatory only if Registrant Type = Legal Person)

Similar to [DE-D06-R01] [DE-D07-R02], PR to be defined in P1, each referenced Data Element to be fully defined in P2, Depends on Permissible Purposes involving this data, Privacy PR(s), Risk PR(s)

1, 2

DA

b

[DE-D01-R27]

To balance simplicity and reachability, if a Registrant does not supply a mandatory purpose-based contact, the Registrant must be informed that [Registrant data elements] will be used [for that purpose]. The Registrant can avoid this disclosure by specifying one or more third party contacts or by using an accredited Privacy/Proxy service.

Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35], Privacy PR(s) for P/P Providers

1

DA, ID

b, f, g

[DE-D01-R28]

For TLD-specific data elements, the TLD Registry must establish and publish a data disclosure policy (consistent with these over-arching principles) and be responsible for identifying permissible purposes for any gated TLD-specific data elements.

Related to [DE-D07-R01], Depends on Permissible Purposes

1

IA

d

[DE-D01-R29]

[gTLD registration directory services] must be expandable in the future to support “multiple contacts specified for each type of purpose-based contact, allowing direct contact with specific individuals with critical responsibilities.”

Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35]

1

DA

f

[DE-D01-R30]

All purpose-based contacts “must be aware of and agree to fulfill the designated role(s) for each registered domain name.” (p.39) [as further described below:]

Precedes [DE-D01-R31 to R34], Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35]

1

DA

f, af

[DE-D01-R31]

* Each contact’s approval must be obtainable in a scalable, real-time or near real-time manner to avoid delaying domain name registrations or domain name updates.

Supports [DE-D01-R30]

1

DA

af

[DE-D01-R32]

* Policies and processes must prevent unauthorized use of [a purpose-based contact’s] contact data.

Supports [DE-D01-R30]

1

DA

af

[DE-D01-R33]

* Either the designated contact or the Registrant must be able to rescind approval [to fulfill designated role(s) for each domain name] at a later time.

Supports [DE-D01-R30]

1

DA

af

[DE-D01-R34]

* Registrants must be able to easily designate themselves as contacts for their domain names without external/third party approval.

Supports [DE-D01-R30]

1

DA

af

[DE-D01-R35]

Contact management must be feasible separately from domain management, allowing contact portability and accountability separate from domain names and controlled by the actual individuals or entities listed under such contacts.

Related to Data Accuracy PR(s) for reusable Contact Directory such as [DA-D01-R02], Depends on Privacy PR(s)

1

DA

af

[DE-D01-R36]

Contacts must be managed using Validators who manage contact databases, implement validation regimes, and maintain information on the level of validity for the contact and its data elements (accessible through the [gTLD registration directory service]).

Related to Data Accuracy PR(s) for pre-validated Contact Directory such as [DA-D01-R02]

1

DA, EA

af, e

[DE-D01-R37]

Domain registrations may be associated with Contact IDs designated by their Registrants and approved by such designated contacts for various purposes associated with a domain name.

Related to Data Accuracy PR(s) for Contact IDs such as [DA-D01-R06]

1

DA

af

[DE-D01-R38]

Such contacts must contain valid mandatory data elements. Policies and oversight will be needed to manage these processes to ensure that Contact IDs are not used without contact’s authorization and meet minimum standards.

Related to [DE-D01-R39], Depends on Contact’s Authorization [DE-D01-R30], Data Accuracy PR(s) for Validation

1

IA

d

[DE-D01-R39]

Change management and authorization of use of contact information is controlled by the Contact Holder and affects all domains associated to a contact. Processes and policies to ensure accurate, authentic, and timely implementation of desired changes without burdening contacts or Registrants must be developed to support this new paradigm.

Related to [DE-D01-R38] with similar dependencies

1

IA

d

[DE-D01-R40]

Each individual block of contact data must have a Contact ID which uniquely identifies both the Validator and the Contact Holder to enable retrieval and update of associated contact data. This Contact ID must be published in any public display of [registration] data.

Related to Data Accuracy PR(s) for Contact IDs such as [DA-D01-R06]

1

DA

ah

[DE-D02-R01]

"Internationalization MUST be supported by default, not called out separately. The focus should be on Recommendation 2 from the IRD-WG final report."

Related to [GA-D01-R31 to R33] [GA-D42-R03] [DE-D09-R01] [DE-D09-R01] [DE-D02-R01], Depends on IRD-WG Final Report [insert document # here]

1

F

y

[DE-D06-R01]

From 3.2.1: As part of its registration of Registered Names in a gTLD, Registrar shall submit to, or shall place in the Registry Database operated by, the Registry Operator for the gTLD the following data elements:

  • The name of the Registered Name being registered;
  • The IP addresses of the primary name server and secondary name server(s) for the Registered Name;
  • The corresponding names of those name servers;
  • Unless automatically generated by the registry system, the identity of the Registrar;
  • Unless automatically generated by the registry system, the expiration date of the registration; and
  • Any other data the Registry Operator requires be submitted to it.

Similar to [DE-D01-R14], PR to be defined in P1, each referenced Data Element to be fully defined in P2

1, 2

DA

ah

[DE-D06-R02]

The agreement between the Registry Operator of a gTLD and Registrar may, if approved by ICANN in writing, state alternative required data elements applicable to that gTLD, in which event, the alternative required data elements shall replace and supersede RAA Subsections 3.2.1.1 through 3.2.1.6 stated above for all purposes under this Agreement but only with respect to that particular gTLD.

Related to TLD-specific data elements [DE-D07-R01] , Same as [DE-D06-R04]

1

IA, F

d, h

[DE-D06-R03]

From 3.3.1: At its expense, Registrar shall provide an interactive web page and, with respect to any gTLD operating a "thin" registry, a port 43 Whois [or gTLD registration directory] service (each accessible via both IPv4 and IPv6) providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by Registrar in any gTLD. Until otherwise specified by a Consensus Policy, such data shall consist of the following elements as contained in Registrar's database:

  • The name of the Registered Name;
  • The names of the primary name server and secondary name server(s) for the Registered Name;
  • The identity of Registrar (which may be provided through Registrar's website);
  • The original creation date of the registration;
  • The expiration date of the registration;
  • The name and postal address of the Registered Name Holder;
  • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and
  • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name.

Similar to [DE-D01-R14] [DE-D01-R20] [DE-D01-R26], PR to be defined in P1, each referenced Data Element to be fully defined in P2

1, 2

F

ak, al

[DE-D06-R04]

The agreement between the Registry Operator of a gTLD and Registrar may, if approved by ICANN in writing, state alternative required data elements applicable to that gTLD, in which event, the alternative required data elements shall replace and supersede RAA Subsections 3.3.1.1 through 3.3.1.8 stated above for all purposes under this Agreement but only with respect to that particular gTLD.

Same as [DE-D06-R02], identical from same source with exception of referenced RAA subsections

1

F

h

[DE-D06-R05]

From 3.4.1: For each Registered Name sponsored by Registrar within a gTLD, Registrar shall collect and securely maintain, in its own electronic database, as updated from time to time:

The data specified in the Data Retention Specification attached hereto for the period specified therein;

  • The data elements listed in RAA Subsections 3.3.1.1 through 3.3.1.8;
  • The name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact;
  • Any other Registry Data that Registrar has submitted to the Registry Operator or placed in the Registry Database under Subsection RAA 3.2; and
  • The name, postal address, e-mail address, and voice telephone number provided by the customer of any privacy service or licensee of any proxy registration service, in each case, offered or made available by Registrar or its Affiliates in connection with each registration. Effective on the date that ICANN fully implements a Proxy Accreditation Program established in accordance with RAA Section 3.14, the obligations under this Section 3.4.1.5 will cease to apply as to any specific category of data (such as postal address) that is expressly required to be retained by another party in accordance with such Proxy Accreditation Program.

Similar to [DE-D01-R14] [DE-D01-R20] [DE-D01-R26], PR to be defined in P1, each referenced Data Element to be fully defined in P2, Depends on Privacy PR(s) for Collection

1, 2

J

o

[DE-D06-R06]

From 3.4.2: During the Term of this [Registrar Accreditation] Agreement and for two (2) years thereafter, Registrar (itself or by its agent(s)) shall maintain the following records relating to its dealings with the Registry Operator(s) and Registered Name Holders:

  • In electronic form, the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry Operator(s);
  • In electronic, paper, or microfilm form, all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with Registered Name Holders, including registration contracts; and
  • In electronic form, records of the accounts of all Registered Name Holders with Registrar.

Depends on Privacy PR(s) for Retention

1

J

o

[DE-D06-R07]

From 3.4.3: During the Term of this [Registrar Accreditation] Agreement and for two (2) years thereafter, Registrar shall make the data, information and records specified in this Section 3.4 available for inspection and copying by ICANN upon reasonable notice. In addition, upon reasonable notice and request from ICANN, Registrar shall deliver copies of such data, information and records to ICANN in respect to limited transactions or circumstances that may be the subject of a compliance-related inquiry; provided, however, that such obligation shall not apply to requests for copies of the Registrar's entire database or transaction history. Such copies are to be provided at Registrar's expense. In responding to ICANN's request for delivery of electronic data, information and records, Registrar may submit such information in a format reasonably convenient to Registrar and acceptable to ICANN so as to minimize disruption to the Registrar's business. In the event Registrar believes that the provision of any such data, information or records to ICANN would violate applicable law or any legal proceedings, ICANN and Registrar agree to discuss in good faith whether appropriate limitations, protections, or alternative solutions can be identified to allow the production of such data, information or records in complete or redacted form, as appropriate. ICANN shall not disclose the content of such data, information or records except as expressly required by applicable law, any legal proceeding or Specification or Policy.

Depends on Privacy PR(s) for Retention

2

 

o

[DE-D06-R08]

From RAA WHOIS Spec 1.4: For a Domain Name Data Query “whois – h whois.example-registrar.tld EXAMPLE.TLD” the format of responses shall contain all the elements and follow a semi-free text format outline below. Additional data elements can be added at the end of the text format outlined below. The data element may, at the option of Registrar, be followed by a blank line and a legal disclaimer specifying the rights of Registrar, and of the user querying the database (provided that any such legal disclaimer must be preceded by such blank line).

Domain Name: EXAMPLE.TLD

Registry Domain ID: D1234567-TLD

Registrar WHOIS Server: whois.example-registrar.tld

Registrar URL: http://www.example-registrar.tld

Updated Date: 2009-05-29T20:13:00Z

Creation Date: 2000-10-08T00:45:00Z

Registrar Registration Expiration Date: 2010-10-08T00:44:59Z

Registrar: EXAMPLE REGISTRAR LLC

Registrar IANA ID: 5555555

Registrar Abuse Contact Email: email at registrar.tld

Registrar Abuse Contact Phone: +1.1235551234

Reseller: EXAMPLE RESELLER1

Domain Status: clientDeleteProhibited2

Domain Status: clientRenewProhibited

Domain Status: clientTransferProhibited

Registry Registrant ID: 5372808-ERL3

Registrant Name: EXAMPLE REGISTRANT4

Registrant Organization: EXAMPLE ORGANIZATION

Registrant Street: 123 EXAMPLE STREET

Registrant City: ANYTOWN

Registrant State/Province: AP5

Registrant Postal Code: AA1A16

Registrant Country: AA

Registrant Phone: +1.5555551212

Registrant Phone Ext: 12347

Registrant Fax: +1.5555551213

Registrant Fax Ext: 4321

Registrant Email: EMAIL at EXAMPLE.TLD

Registry Admin ID: 5372809-ERL8

Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE

Admin Organization: EXAMPLE REGISTRANT ORGANIZATION

Admin Street: 123 EXAMPLE STREET

Admin City: ANYTOWN

Admin State/Province: AP

Admin Postal Code: A1A1A1

Admin Country: AA

Admin Phone: +1.5555551212

Admin Phone Ext: 1234

Admin Fax: +1.5555551213

Admin Fax Ext: 1234

Admin Email: EMAIL at EXAMPLE.TLD

Registry Tech ID: 5372811-ERL9

Tech Name: EXAMPLE REGISTRANT TECHNICAL

Tech Organization: EXAMPLE REGISTRANT LLC

Tech Street: 123 EXAMPLE STREET

Tech City: ANYTOWN

Tech State/Province: AP

Tech Postal Code: A1A1A1

Tech Country: AA

Tech Phone: +1.1235551234

Tech Phone Ext: 1234

Tech Fax: +1.5555551213

Tech Fax Ext: 93

Tech Email: EMAIL at EXAMPLE.TLD

Name Server: NS01.EXAMPLE-REGISTRAR.TLD10

Name Server: NS02.EXAMPLE-REGISTRAR.TLD

DNSSEC: signedDelegation

URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/

>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

Depends on Access PR(s) and referenced Data Elements being fully defined in P2 – for example, see [DE-D01-R14] [DE-D01-R20] [DE-D01-R26]

2

F, J

al, o

[DE-D06-R09]

From RAA WHOIS Spec 1.5: The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers, email addresses, date and times must conform to the mappings specified in EPP RFCs 5730-5734 (or its successors), and IPv6 addresses format should conform to RFC 5952 (or its successor), so that the display of this information (or values returned in… responses) can be uniformly processed and understood.

Depends on PR(s) involving use of and mapping to EPP such as [DE-D43-R02]

3

A, EA

a, m

[DE-D06-R10]

From RAA Data Retention Spec: Registrar shall collect the following information from registrants at the time of registration of a domain name (a "Registration") and shall maintain that information for the duration of Registrar's sponsorship of the Registration and for a period of two additional years thereafter:

  • First and last name or full legal name of registrant;
  • First and last name or, in the event registrant is a legal person, the title of the registrant's administrative contact, technical contact, and billing contact;
  • Postal address of registrant, administrative contact, technical contact, and billing contact;
  • Email address of registrant, administrative contact, technical contact, and billing contact;
  • Telephone contact for registrant, administrative contact, technical contact, and billing contact;
  • WHOIS [or gTLD registration directory service] information, as set forth in the [above] Specification;
  • Types of domain name services purchased for use in connection with the Registration; and
  • To the extent collected by Registrar, "card on file," current period third party transaction number, or other recurring payment data.

Depends on RAA WHOIS Spec such as [DE-D06-R08], Privacy PR(s) for Collection and Retention

2

DA, J

f, o

[DE-D06-R11]

Registrar shall collect the following information and maintain that information for no less than one hundred and eighty (180) days following the relevant interaction:

  • Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor;
  • Log files, billing records and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other records containing communications source and destination information, including, depending on the method of transmission and without limitation: (1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle, or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration; and
  • Log files and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other records associated with the Registration containing dates, times, and time zones of communications and sessions, including initial registration.

Depends on Privacy PR(s) for Collection and Retention

2

J

o, an

[DE-D07-R01]

From Spec 4, Section 1.4: Requires that registries provide registrar information and contact details as part of a registrar query on the [gTLD registration directory service], as well as registrar information as part of the name server [gTLD registration directory service] query. “The fields specified below set forth the minimum output requirements. Registry Operators may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.”

Depends on Registrar Data such as [DE-D07-R02], Related to [DE-D01-R21] for additional data

1

F

al

[DE-D07-R02]

From Spec 4, Section 1.6: “Registrar Data [must include]

  • Registrar Name
  • Registrar Postal Address
  • Registrar Phone Number
  • Registrar Email Address
  • WHOIS Server
  • Referral URL
  • Admin Contact Information (phone number and email)
  • Technical Contact Information (phone number, email)”

Similar to [DE-D01-R14], PR to be defined in P1, each referenced Data Element to be fully defined in P2

1, 2

D

ao

[DE-D07-R03]

From Spec 4, Section 1.7: "Name Server Data [must include]

  • Server Name
  • IP Address (1 or more, IPv4 and/or IPv6)
  • Registrar Name
  • Registrar WHOIS Server
  • Referral URL"

Similar to [DE-D01-R14], PR to be defined in P1, each referenced Data Element to be fully defined in P2

1, 2

D

ap

[DE-D07-R04]

From Specification 4, Section 1.8: "The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers (the extension will be provided as a separate field as shown above), email addresses, date and times should conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.”

Depends on PR(s) involving use of and mapping to EPP such as [DE-D43-R02]

3

F

am

[DE-D07-R05]

From Specification 4, Section 1.9: “In order to be compatible with ICANN’s common interface for WHOIS (interNIC), [gTLD registration directory service] output shall be in the format outlined above”

Depends on common interface format such as [DE-D07-R04]

3

F

am

[DE-D08-R01]

The “designated role” for each purpose-based contact must be clearly defined and communicated to registrants and to persons/entities designated as contacts, as well as to requestors.

Variant of [DE-D01-R30], Depends on PR(s) for Purpose-based Contacts such as [UP-D01-R35]

1

IA

d

[DE-D09-R01]

In Recommendations 12-16, the WHOIS RT recommends that gTLD registration directory services support Internationalization of [registration] data, and the consistent handling of non-ASCII text in both the records and the display of the domain name itself.

Related to [GA-D01-R31 to R33] [GA-D42-R03] [DA-D02-R02] [DE-D02-R01]

1

F

y

[DE-D12-R01]

Registration information from all registries should follow consistent rules for labeling and display, as per the model outlined in specification 3 of the 2013 RAA. (Rec. #1)

Depends on Rules for Labeling and Display such as RAA Spec 3

1

F

al,   am

[DE-D12-R02]

The [gTLD registration directory service] should collect and display uniform sets of data regardless of the registry involved. (sec. 5.2)

Variant of [DE-D12-R01]

1

F

al, am

[DE-D13-R01]

based on the review of ICANN’s procedure for handling WHOIS conflicts with privacy law, the following Data Element-related requirements from past accreditation agreements are unchanged: Registrars must notify registrants of: 3) which data are obligatory, and that 5) Data collection may only be conducted with the consent of the registrant.

Depends on Data Element PR(s) on Collection such as [DE-D01-R14], Privacy PR(s) on Consent

1

IA, EA

d, l

[DE-D14-R01]

According to the 2013 RAA Data Retention Waiver and Discussion Document, registrars should have access to standard data elements, including first and last name of the registrant, Technical contact and billing contact, Postal address, Email address, Telephone number, Types of domain name services purchased, information on the means and source of payment, for billing and billing disputes.

Related to [UP-D14-R01] , Depends on standard data elements such as those defined by [DE-D06-R08]

1

AB

ar

[DE-D15-R01]

ICANN’s UDRP requires registrant information (Name and Company Name) taken from [gTLD registration directory services] for the disputed domain name. Specifically, “To demonstrate “legitimate interests in a Domain Name in Responding UDRP to a Complaint​... (ii) Respondent (as an individual, business, or other organization) have been [commonly known] by the domain name, even if acquired no trademark or service mark rights;” (UDRP policy, Paragraph 4(c)). For proving legitimate rights in a Domain Name, mostly under Ex ­ parte matters, the Complainant and Panelist in a UDRP matter analyze WHOIS information mainly to determine whether the Respondent (Owner of Disputed Domain) is commonly known by the disputed domain name. The Complainant will require access to WHOIS even before filing of the Complaint, to determine whether to go for UDRP/legal action or not.

Related to [UP-D01-R12], See also [DE-D16-R0x], Depends on standard data elements such as those defined by [DE-D06-R08]

1

CA, IC

j, aq

[DE-D15-R02]

According to ICANN’s UDRP, the UDRP Service provider, “when forwarding a complaint, including any annexes, electronically to the Respondent, it has to employ reasonably available means calculated to achieve actual notice to the Respondent. Achieving actual notice, or employing the following measures to do so, shall discharge this responsibility: (i) sending [Written Notice] of the complaint to all postal ­ mail and facsimile addresses shown in the domain name's registration data in [Registrar's Whois database] for the registered domain ­ name holder, the technical contact, and the administrative contact and supplied by Registrar to the Provider for the registration's billing contact; and (ii) sending the complaint, including any annexes, in electronic form by e ­ mail to the [e ­ mail addresses] for those technical, administrative, and billing contacts;” (Rules for Uniform Domain Name Dispute Resolution Policy, Paragraph 2) UDRP Service Providers therefore require these WHOIS details for service of notice.

Related to [UP-D01-R12], See also [DE-D16-R0x], Depends on standard data elements such as those defined by [DE-D06-R08]

2

CA, IC

j, aq

[DE-D15-R03]

According to ICANN’s UDRP, in a UDRP Complaint, “the Complainant [needs] to provide the name of the Respondent (domain ­ name holder) and all information (including any ​postal and e ­ mail addresses and telephone and telefax numbers​) known to Complainant regarding how to contact Respondent or any representative of Respondent and Identify the Registrar with whom the Domain is registered at the time of the Complaint.” (Rules for Uniform Domain Name Dispute Resolution Policy, Paragraph 3) The Complainant is required to provide contact information (i.e., Name, Address, Email, Telephone, Telefax and Domain Registrar) as a part of the UDRP Complaint and the most important source to know such information is WHOIS of a Domain Name, as the Respondent (i.e., owner of a disputed domain name) may be from any part of the world.

Related to [UP-D01-R12], See also [DE-D16-R0x], Depends on standard data elements such as those defined by [DE-D06-R08]

2

CA, IC

j, aq

[DE-D16-R01]

ICANN’s URS policy requires registrant information taken from [gTLD registration directory services] for the disputed domain name. Specifically, “the contents of Complaint under URS, [should] contain: (i) Name of Registrant (i.e. relevant information available from WHOIS) and WHOIS listed available contact information for the relevant domain name(s). (URS Procedure Para 1.2.3) and (ii) The specific domain name(s) that are the subject of the Complaint. For each domain name, the Complainant [shall include] a copy of the currently available WHOIS information​.” (URS Procedure Para 1.2.4)

Related to [UP-D01-R12], See also [DE-D15-R0x], Depends on standard data elements such as those defined by [DE-D06-R08]

2

CA, IC

j, aq

[DE-D16-R02]

ICANN’s URS policy paragraph 4 provides for service of Notice by the URS Provider to the Domain Registrant, through email, fax and postal mail obtained from WHOIS. Specifically, “after the Notice of Lock from the Registry Operator, within 24 hours, the URS Provider [shall] notify the Registrant of the Complaint, sending a hard copy of the Notice of Complaint to the addresses listed in the WHOIS contact information​.” (URS Policy Para 4.2) “The said Notice of Complaint to the Registrant [shall] be sent through email, fax (where available) and postal mail. The Complaint and accompanying exhibits, if any, shall be served electronically.” (URS Procedure Para 4.3)

Related to [UP-D01-R12], See also [DE-D15-R0x], Depends on standard data elements such as those defined by [DE-D06-R08]

2

IC

aq

[DE-D16-R03]

According to ICANN’s URS policy, when the Domain Registrant does not respond within 14 days period, it is considered as Default and the URS Provider will notify the Registry Operator accordingly. Specifically, “in case of Default, the URS Provider [shall] provide Notice of Default via email to the Complainant and Registrant, and via mail and fax to Registrant. During the Default period, the Registrant will be prohibited from changing content found on the site to argue that it is now a legitimate use and will also be prohibited from changing the WHOIS information.” ​(URS Procedure Para 6.2)

Related to [UP-D01-R12], See also [DE-D15-R0x], Depends on standard data elements such as those defined by [DE-D06-R08]

2

IC

aq

[DE-D16-R04]

According to ICANN’s URS policy, “after URS Determination, the Registry Operator shall suspend the domain name... The WHOIS for the domain name shall continue to display all of the information of the original Registrant except for the redirection of the name servers. In addition, the Registry Operator [shall cause] the WHOIS to reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.” (URS Procedure Para 10.2) This restricts Domain Status and [the display of data through gTLD registration directory services] to reflect the above data elements. Data for this purpose could be made available through a gated