Operational Design Assessment
An Operational Design Assessment (ODA) is the final work product of an ICANN Organization Operational Design Phase (ODP). The ICANN Board uses an ODA to determine whether to adopt and how to implement consensus policy recommendations. The first-ever ODA was published on January 25, 2022, concerning the development of a System for Standardized Access/Disclosure (SSAD) of gTLD registration data based on the GNSO Council's Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data. ODAs serve as input to the Board's deliberations concerning recommendations, particularly over whether its adoption of a recommendation is in the best interest of the ICANN Community and ICANN Organization. ODAs are also an input to the design, building, and implementation of the recommendations if adopted in the final SSAD.
- The ICANN Board directs the ICANN President and CEO to conduct an ODP and produce an ODA to address a series of questions about a set of recommendations’ potential risks, anticipated costs, resource requirements, timelines, dependencies, and interaction with the Global Public Interest Framework.
- ICANN org undertakes the ODP over ten months with transparency and solicits feedback from the ICANN Community through webinars, blogs, announcements, data gathering, and regular communication with stakeholders.
- ICANN Organization sets out a series of assumptions to create a design framework for determining the roles and responsibilities of various actors, the scope of services and capabilities, involvement of vendors, and development of the cost mode.
- getting ready for operation: ICANN org outsources non-governmental identity, affiliation, and representation verification to a Central Accreditation Authority (Central AA), which uses government-issued identification to certify affiliation or representation. Governmental users are verified by their country or territory’s designated Accreditation Authority (AA).
- Timeline to develop and implement: 5 to 6 years.
- How the SSAD would operate: (Either ICANN-designated central or government-designated) AAs are the only point of contact with SSAD for gTLD registration data requestors. Next, the AAs relay the requests through the automated Central Gateway, which routes them to the appropriate Contracted Party for review and consideration. Then disclosure is approved or denied, and the requestor is permitted to query the data from the Contracted Parties’ Registration Data Access Protocol (RDAP) service.
- Systems and tools needed: Central AA and Central Gateway System to be outsourced. ICANN.org, ICANN’s RDAP client, and the Naming Services portal (NSp) need enhancements.
- Vendors and third parties needed: a Central Gateway Manager, a Central AA, an independent auditor, an SSAD Misuse Investigator, system development, customer service, and public relations firm for an awareness campaign.
- Resources and staffing: outsourced and ICANN personnel required.
- Costs: 20 to 27 million USD to develop and 14 to 106 million USD to run.
- Fee Structure: should allow for a five-year payback period.
- Risks include: maintaining compliance with evolving data protection laws, such as the GDPR, attractive target to online criminals, complexity, financial unsustainability due to uncertain demand, and reputational risks to ICANN.
- Global Public Interest: SSAD appears to be in the public's interest but more feedback is needed.
- Contractual Compliance: needs to develop processes and procedures to investigate complaints and make interventions.
- Audits: will be based on compliance with established accreditation policies and procedures posted via the Central Gateway.