icannwiki

System for Standardized Access/Disclosure

Revision as of 14:27, 27 December 2021 by Jessica (talk | contribs)

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.

History edit

  1. Era of Whois
  2. GDPR goes into effect (2018)
  3. The GNSO engages in an EPDP on the Temporary Specification for gTLD Registration Data
    • 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
  4. 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
  5. 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 (2021)
  6. ODP results in an Operational Design Assessment (ODA)

EPDP Phase 2 Final Report & Recommendations edit

Phase 2 of the 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.[1] 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.[2] 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 edit

From ICANN Org edit

Operational Design Phase edit

ICANN Organization gave an update on the SSAD's key components in November 2021.[3]

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
Data subjects
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

References edit

  1. ↑ EPDP Temp Spec Workspace - Phase 2 Final Report, July 31, 2020.
  2. ↑ ICANN.org Blog - EPDP Phase 2 Team Publishes Final Report, August 10, 2020
  3. ↑ SSAD ODP Update Presentation, Nov 2021, ICANN

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Retrieved from "https://icannwiki.org/index.php?title=System_for_Standardized_Access/Disclosure&oldid=1341533"