During ICANN72, the System for Standardized Access/Disclosure Operational Design Phase (SSAD ODP) project team provided its third project update to the community. We thank everyone who was able to join the interactive session (recording, presentation). As the SSAD ODP project team continues its work, we will continue holding community webinars and publish a blog after each session to provide a brief recap and to restate any questions that are directed at the community.
The ICANN72 session gave an update on the project timeline, which was extended past its initial six-month timeframe. After making adjustments to allow for additional time to collect data and engage with the community, the project team is now expected to deliver the Operational Design Assessment (ODA) to the ICANN Board by the end of February 2022.
An overview of design proposals for two important aspects of the SSAD related to ICANN Contractual Compliance and identity verification methodology was also provided during the session. While the project team was building out these design elements, a number of questions arose that we have now directed to the community for feedback (outlined below).
Contractual Compliance
In the SSAD recommendations, there are two areas where ICANN Contractual Compliance would be involved:
- Procedural complaints: when requestors or data subjects believe a contracted party is violating the procedural requirements laid out in the policy for evaluating nonpublic data disclosure requests.
- Service Level Agreement (SLA) complaints: when contracted parties miss their SLA response requirement (e.g., taking too long to respond to an urgent request).
Contractual Compliance would approach these complaints using the same standard processes already in place. SSAD-related complaints would be received and processed through public complaint forms in the Naming Services portal (NSp) that result in individual cases. If needed, automated processes may be developed to handle SLA violations.
Question for the Community
- Do the areas identified in the recommendations capture all intended areas in which Contractual Compliance can enforce the policy?
Identity Verification Methodology
The SSAD recommendations state that any user of the SSAD system who requests nonpublic registration data must be accredited. The recommendations identified two separate accreditation categories:
- Non-governmental natural and legal persons (outlined in Recommendation 1).
- For these users, ICANN would serve as the Central Accreditation Authority (AA).
- Governmental entities and intergovernmental organizations (outlined in Recommendation 2).
- The accreditation of governmental users is out of scope for the Central AA.
To address the accreditation requirements for non-governmental natural and legal persons, the SSAD ODP project team researched a variety of identity verification methods available in the marketplace. Methods ranged from low cost and effort to potentially very high cost and effort. ICANN org is proposing a moderate level of assurance for the identity verification of natural persons (users), which provides a balance of cost and value and offers a degree of comfort that an individual can be identified per policy requirements.
The methods that ICANN proposes to identify natural persons include:
- Use of a qualifying electronic identification (eID) system, or
- Possession of a recognizable government ID with photo, or
- Possession of a recognizable government ID with electronic capabilities
The methods that ICANN proposes to verify affiliation (with a legal person) include:
- Verified natural person (outlined above) would provide information related to the legal person or affiliation including legal name, legal form of the organization, address, tax or other ID, that would then be verified by the Central AA or its designated identity provider.
The methods that ICANN proposes to verify user representation include:
- A verified natural person within the system may assert that they represent a legal entity for the purposes of requesting nonpublic data.
- The representative will provide various information regarding the legal person who is being represented, e.g., legal name, legal form, physical address, applicable ID/tax number of the representee.
- Confirmation of the relationship between the representative and the representee via Point of Contact (PoC). The PoC must be identified within the SSAD system and must be affiliated with the representee.
- The PoC provides a certificate of good standing (or equivalent) for the representee.
More detailed information on identity verification methods and processes is available in the webinar presentation here.
Questions for the Community
- Does the proposed approach provide an appropriate level of verification related to:
- The identity of natural persons who may become users of the SSAD?
- The identity of legal persons which will exist within the SSAD for purposes of documenting affiliation by users?
- The relationship between represented organizations and users?
- Does the proposed approach represent a reasonable level of effort for:
- Users who wish to become accredited?
- Those who are required to declare and maintain affiliation?
- Those who are required to declare and maintain representation?
It's important to remember that those requesting data via the SSAD must be accredited, but accreditation does not guarantee data disclosure. In most instances, contracted parties that receive the data disclosure request will evaluate the request and determine, based on their criteria, whether to disclose any of the requested data.
If you have questions or would like to provide input on the questions outlined above, please send an email to ODP-SSAD@icann.org. Note, all submissions will be publicly archived and available to view here.
The SSAD ODP project team will hold another webinar on 18 November to discuss additional design elements including the Business Process Design (register here). The community's input during this ODP is critical to its success, and we look forward to engaging with you all again soon.
