SSAC Comments on Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A (R1)

Date IssuedDocumentReference IDCurrent Phase

  

SSAC Comments on Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A (R1)SAC118

Phase 3 | Evaluate & Consider



  1. Phase 1 Receive
  2. Phase 2 Understand
  3. Phase 3 Evaluate
  4. Phase 4 Implement
  5. Phase 5 Close
  6. Closed


DESCRIPTION

The SSAC recommends the Generic Name Supporting Organization (GNSO) and ICANN org focus their attention on building and operating an effective differentiated access system.

A differentiated access system with the following properties is needed:

Timely - It must come into operation soon.
Reliable - It must operate in a predictable and consistent fashion, both in the operation of the system and the decision-making by the participants of the system.
Useful - It must provide results that are of benefit to the requesters.
Efficient - It must provide responses to legitimate data requests quickly, and at a cost to all the parties that are acceptable for the purpose.
Easily Accessed - Gaining and maintaining credentials has to work well enough to facilitate—rather than impede—use.

This document uses the term “effective” to refer to a differentiated access system fulfilling all the above requirements, and, of course including the functionality required to manage distinct requests and responses to various combinations of requesters and purposes as noted in Section 2.2.


DEPENDENCIES

Pending external activity - the proof-of-concept service for a differentiated access system is developed and implemented and plans are then made for a full implementation.


STATUS UPDATES

DatePhaseTypeStatus Updates

 

Phase 3AP FeedbackThe SSAC does not agree the implementation of SAC118 Recommendation 1 has been overtaken by subsequent events and does not agree with the proposed plan to move SAC118 Recommendation 1 to Phase 5. The SSAC would prefer for SAC118 Recommendation 1 to remain in a deferred state while the proof-of-concept service is developed and implemented and plans are then made for a full implementation. The SSAC would base eventual disposition of this advice item based on how the final implementation of the resulting system (e.g. RDDS, SSAD) takes into account the SSAC’s advice.

 

