System for Standardized Access/Disclosure: Difference between revisions

(45 intermediate revisions by 2 users not shown)

Line 1:

The '''System for Standardized Access/Disclosure (SSAD)''' is a system proposed to centrally handle requests for non-public registration data, envisioned in Recommendations 1-18 of the Final Report of the GNSO Expedited Policy Development Process ([[EPDP]]) on the Temporary Specification for gTLD Registration Data Phase 2.

The '''System for Standardized Access/Disclosure (SSAD)''' is a system proposed to centrally handle requests for non-public registration data, envisioned in Recommendations 1-18 of the Final Report of the GNSO Expedited Policy Development Process ([[EPDP]]) on the Temporary Specification for gTLD Registration Data Phase 2. Whereas [[RDAP]] is an ''access'' protocol for registration data, [[SSAD]] is a ''request'' protocol.

==History==

# [[Whois]]

# Era of [[Whois]]

# [[GDPR]]

# [[GDPR]] goes into effect (2018)

# The GNSO engages in an [[EPDP]] on the [[Temporary Specification for gTLD Registration Data]]

## [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)#Phases|Phase 2]] outlines the GNSO's requirements for data requestor accreditation; request and response criteria and content; service level agreements; process automation; terms and conditions; logging, auditing, and reporting requirements

#* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)#Phases|Phase 2]] outlines the GNSO's requirements for data requestor accreditation; request and response criteria and content; service level agreements; process automation; terms and conditions; logging, auditing, and reporting requirements

# Recommendations 1-18 from TempSpec Phase 2 EPDP Final Report about what to include in a proposed centralized registration data system (SSAD) is sent to ICANN Board

# the [[ICANN Board]] requests an [[ODP]] to inform its SSAD deliberations, including whether the recommendations are in the best interests of the [[ICANN Community]] and [[ICANN Organization]]

## research and deliberations take place and ICANN hosts updated/feedback gathering webinars

#* research and deliberations take place and ICANN hosts updated/feedback gathering webinars (2021)

# ODP results in an [[Operational Design Assessment]] (ODA)

==EPDP Phase 2 Final Report & Recommendations==

