icannwiki

System for Standardized Access/Disclosure: Difference between revisions

← Older edit
VisualWikitext
Jessica (talk | contribs)
Bureaucrats, Check users, lookupuser, Administrators, translator
14,952 edits
Christiane (talk | contribs)
Bureaucrats, steward, Administrators, translator
3,206 edits
m Christiane moved page SSAD to System for Standardized Access/Disclosure: Standardize
 
(3 intermediate revisions by one other user not shown)
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==
==History==
Line 12: Line 12:


==EPDP Phase 2 Final Report & Recommendations==
==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 recommendation for creations 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 request, 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:
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;
* Accreditation of SSAD requestors, including governmental entities;
* Required criteria and content of SSAD requests;
* Required criteria and content of SSAD requests;
Line 48: Line 48:


==Operational Design Phase==
==Operational Design Phase==
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 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>
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>


===Key Components===
===Key Components===
Line 102: Line 102:


===Operational Design Assessment===
===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 took note of 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" />
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.
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)==
== Whois Disclosure System (FKA Simple Ticketing System or SSAD Light)==
One outcome of the ODA is 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> If it runs as a pilot version of the SSAD, it will provide data that may help ICANN staff refine the SSAD proposal. Following its review of the ODA and a meeting and several rounds of correspondence with the board, the GNSO Council formed a small team to develop the concept of the simple ticketing system (STS) and ICANN Staff began researching the STS's development cost and timeframe. The STS will document requests' nature, receiving registrars, response speed (if at all), and appropriateness of disclosure. The STS will also yield estimates of how many users and requests to expect of the eventual SSAD.<ref>[https://circleid.com/posts/20220404-icann-ssad-proposal-poised-to-succeed ICANN SSAD Proposal Poised to Succeed, Paul McGrady, CircleID]</ref> <br/>
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>
At the April 2022 GNSO Council meeting, [[Sebastien Ducos]] explained that the idea was for the Board to pause any decision on the SSAD and instead enter what was a pilot phase but became a [https://gnso.icann.org/sites/default/files/policy/2022/correspondence/ducos-to-gnso-council-et-al-04apr22-en.pdf proof of concept] phase (as of April 4, 2022) to arrive at a simplified SSAD version to run for up to two years in six-month increments to review/test hypotheses about who, what, when, why in terms of traffic at each interval and estimate what would be required and how to deliver it.<ref>[https://gnso.icann.org/sites/default/files/policy/2022/transcript/transcript-gnso-council-14apr22-en.pdf GNSO Council Meeting April 4, 2022, Transcript pg. 16, GNSO, ICANN.org]</ref><br/>
On April 27, 2022, the GNSO Council requested that while its STS small team worked on the proof of concept now called the "SSAD Light," the ICANN Board pause consideration of the SSAD recommendations.<ref>[https://gnso.icann.org/sites/default/files/policy/2022/correspondence/fouquart-to-botterman-27apr22-en.pdf Status Update EPDP Phase 2 & Review of ODA, GNSO Council Letter to ICANN Board, April 27, 2022]</ref> <br/>
The SSAD Light Concept was developed by ICANN Org to reflect the small team's recommendations for a more affordable, simpler ticketing system, which will ''not'' include:
* all the [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data|EPDP Phase 2]] policy recommendations,
* central or governmental accreditation authorities,
* identity verification of requestors,
* an abuse investigator,
* an obligation or expectation of automated processing of certain requests by contracted parties, or
* billing since ICANN will not pass operational costs to requestors.<br/>
Instead, the SSAD Light proof of concept ''will'':
* be based on the design described in the SSAD [[ODA]],
* incorporate changes in the design to allow for a more effective model,
* minimize development and operational costs of the system,
* collect request statuses (e.g., approved, denied) from [[CPH|contracted parties]], and
* gather data on response times from contracted parties for requests of different priorities.<ref>[https://gnso.icann.org/sites/default/files/policy/2022/correspondence/fouquart-to-botterman-27apr22-en.pdf Status Update EPDP Phase 2 & Review of ODA, GNSO Council Letter to ICANN Board, April 27, 2022]</ref><br/>
At [[ICANN 74]], the GNSO held a session on EPDP Phase 2 concerning the latest developments on the creation of what used to be called SSAD. During this session, [[Ashwin Rangan]] explained how the Whois disclosure system will work. It will:
* use ICANN systems that already exist
* leverage existing and proven ICANN design patterns already available for use by the [[ICANN Community]] (such as the naming services portal, operating on salesforce), existing technology stacks (ICANN Account operating on okta identity platform), and
* rely on in-house expertise and users.
The Whois disclosure system needs to be written but will be a traffic cop in the middle. The latest version of this proof of concept or minimal viable product proposal involves the removal of authentication. What's left are accreditation and access.<ref>[https://74.schedule.icann.org/meetings/ GNSO:EPDP Phase 2 Session, ICANN 74]</ref>
[[Milton Mueller]] expressed concerns over a temporary solution becoming a permanent default, from which any further improvements are
made, and the absence of a billing function. There may be a very different level of demand if ICANN has to impose some costs on the people making the request. The org could bundle request subscriptions and say give us some fee, like $100, and you get 100 requests or 500 requests for the next two months or something.<ref>[https://74.schedule.icann.org/meetings/ GNSO:EPDP Phase 2 Session, ICANN 74]</ref>


==References==
==References==
Retrieved from "https://icannwiki.org/System_for_Standardized_Access/Disclosure"