Phase 3Phase Update
  • SSAC Staff ICANN org worked with the EPDP Phase 2 Small Team to identify what elements of the System for Standardized Access/Disclosure (SSAD) policy recommendations would be needed for a proof of concept, which is meant to be cost effective and simpler than the SSAD, for the purpose of understanding usage and demand for a centralized request service. The service will be operational for up to two years, at which point the Board will make a determination regarding the SSAD policy recommendations. As the SSAD Operational Design Assessment (ODA) identified the identity verification and accreditation feature (SSAD recommendations 1 and 2 from the EPDP Phase 2 Final Report) to be the major drivers of cost and complexity, the Small Team did not recommend inclusion of these recommendations in the proof of concept design, which the GNSO Council recommended and the Board has directed (https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-27-02-2023-en#section1.a) ICANN org to implement. This proof of concept service -- the Registration Data Request Service -- is less complex than the SSAD and will leverage existing ICANN materials, systems, and tools, which is expected to result in a timely launch by November 2023. The service will provide a streamlined experience for both data requestors and ICANN-accredited registrars by providing the centralized platform to submit and receive the data requests with the use of standardized form, making this service reliable and efficient. Furthermore, while this service is streamlined, it does not offer differentiated access due to the exclusion of identity verification and accreditation features. It is important to keep in mind that the service will not remove the requirement that individual registrars - and not the system or ICANN - undertake the legitimate interests balancing test on a case-by-case basis. That said, some people have noted that a standardized intake form, specifying all required inputs, could make it easier for registrars to conduct that test. Finally, the ICANN Board also urged the GNSO Council to consider a Policy Development Process or other means to require registrars to use the service to gather comprehensive data. This advice has been overtaken by subsequent events and will be moved to Phase 5 Close.

 

Phase 3DependenciesPending external activity - the proof-of-concept service for a differentiated access system is developed and implemented and plans are then made for a full implementation.

 

Phase 3Phase ChangeNow in Phase 3: Evaluate & Consider

Phase 2AP FeedbackSSAC confirmed Understanding of Advice.

 

Phase 2Board UnderstandingWith respect to the SSAD recommendations, the Board understands that the SSAC is recommending that the ICANN Board, Generic Name Supporting Organization (GNSO) and ICANN org should take into account the SSAC's previous advice and minority opinion on the SSAD recommendations and collectively rethink and refocus their attention on how to achieve a complete system that is usable, effective, reliable, accessible, and timely. As SSAC is aware, the Board has received additional information from ICANN org's recently completed ODP assessment of the recommendations. We are also looking forward to hearing from the GNSO Small Team (that SSAC is participating in) that has been recently formed to look at the ODP work. We welcome continued dialogue with the SSAC and the entire ICANN community with regards to the next steps as the Board considers the SSAD recommendations.

 

Phase 2AP Feedback1. As SSAC has previously stated, SSAC does not believe that the EPDP produced an SSAD system that is fit for any purpose. As such SSAC has concerns about the resulting operational design phase. 2. The SSAC suggests that SSAC’s previous advice about the SSAD be taken into account. The SSAC had minority opinions about several SSAD-related consensus recommendations. This advice is found in SSAC118v2 and Addendum to SAC118v2, SAC112, SAC111, and SAC104.

 

Phase 2AP Feedback

Additional Context for SSAC’s Response: The proposed SSAD will forward requests from requesters to contracted parties. From an overall system perspective, the SSAD will be just part of the overall system. In an overall system, the other essential functions include: 1. formalization of approved types of requests, 2. authorization of requesters to make those requests, 3. binding of requesters to appropriate obligations, 4. regular audit and notice of breaches, and 5. enforcement in case of breaches.

SSAD is a ticketing system that forwards requests to contracted parties. With respect to the five functions mentioned above, the SSAD design includes accreditation (#2), includes structured requests (#1) for certain fields, includes a legal terms of service (TOS) that covers #3, #4, and #5. However, those functions are included only perfunctorily. There is no evaluation as to whether the requests will be effective, nor is there any retrospective analysis of the performance of how requests are handled.

Worse yet, the current cost estimate for SSAD seems to be quite substantial. The GNSO is currently reacting to the cost estimates provided by Org. But from the SSAC’s point of view, even if the cost of SSAD were not an issue, the overall system would still be problematic.

In SAC118 the SSAC outlined five properties of an overall system see recommendation

  1. Is it Useful, i.e., does it serves the needs of the requesters. ("Can I get the data that helps me get my job done?")
  2. Is it Reliable, i.e., is it predictable and consistent? ("Will I know in advance what requests I can make, and will I get the responses I expect?")
  3. Is it Efficient, i.e., is it quick and cost effective? ("Will I get responses quickly and at a price I can afford?")
  4. Is it Accessible, i.e., are there only minimal barriers to using the system? ("Can I sign up for and get accredited in a straightforward and efficient manner?")
  5. Will the system be Timely, i.e., will it come into existence soon, not years from now? ("How soon will I be able to use this/these system(s)?") 

These properties have quantitative implications. To operate at scale, the vast majority of requests have to be satisfied automatically. Otherwise, the cost of operation will be many orders of magnitude greater than it should be. No matter whether those costs are borne by the requesters, the contracted parties, or by ICANN, the costs will be intolerable.

Automatic operation is also imperative for the system to be useful. A response time measured in days is qualitatively different from a response time measured in seconds. For many uses, a lengthy response reduces or effectively eliminates the usefulness of the system. Although the SSAC acknowledges that the proposed system would allow a contracted party to fulfill some or all requests automatically, if they wish to, the lack of predictability from the end user’s perspective would severely limit the usefulness of the system. The system should include contracted parties’ policies that cover which requests will in fact be responded to automatically.

It is also essential that requesters know in advance whether they will receive an affirmative response. Manual review and negotiation regarding purposes, credentials, etc. might be necessary in a very few cases, but for the vast majority of cases the processing has to be automated and predictable.**

These considerations make it clear that formalization of approved types of requests, authorization of requesters to make those requests, binding of requesters to appropriate obligations, regular audit and notice of breaches, and enforcement in case of breaches, are all necessary.

Thus, in response to the clarifying questions, we offer two perspectives.

  1. The requirements listed above will continue to be important even if Org continues on its present course. The SSAD, as currently specified, fails to address the requirements to be Useful, Reliable, and Efficient. It is unclear how Accessible it will be. (The Timely criterion is already long behind us). Thus, after the SSAD is completed and put into operation, there will still be work needed to put arrangements in place between requesters and contracted parties that streamline and make predictable the request and response process.
  2. Alternatively, an incremental, dynamic approach has the potential for achieving the requirements more completely and more quickly than the current approach. The requesting parties and the contracted parties can easily develop and field one or more. systems that satisfy the operational requirements and include the necessary contractual protections. It is not necessary to build and field a complete system all at once. In fact, it is also certain that evolution will be required even if a putatively complete system were put into operation. There will be an evolving set of purposes, an evolving set of accreditation authorities, etc. In concert with an incremental development approach, it may well be possible to use existing technologies and existing systems. Accreditation and authorization systems are commonplace. The needs of the DNS registration community are not distinct or more complex than the needs of other communities that regularly use single sign-on technology.

Thus, in response to the two clarifying questions you've asked. We recommend the Board, Org and GNSO rethink how to achieve a complete system that is usable, effective, reliable, accessible, and timely.

**"Vast majority" in this context means 99% or more. The cost of manually processing a request will be at least 100 times the cost of automatic processing of a request. If the cost of manual processing is only 100 times the cost of an automatic request and if the percentage of automatically processed requests is only 99%, then 1% of the requests will account for 50% of the cost.

 

Phase 2Clarifying Question
  • SSAC Staff Clarifying Questions: 1) Is the SSAC, in recommending that the GNSO and ICANN org focus their attention on building and operating an effective differentiated access system, supporting the Org’s current operational design phase to inform the Board’s consideration of the SSAD recommendations? 2) Is the SSAC's recommendation suggesting that the ICANN Board should not act on the existing SSAD-related consensus recommendations, and instead build a differentiated access system based on the SSAC's recommendations?

 