Phase 2 of the [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Temp Spec]] was largely focused on the recommendation for the creation of a system of access and disclosure of anonymized or proxied registration data. Their final report was issued in July 2020.<ref name="finalrep">[https://gnso.icann.org/en/correspondence/epdp-phase-2-temp-spec-gtld-registration-data-2-31jul20-en.pdf EPDP Temp Spec Workspace - Phase 2 Final Report], July 31, 2020.</ref> The report's recommendations were intended to be an integrated set of proposals for a system where accredited parties could request nonpublic registration data from a centralized clearinghouse for such requests, and the determinations regarding such requests would be delegated to the relevant contracted parties.<ref>[https://www.icann.org/en/blogs/details/epdp-phase-2-team-publishes-final-report-10-8-2020-en ICANN.org Blog - EPDP Phase 2 Team Publishes Final Report], August 10, 2020</ref> The recommendations covered a variety of topics:

* Accreditation of SSAD requestors, including governmental entities;

* Required criteria and content of SSAD requests;

* Response requirements;

* Required Service Level Agreements (SLAs);

* Automation of SSAD processing;

* Terms and conditions of SSAD;

* Logging, auditing, and reporting requirements; and

* Implementation of a GNSO Standing Committee charged with evaluating SSAD operational issues and proposing recommendations for improvement to the GNSO Council.

==Key Figures==

===From ICANN Org===

* [[Yuko Yokoyama]]

* [[Francisco Arias Correa]]

* [[Eduardo Alvarez]]

* [[Jonathan Denison]]

===EPDP Phase 2 Small Team===

An EPDP Phase 2 Small Team was formed to review the SSAD ODA and started meeting in February 2022.<ref>[https://community.icann.org/collector/pages.action?key=EOTSFGRD EPDP Phase 2 Small Team, ICANN Community]</ref>

* [[Alan Greenberg]]

* [[Steve DelBianco]]

* [[Chris Lewis-Evans]]

* [[Laureen Kapin]]

* [[John McElwaine]]

* [[Terri Agnew]] (Staff)

* [[Marika Koning]] (Staff)

* [[Berry Cobb]] (Staff)

* [[Caitlin Tubergen]] (Staff)

* [[Thomas Rickert]]

* [[Paul McGrady]]

* [[Olga Cavalli]]

* [[Stephanie Perrin]]

* [[Sarah Wyld]]

* [[Greg DiBiase]] (Alternate)

* [[Marc Anderson]]

* [[Sebastien Ducos]]

==SSAD Components==

==Operational Design Phase==

===~~Actors~~===

ICANN staff launched the [[Operational Design Phase]] (ODP) for the SSAD recommendations in April 2021.<ref name="odpdash">[https://www.icann.org/ssadodp ICANN.org - SSAD Operational Design Phase Dashboard], last updated January 25, 2022</ref> The ODP provided an opportunity to "assess the potential risks, anticipated costs, resource requirements, timelines, dependencies, interaction with the Global Public Interest Framework that is currently being piloted, and other matters related to the implementation of the SSAD-related recommendations (1-18)."<ref name="odpdash" /> Because of the complexity of the system being proposed, the ICANN Board determined that it would be valuable for the organization to engage in that assessment.<ref>[https://www.icann.org/resources/board-material/resolutions-2021-03-25-en#2.c Resolution of the Board] initiating the SSAD ODP, March 25, 2021</ref> The Board drafted a scoping paper for the ODP, including questions for consideration.<ref>[https://www.icann.org/en/system/files/files/ssad-non-public-registration-data-odp-scoping-25mar21-en.pdf ICANN.org - SSAD Non-Public Registration Data ODP Scoping], March 25, 2021</ref>

===~~Subsystems~~==

===~~Business Processes~~===

===Key Components===

[[ICANN Organization]] gave an update on the SSAD's key components in November 2021.<ref>[https://www.icann.org/en/system/files/files/presentation-ssad-odp-project-update-18nov21-en.pdf SSAD ODP Update Presentation, Nov 2021, ICANN]</ref>

{| class=wikitable

! Actors !! Subcategories !! Roles !! Subsystems !! Requests

|-

| Data disclosure requestors || natural and legal persons || * submits the data disclosure request * To be accredited and periodically renewed by the accreditation authority in order to submit data disclosure requests and for verification of requestor identity * Manages authentication details, such as supported electronic IDs (eID) and SSAD-specific identity credentials || [[RDAP]] clients || can be for: * Specific domain names * non-public fields (RFC 8982 - RDAP partial response) * Supporting documentation; * Verified requestor identity (name, organization, country/territory); * Verified requestor declarations; * Confidentiality classification need to include purpose and legal basis priority: * Urgent * ICANN administrative proceedings

|-

|| || Governments and IGOs || * submits the data disclosure request * submits the data disclosure request * To be accredited and periodically renewed by the accreditation authority in order to submit data disclosure requests and for verification of requestor identity * Manages authentication details, such as supported electronic IDs (eID) and SSAD-specific identity credentials || || ||

|-

| Accreditation Authorities || Central Accreditation Authority || * validates request and relays to the central gateway; * vendor contracted to develop and operate the system that acts as the sole interface with SSAD requestors for verifying requestor identity, managing disclosure requests, authenticating requestors on behalf of the central gateway and contracted parties; * notifies requestor; * Manage billing process for requestors; * Transfer request-processing fees to the central gateway; * delegate some functions to “identity providers” in English; * support verifying requestor declarations of trademark ownership; * billing for accreditation/Identity verification, requestor declaration verification, and disclosure request processing; * support federated authentication of requestors using OpenID Connect || * Web portal *API ||

|-

|| ||Country/territory governmental accreditation authorities || * designated by country/territory government to Implement the same interfaces as the central accreditation; * notifies requestor; * integrate with the central gateway and contracted parties in their chosen languages; * support the verification of declarations for requests processed automatically (as described in Recommendations 9.4.1 and 9.4.2); * billing for accreditation/Identity verification, requestor declaration verification, and disclosure request processing; * support federated authentication of requestors using OpenID Connect || || ||

|-

| Central Gateway || ||* verifies criteria for automated processing (Rec. 9.4); * notifies contracted parties via email and poll message through the API; * relays determination to accreditation authority; * vendor contracted to develop and operate the system; * can implement a recommendation engine for contracted parties on whether to approve or deny disclosure requests || * Web portal *API || ||

|-

| Abuse Investigator || ||* vendor contracted to investigate abuse; * Monitors standard operation metrics, requestor compliance with SSAD terms of service * verifies abuse reports contracted parties and data subjects/public * Provides requestors’ redress mechanism (rec. 13.1.3) || || ||

|-

| Contracted parties || [[Registries]] || * (secondary) reviews the request and communicates determination back to the central gateway; * may opt out/request an exemption for automated processing of any specific category of disclosure requests from recommendation 9.4; * the sole authorizers of data disclosure requests directed at them || [[RDAP]] service ||

|-

|| ||ICANN-accredited [[registrars]] || * (primary) reviews the request and communicates determination back to the central gateway; * may opt out/request an exemption for automated processing of any specific category of disclosure requests from recommendation 9.4; * the sole authorizers of data disclosure requests directed at them || [[RDAP]] service || ||

|-

| Auditors || || * vendor contracted to audit system || || ||

|-

| [[ICANN Community|Data subjects]] || || || ||

|-

| [[ICANN Organization|ICANN org]] || || Publishes on a quarterly basis a summary of the: * Number of disclosure requests received, Approved/Denied, Automated/Manual * Third-Party purposes/justifications * Complaints per priority level with average response times * Information about the financial sustainability of SSAD * New EDPB guidance or new topical jurisprudence * Technical or system difficulties * Operational and system enhancements * [[Contractual Compliance]] is responsible for the investigation of complaints regarding: Contracted parties’ procedural deficiencies in SSAD responses; and Failure to respond to urgent priority requests within the timeframes established by the SLA || * icann.org portal * NSp || ||

|}

===Projected Specifications and Reasons===

On December 20, 2021, [[ICANN Organization]] and several [[ICANN Board]] members briefed the [[GNSO Council]] on the initial findings of the org's ODP analysis, including the following details.<ref>[https://www.icann.org/en/blogs/details/icann-presents-estimated-ssad-costs-and-fees-to-gnso-council-21-12-2021-en Estimated SSAD Costs and Fees Presented to GNSO Council, ICANN Blogs]</ref>

{| class="wikitable"

|-

!

! Development Timeframe

! Development Costs

! Operational Costs

! Cost Recovery

|-

| '''Amount'''

| '''3 - 4 Years''' (including parallel [[Implementation Review Team|IRT]] for '''2 years''')

|'''$20M - $27M'''

| '''$14M - $107M/Year'''

| * Accreditations/Identity Verifications: '''$86 - $21''' (low - high usage) * Requestor Declaration Verification: '''$190 - $160''' (low - high usage) * Disclosure Requests: '''$40 - $0.45''' (low - high usage)

|-

| '''Reasons'''

| * Selection of vendors * Vendor ramp-up * System development * Legal instrument development * Communications plan and support * Development and confirmation of requirements * Policy document development

| * development outsourced

| * Ongoing operations outsourced * User accreditation volume drives cost * ICANN org oversees ongoing operations, vendors, etc. * 7 functions to fill through RFPs

|ICANN Org assumes there will be between '''25,000 and 3 million users''' and '''100,000 and 12 million requests''' based on [[CPH|contracted parties]] and [[ICANN Community]] surveys, [https://www.icann.org/en/blogs/details/registration-data-directory-services-rdds-roadmap-update-20-2-2020-en RDDS] requests, and abuse rates and because requestors may still directly go to the contracted party, bypassing SSAD entirely.

|}

===Operational Design Assessment===

ICANN org published its [[Operational Design Assessment]] on January 25, 2022.<ref name="odaannounce">[https://www.icann.org/en/announcements/details/icann-delivers-operational-design-assessment-of-ssad-recommendations-25-1-2022-en ICANN.org - ICANN Delivers ODA of SSAD Recommendations], January 25, 2022</ref> The Assessment identified a number of challenges with SSAD as proposed by the recommendations.<ref name="oda">[https://www.icann.org/en/system/files/files/ssad-oda-25jan22-en.pdf ICANN.org - SSAD Operational Design Assessment], January 25, 2022</ref> One of the largest issues was SSAD's interaction with proxy and privacy services offered by registrars. The assessment noted a study by [[Interisle]] from January 2021 that approximated that 86.5% of registered gTLDs were covered by either a proxy service or a privacy shield.<ref>[https://interisle.net/ContactStudy2021.pdf Interisle.net: WHOIS Contact Data Availability and Registrant Classification Study], January 2021, page 3 (PDF)</ref> As a result, the ODA noted, "the existence of proxy and privacy services poses several challenges to the system’s operations..."<ref name="oda" /> The SSAD as designed "assumes the system will only handle base-case requests for data for non-proxy/privacy service registrations,"<ref name="oda" /> and does not make any provision to compel production of registration data that is cloaked by a proxy or privacy service. Beyond the expectation that privacy or proxy services provide "full information" about the privacy or proxy service and the means of contacting such services, the [[Temporary Specification for gTLD Registration Data|Temporary Specification]] did not address such services. Because the EPDP charter addressed only the text of the Temporary Specification, the handling of proxied or private data was largely unaddressed.<ref name="oda" />

This finding gave rise to substantial concern among the ICANN Board. As [[Maarten Botterman]] noted in a letter to the GNSO Council, "[t]here is no guarantee that SSAD users would receive the registration data they request via this system" because such a high volume of registration data is contained within a proxy or privacy service.<ref name="odaletter">[https://mm.icann.org/pipermail/council/attachments/20220125/81d60ddc/2022-01-24BoardtoCouncilonSSADconsultation-0001.pdf GNSO Council Listserv Archive - Board to Council re: Upcoming SSAD Consultation], January 24, 2022</ref> Botterman's letter was intended to initiate conversation and thought prior to a scheduled meeting of the Board and GNSO Council on January 27, 2022.<ref name="odaletter" /><ref name="odpdash" /> That meeting was a constructive exchange of views on the viability of SSAD, although no conclusions were drawn. In particular, the discussants raised topics such as the merits and costs of accreditation, the legal risks involved in SSAD, the development of a requestor code of conduct, the need for a pilot version, shortening the timeline, and improving the estimate of potential users.

== Whois Disclosure System (FKA Simple Ticketing System or SSAD Light)==

The [[Whois Disclosure System]] was one outcome of the ODA was the development of an idea for a simple ticketing system (STS) designed to centralize requests for registrant information disclosures.<ref>[https://circleid.com/posts/20220404-icann-ssad-proposal-poised-to-succeed ICANN SSAD Proposal Poised to Succeed, Paul McGrady, CircleID]</ref>

==References==

@@ Line 1: / Line 1: @@
-The '''System for Standardized Access/Disclosure (SSAD)''' is a system proposed to centrally handle requests for non-public registration data, envisioned in Recommendations 1-18 of the Final Report of the GNSO Expedited Policy Development Process ([[EPDP]]) on the Temporary Specification for gTLD Registration Data Phase 2.
+The '''System for Standardized Access/Disclosure (SSAD)''' is a system proposed to centrally handle requests for non-public registration data, envisioned in Recommendations 1-18 of the Final Report of the GNSO Expedited Policy Development Process ([[EPDP]]) on the Temporary Specification for gTLD Registration Data Phase 2. Whereas [[RDAP]] is an ''access'' protocol for registration data, [[SSAD]] is a ''request'' protocol.
 ==History==
-# [[Whois]]
+# Era of [[Whois]]
-# [[GDPR]]
+# [[GDPR]] goes into effect (2018)
 # The GNSO engages in an [[EPDP]] on the [[Temporary Specification for gTLD Registration Data]]
-## [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)#Phases|Phase 2]] outlines the GNSO's requirements for data requestor accreditation; request and response criteria and content; service level agreements; process automation; terms and conditions; logging, auditing, and reporting requirements
+#* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)#Phases|Phase 2]] outlines the GNSO's requirements for data requestor accreditation; request and response criteria and content; service level agreements; process automation; terms and conditions; logging, auditing, and reporting requirements
 # Recommendations 1-18 from TempSpec Phase 2 EPDP Final Report about what to include in a proposed centralized registration data system (SSAD) is sent to ICANN Board
 # the [[ICANN Board]] requests an [[ODP]] to inform its SSAD deliberations, including whether the recommendations are in the best interests of the [[ICANN Community]] and [[ICANN Organization]]
-## research and deliberations take place and ICANN hosts updated/feedback gathering webinars
+#* research and deliberations take place and ICANN hosts updated/feedback gathering webinars (2021)
 # ODP results in an [[Operational Design Assessment]] (ODA)
+==EPDP Phase 2 Final Report & Recommendations==
+Phase 2 of the [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Temp Spec]] was largely focused on the recommendation for the creation of a system of access and disclosure of anonymized or proxied registration data. Their final report was issued in July 2020.<ref name="finalrep">[https://gnso.icann.org/en/correspondence/epdp-phase-2-temp-spec-gtld-registration-data-2-31jul20-en.pdf EPDP Temp Spec Workspace - Phase 2 Final Report], July 31, 2020.</ref> The report's recommendations were intended to be an integrated set of proposals for a system where accredited parties could request nonpublic registration data from a centralized clearinghouse for such requests, and the determinations regarding such requests would be delegated to the relevant contracted parties.<ref>[https://www.icann.org/en/blogs/details/epdp-phase-2-team-publishes-final-report-10-8-2020-en ICANN.org Blog - EPDP Phase 2 Team Publishes Final Report], August 10, 2020</ref> The recommendations covered a variety of topics:
+* Accreditation of SSAD requestors, including governmental entities;
+* Required criteria and content of SSAD requests;
+* Response requirements;
+* Required Service Level Agreements (SLAs);
+* Automation of SSAD processing;
+* Terms and conditions of SSAD;
+* Logging, auditing, and reporting requirements; and
+* Implementation of a GNSO Standing Committee charged with evaluating SSAD operational issues and proposing recommendations for improvement to the GNSO Council.
 ==Key Figures==
+===From ICANN Org===
 * [[Yuko Yokoyama]]
+* [[Francisco Arias Correa]]
+* [[Eduardo Alvarez]]
+* [[Jonathan Denison]]
+===EPDP Phase 2 Small Team===
+An EPDP Phase 2 Small Team was formed to review the SSAD ODA and started meeting in February 2022.<ref>[https://community.icann.org/collector/pages.action?key=EOTSFGRD EPDP Phase 2 Small Team, ICANN Community]</ref>
+* [[Alan Greenberg]]
+* [[Steve DelBianco]]
+* [[Chris Lewis-Evans]]
+* [[Laureen Kapin]]
+* [[John McElwaine]]
+* [[Terri Agnew]] (Staff)
+* [[Marika Koning]] (Staff)
+* [[Berry Cobb]] (Staff)
+* [[Caitlin Tubergen]] (Staff)
+* [[Thomas Rickert]]
+* [[Paul McGrady]]
+* [[Olga Cavalli]]
+* [[Stephanie Perrin]]
+* [[Sarah Wyld]]
+* [[Greg DiBiase]] (Alternate)
+* [[Marc Anderson]]
+* [[Sebastien Ducos]]
-==SSAD Components==
+==Operational Design Phase==
-===Actors===
+ICANN staff launched the [[Operational Design Phase]] (ODP) for the SSAD recommendations in April 2021.<ref name="odpdash">[https://www.icann.org/ssadodp ICANN.org - SSAD Operational Design Phase Dashboard], last updated January 25, 2022</ref> The ODP provided an opportunity to "assess the potential risks, anticipated costs, resource requirements, timelines, dependencies, interaction with the Global Public Interest Framework that is currently being piloted, and other matters related to the implementation of the SSAD-related recommendations (1-18)."<ref name="odpdash" /> Because of the complexity of the system being proposed, the ICANN Board determined that it would be valuable for the organization to engage in that assessment.<ref>[https://www.icann.org/resources/board-material/resolutions-2021-03-25-en#2.c Resolution of the Board] initiating the SSAD ODP, March 25, 2021</ref> The Board drafted a scoping paper for the ODP, including questions for consideration.<ref>[https://www.icann.org/en/system/files/files/ssad-non-public-registration-data-odp-scoping-25mar21-en.pdf ICANN.org - SSAD Non-Public Registration Data ODP Scoping], March 25, 2021</ref>
-===Subsystems==
-===Business Processes===
+===Key Components===
+[[ICANN Organization]] gave an update on the SSAD's key components in November 2021.<ref>[https://www.icann.org/en/system/files/files/presentation-ssad-odp-project-update-18nov21-en.pdf SSAD ODP Update Presentation, Nov 2021, ICANN]</ref>
+{| class=wikitable
+! Actors !! Subcategories !! Roles !! Subsystems !! Requests
+|-
+| Data disclosure requestors || natural and legal persons || * submits the data disclosure request <br/> * To be accredited and periodically renewed by the accreditation authority in order to submit data disclosure requests and for verification of requestor identity <br/> * Manages authentication details, such as supported electronic IDs (eID) and SSAD-specific identity credentials || [[RDAP]] clients ||  can be for:<br/>* Specific domain names<br/>* non-public fields (RFC 8982 - RDAP partial response)<br/>  * Supporting documentation; <br/> * Verified requestor identity (name, organization, country/territory);<br/>  * Verified requestor declarations;<br/>  * Confidentiality classification <br/>  need to include purpose and legal basis <br/>  priority:<br/>   * Urgent<br/>  * ICANN administrative proceedings
+|-
+|| || Governments and IGOs || * submits the data disclosure request <br/> * submits the data disclosure request <br/> * To be accredited and periodically renewed by the accreditation authority in order to submit data disclosure requests and for verification of requestor identity <br/> * Manages authentication details, such as supported electronic IDs (eID) and SSAD-specific identity credentials  ||  ||  ||
+|-
+| Accreditation Authorities || Central Accreditation Authority || * validates request and relays to the central gateway;<br/>  * vendor contracted to develop and operate the system that acts as the sole interface with SSAD requestors for verifying requestor identity, managing disclosure requests, authenticating requestors on behalf of the central gateway and contracted parties;<br/>  * notifies requestor;<br/>  * Manage billing process for requestors;<br/>  * Transfer request-processing fees to the central gateway;<br/>  * delegate some functions to “identity providers” in English;<br/>  * support verifying requestor declarations of trademark ownership;<br/>  * billing for accreditation/Identity verification, requestor declaration verification,  and disclosure request processing; <br/> * support federated authentication of requestors using OpenID Connect || * Web portal<br/>  *API ||
+|-
+|| ||Country/territory governmental accreditation authorities || * designated by country/territory government to Implement the same interfaces as the central accreditation;<br/>  * notifies requestor;<br/>  * integrate with the central gateway and contracted parties in their chosen languages;<br/>  * support the verification of declarations for requests processed automatically (as described in Recommendations 9.4.1 and 9.4.2); <br/> * billing for accreditation/Identity verification, requestor declaration verification, and disclosure request processing; <br/> * support federated authentication of requestors using OpenID Connect ||  ||  ||
+|-
+| Central Gateway || ||* verifies criteria for automated processing (Rec. 9.4);<br/>  * notifies contracted parties via email and poll message through the API;<br/>  * relays determination to accreditation authority;<br/>  * vendor contracted to develop and operate the system;<br/>  * can implement a recommendation engine for contracted parties on whether to approve or deny disclosure requests || * Web portal<br/>  *API ||  ||
+|-
+| Abuse Investigator || ||* vendor contracted to investigate abuse;<br/>  * Monitors standard operation metrics, requestor compliance with SSAD terms of service <br/> * verifies abuse reports contracted parties and data subjects/public<br/>  * Provides requestors’ redress mechanism (rec. 13.1.3) ||  ||  ||
+|-
+| Contracted parties || [[Registries]] || * (secondary) reviews the request and communicates determination back to the central gateway;<br/>  * may opt out/request an exemption for automated processing of any specific category of disclosure requests from recommendation 9.4;<br/>  * the sole authorizers of data disclosure requests directed at them ||  [[RDAP]] service ||
+|-
+|| ||ICANN-accredited [[registrars]] || * (primary) reviews the request and communicates determination back to the central gateway;<br/>  * may opt out/request an exemption for automated processing of any specific category of disclosure requests from recommendation 9.4;<br/>  * the sole authorizers of data disclosure requests directed at them || [[RDAP]] service ||  ||
+|-
+| Auditors || || * vendor contracted to audit system ||  ||  ||
+|-
+| [[ICANN Community|Data subjects]] ||  ||  ||  ||
+|-
+| [[ICANN Organization|ICANN org]] || || Publishes on a quarterly basis a summary of the: <br />* Number of disclosure requests received, Approved/Denied, Automated/Manual<br/> * Third-Party purposes/justifications<br/> * Complaints per priority level with average response times<br/> * Information about the financial sustainability of SSAD<br/> * New EDPB guidance or new topical jurisprudence <br/> * Technical or system difficulties<br/> * Operational and system enhancements <br/> * [[Contractual Compliance]] is responsible for the investigation of complaints regarding:  <br>Contracted parties’ procedural deficiencies in SSAD responses; and<br/>  Failure to respond to urgent priority requests within the timeframes established by the SLA || * icann.org portal<br/>  * NSp ||  ||
+|}
+===Projected Specifications and Reasons===
+On December 20, 2021, [[ICANN Organization]] and several [[ICANN Board]] members briefed the [[GNSO Council]] on the initial findings of the org's ODP analysis, including the following details.<ref>[https://www.icann.org/en/blogs/details/icann-presents-estimated-ssad-costs-and-fees-to-gnso-council-21-12-2021-en Estimated SSAD Costs and Fees Presented to GNSO Council, ICANN Blogs]</ref>
+{| class="wikitable"
+|-
+!
+! Development Timeframe
+! Development Costs
+! Operational Costs
+! Cost Recovery
+|-
+| '''Amount'''
+| '''3 - 4 Years''' (including parallel [[Implementation Review Team|IRT]] for '''2 years''')
+|'''$20M - $27M'''
+| '''$14M - $107M/Year'''
+| * Accreditations/Identity Verifications:<br />'''$86 - $21''' (low - high usage)<br />* Requestor Declaration Verification:<br />'''$190 - $160''' (low - high usage)<br />* Disclosure Requests:<br />'''$40 - $0.45''' (low - high usage)
+|-
+| '''Reasons'''
+| * Selection of vendors<br />* Vendor ramp-up<br />* System development<br />*  Legal instrument<br />development<br />* Communications plan<br />and support<br />* Development and<br />confirmation of<br />requirements * Policy document<br />development
+| * development outsourced
+| * Ongoing<br />operations<br />outsourced<br />* User<br />accreditation<br />volume drives<br />cost<br />* ICANN org<br />oversees ongoing<br />operations,<br />vendors, etc.<br />* 7 functions to fill<br />through RFPs
+|ICANN Org assumes there will be between '''25,000 and 3 million users''' and '''100,000 and 12 million requests''' based on [[CPH|contracted parties]] and [[ICANN Community]] surveys, [https://www.icann.org/en/blogs/details/registration-data-directory-services-rdds-roadmap-update-20-2-2020-en RDDS] requests, and abuse rates and because requestors may still directly go to the contracted party, bypassing SSAD entirely.
+|}
+===Operational Design Assessment===
+ICANN org published its [[Operational Design Assessment]] on January 25, 2022.<ref name="odaannounce">[https://www.icann.org/en/announcements/details/icann-delivers-operational-design-assessment-of-ssad-recommendations-25-1-2022-en ICANN.org - ICANN Delivers ODA of SSAD Recommendations], January 25, 2022</ref> The Assessment identified a number of challenges with SSAD as proposed by the recommendations.<ref name="oda">[https://www.icann.org/en/system/files/files/ssad-oda-25jan22-en.pdf ICANN.org - SSAD Operational Design Assessment], January 25, 2022</ref> One of the largest issues was SSAD's interaction with proxy and privacy services offered by registrars. The assessment noted a study by [[Interisle]] from January 2021 that approximated that 86.5% of registered gTLDs were covered by either a proxy service or a privacy shield.<ref>[https://interisle.net/ContactStudy2021.pdf Interisle.net: WHOIS Contact Data Availability and Registrant Classification Study], January 2021, page 3 (PDF)</ref> As a result, the ODA noted, "the existence of proxy and privacy services poses several challenges to the system’s operations..."<ref name="oda" /> The SSAD as designed "assumes the system will only handle base-case requests for data for non-proxy/privacy service registrations,"<ref name="oda" /> and does not make any provision to compel production of registration data that is cloaked by a proxy or privacy service. Beyond the expectation that privacy or proxy services provide "full information" about the privacy or proxy service and the means of contacting such services, the [[Temporary Specification for gTLD Registration Data|Temporary Specification]] did not address such services. Because the EPDP charter addressed only the text of the Temporary Specification, the handling of proxied or private data was largely unaddressed.<ref name="oda" />
+This finding gave rise to substantial concern among the ICANN Board. As [[Maarten Botterman]] noted in a letter to the GNSO Council, "[t]here is no guarantee that SSAD users would receive the registration data they request via this system" because such a high volume of registration data is contained within a proxy or privacy service.<ref name="odaletter">[https://mm.icann.org/pipermail/council/attachments/20220125/81d60ddc/2022-01-24BoardtoCouncilonSSADconsultation-0001.pdf GNSO Council Listserv Archive - Board to Council re: Upcoming SSAD Consultation], January 24, 2022</ref> Botterman's letter was intended to initiate conversation and thought prior to a scheduled meeting of the Board and GNSO Council on January 27, 2022.<ref name="odaletter" /><ref name="odpdash" /> That meeting was a constructive exchange of views on the viability of SSAD, although no conclusions were drawn. In particular, the discussants raised topics such as the merits and costs of accreditation, the legal risks involved in SSAD, the development of a requestor code of conduct, the need for a pilot version, shortening the timeline, and improving the estimate of potential users.
+== Whois Disclosure System (FKA Simple Ticketing System or SSAD Light)==
+The [[Whois Disclosure System]] was one outcome of the ODA was the development of an idea for a simple ticketing system (STS) designed to centralize requests for registrant information disclosures.<ref>[https://circleid.com/posts/20220404-icann-ssad-proposal-poised-to-succeed ICANN SSAD Proposal Poised to Succeed, Paul McGrady, CircleID]</ref>
+==References==