Last week, we held the fourth webinar update on the System for Standardized Access/Disclosure (SSAD) Operational Design Phase (ODP). We focused our presentation on the additional design elements for the SSAD, including the business process design. We thank all who were able to join the webinar, and invite those who couldn't make it to listen to the recording, and share your thoughts.
As we have done following previous webinars, this blog provides a recap of what was presented, and restates the questions that were directed at the community to solicit feedback on the design elements shared:
- Did we capture all the necessary actions as outlined in the recommendations for accreditation, submitting disclosure requests, and routing them to contracted parties?
- Are there any actors or subsystems missing from this model, or roles and responsibilities not identified that you think should be included?
The SSAD ODP team presented the proposed business process design for the system, based on the policy recommendations in the final report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Phase 2. This design incorporates the recommendations for accreditation and submission of disclosure requests. It also includes recommendations on how those requests would be routed to contracted parties for review, all the way up to the actual disclosure of data to the requestor where applicable. Additionally, the team outlined the various roles and responsibilities identified by the SSAD project team.
It is important to remember that even though those requesting data via the SSAD must be accredited, accreditation alone does not guarantee data disclosure. In most instances, each contracted party that receives the data disclosure request will evaluate the request and determine, based on their own criteria, whether to disclose any of the requested data.
The project team further highlighted the audit approach incorporated into the SSAD design to ensure conformity to the business processes and system designs put in place. The team also emphasized the supplementary system requirements that would need to be in place, such as service level agreements, system logging and data retention, and SSAD reporting content and frequency.
The SSAD ODP team has met for more than 200 hours to draft the proposed design shared in this webinar, as well as the other elements of the Operational Design Assessment (ODA), that have been shared to date. In addition, individual team members have dedicated many more hours to research, write, and design the proposed SSAD. The team is eager to hear the community's feedback on its work.
ICANN community engagement and transparency during this ODP process is critical to its success. If you have questions or would like to provide input on the questions outlined above, please send an email to ODP-SSAD@icann.org. All submissions will be publicly archived and available to view here. Please review the terms and acknowledgment before submitting your comment, available here.
The SSAD ODP project team will hold its next webinar to discuss associated costs and fee structure, as well as an estimated timeline for the SSAD. Though we intended to hold this webinar in December, we have postponed until after the new year to allow time for the Board and GNSO Council to consider next steps regarding the Board-GNSO Council consultation on the financial sustainability of the SSAD.