Phase 2AP FeedbackThe SSAC Admin Committee disagreed with the org's understanding. Clarifying Comment: Recommendation 1 is directed at ICANN org which requires Board oversight. The SSAC believes the SSAD ODP is the appropriate place for the ICANN Board to consider SAC118 Recommendation 1 and provide a response.

 

Phase 2Board UnderstandingThe ICANN org understands that this statement is the SAC118: SSAC Comments on Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A. As this item will be considered via the Public Comment process, there is no action for the ICANN Board, and the item will be considered closed. If you do not agree with ICANN org's understanding, reply to this email with the word NO in the first line. Please provide clarifying comments on the second line.

 

Phase 2Phase ChangeNow in Phase 2: Understand

 

Phase 1Phase UpdateICANN is in receipt of the following advice to the ICANN Board of Directors: SAC118: SSAC Comments on Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A This advice is now in process and has been assigned case number 00022514. Please retain this number for your records. Please note acknowledgement of advice does not imply acceptance or promise of implementation. An ICANN representative will be reaching out to you to begin the process of ensuring that the Security and Stability Advisory Committee (SSAC) and ICANN share a mutual understanding of the actionable items of these recommendations. Thank you for your time and the work involved in producing this statement.

 

Phase 1Phase UpdateICANN acknowledged receipt of Advice SAC118.

 

Phase 1Phase UpdateSSAC published SAC118: SSAC Comments on Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team – PHASE 2A Link: https://www.icann.org/en/system/files/files/sac-118-en.pdf.