- TSG-Access-RD - lists.icann.org

Fwd: Technical Model for Access to Non-Public Registration Data
by Benedict Addis May 21, 2019

May 21, 2019

Feedback on the TSG report from Joe St Sauver of Farsight. He’d like me to make clear that the opinions below are his own. Benedict. > Begin forwarded message: > > From: Joe St Sauver > Subject: Re: Technical Model for Access to Non-Public Registration Data > Date: 4 May 2019 at 04:05:02 BST > > Hi, > > Carlos wrote: > > For those interested on how non-public registration data (aka WHOIS) > > will be technically accessed in the future: > > > > https://www.icann.org/news/blog/technical-study-group-publishes-tsg01-techn… > > Thanks for passing this along. After a first reading, some quick highlights from the new document [my personal comments below are in square brackets]: > > > -- Goal/purpose (See Executive Summary on page 6): > > "The TSG's work is not an effort to replace the ICANN community's > policy development process. Rather, the work of the Group is > intended to help ICANN org determine whether such a model would > diminish the legal liability for gTLD Contracted Parties (CPs), who > would provide access to non-public gTLD domain name registration > data." > > [framing the question in terms of "risk minimization for contracted > parties," rather than in terms of facilitating public access for the > historical Whois users (such as the anti-cyber-crime community) > predictably skews the mission and output of this working group] > > > -- The Solution WILL Be RDAP based (also from the Executive Summary): > > "Building on the technology available via the Registration Data > Access Protocol (RDAP) and its extensions, the TSG recommends a > technical model for authenticating, authorizing, and providing > access to non-public gTLD domain name registration data to third > parties with legitimate interests based on existing technologies." > > [not surprising, by taking RDAP as a "given," this predetermines a > number of other outcomes, as highlighted below; I'd also note > that RDAP deployment is still very limited per > https://data.iana.org/rdap/dns.json ] > > > -- Punting On Some Key Questions (Section 1 ("Background") on 7): > > "The TSG [Technical Study Group on Access to Non-Public Registration > Data], by design, has not made decisions or recommendations on > purely policy questions, e.g., which users get access, to which data > fields and under what conditions should access be given, and what is > a legitimate interest for requesting such data." > > [failing to consider these key issues ignores the extent to which > these issues potentially drive a successful technical solution, > e.g., imagine a scenario where some users get access to "full" data > while others are only eligible for a subset of that data -- how > those entitlements get communicated represents a key part of the > technical design. Nonetheless, noted as "punt to policy"] > > > -- Identity Management Choice (see Section 6.1 ("Functional > Requirements Mapping and Analysis") on page 16): > > "The TSG considered two technologies as candidates for inclusion in > its Technical Model proposal. The first candidate is authentication > and authorization using OpenID Connect and OAuth 2.0. [...] The > second candidate is mutual Transport Layer Security (TLS) > authentication using a digital certificate issued to the end user > by a Certification Authority (CA). [...] The TSG believes that > OpenID Connect/OAuth authentication meets all of the identified > functional requirements." > > [I'm very supportive of federated authentication, but I'd note that > federated auth doesn't necessarily foreclose cert based solutions > at the same time -- the "CILogon" model is a compelling example > of how the two can be bridged, see https://www.cilogon.org/ ] > > > -- Section 7 ("Out of Scope Requirements") on page 17: > > > "The TSG identified several functional requirements that it decided > were out of scope. These requirements are listed below, and the > rationale for placing them out of scope is outlined. > > > "7.1. Reverse Search > > "In the context of domain name registration data, “reverse search” > refers to the ability to identify domains based on common attributes > such as a nameserver IP address or registrant email address. This is > in contrast to the traditional model of accessing registration data > by means of a direct lookup of a resource by an already-known > identifier (e.g., a domain name). A reverse search query may be sent > to a specific CP’s RDAP server, but may also be sent to an RDAP > gateway service, which “fans out” the same query to multiple CPs’ > RDAP servers, and aggregates the responses into a single result. > > While RDAP already supports limited search capabilities, and an > Internet-Draft extending these capabilities exists, the TSG does not > believe that consideration of a reverse search system - and > especially a cross-TLD reverse search system - is within its remit. > The technical feasibility of such a system (in which a single client > query could result in thousands of search queries to CPs’ RDAP > servers), and the policy developments required to allow such a > system to exist, are too great for it to be considered at this point > in time. > > Should reverse search become feasible (from a technical and/or > policy perspective) in the future, the TSG believes that the > solution proposed in this document provides a platform in which it > could be implemented." > > [this dismissive treatment of an important capability is reflective > of a significant disconnect between how the ICANN TSG views > information about domains vs how LEOs and other cyber crime fighters > use that information; the legitimacy of "needs" are being determined > by the current state of RDAP; also note another "punt to policy"] > > > "7.2. Pseudonymity of Registrants > > As an alternative to reverse search, some have proposed that CPs add > pseudonymous, hash-based identifiers to RDDS records, which would > allow third parties to correlate domains with common registrants, > without disclosing the personal information from which the > identifiers are derived. > > The TSG believes that this proposal is out of scope, since it > proposes a change to the basic data elements collected and processed > by CPs: such a proposal is best addressed in the policy domain > first, with a technical implementation to follow afterwards. > > As with reverse search, the TSG believes that registrant > pseudonymity could be supported by the Technical Model in the future. > > [the hash-based approach that was proposed does not require any > "additional data elements to be collected", it merely proposes a > transform on how those elements are processed and shared; "punt to > policy" yet again] > > > "7.3. Bulk Queries and Bulk Access > > The TSG defines “bulk queries” and “bulk access” as follows: > > ● “Bulk queries” is defined as a single transaction, containing > multiple discrete queries, which produces multiple responses. > > ● “Bulk access” is defined as requestors gaining access to entire > datasets in an encapsulated format such as a CSV, XML or > relational database file. > > The TSG believes that neither feature is within scope since neither > feature is currently possible within RDAP." > > [it is a shame that the current state of RDAP is again being used > as the justification for dismissing valid requirements, rather than > serving to highlight required protocol development work] > > > -- Who's Going To Handle Identity Management and Authorization? > (8. "Actor Models" on pages 18-20): > > "The TSG takes no position on which of these models is ideal for > selection to be deployed but is merely presenting possible > combinations of actors and responsibilities that meet the stated > requirements." > > [nonetheless, if you read the four models, Model 2 is clearly the > most favorably characterized "child" from this "family" of models. > It reads: > > "Actor Model 2: ICANN Gateway Using Multiple Identity Providers > with ICANN as Sole Authorizer > > "In this model, ICANN delegates identity management to third-party > Identity Providers, including for example national or regional law > enforcement bodies and civil legal organizations, where vetting and > credentialing of requestors may be already in-use, and natural. > By keeping ICANN as the sole Authorizer, this model lowers the > number of interactions, at least in regards to the authorization > steps. Similar to model one, it does not suffer from potential > inconsistencies in implementing the authorization policy."] > > > -- A Rather Dismissive Note I'm Surprised To See Included (Section 9, > "Implementation Considerations", page 20) > > "Given the nature of a system of this type, there will be > complexity. Therefore, burdensome complexity should be pushed, when > possible, to the fewest and most capable actors. > > "The largest contingent of actors in this system will be the > requestors, for example law enforcement agents. Any proposed > solution should attempt to keep burdensome, complex and technical > matters from impacting their primary duties." > > [This sure SOUNDS like, "Don't you worry 'bout all this complex > technical stuff, we'll take care of those burdensome details for > you non-techy LEOs" -- sheesh. Really?] > > > -- And The Answer Is... (Section 10.1 "System Components" at page 21): > > "10.1 System Components > > "This document proposes two parallel systems for processing requests > for non-public gTLD domain name registration data: a browser-based > Web portal, which allows asynchronous, manual submission, review, > authorization and (optionally) completion of requests for non-public > registration data through an ICANN browser-based RDAP client, and an > RDAP Gateway, which allows synchronous, automated machine-to- > machine requests for non-public registration data. Either or both of > these systems may be deployed, according to policy development > outcomes." > > [sounds like another non-decision, punted to "policy" (again)] > > > -- SLAs are "Critical" But... (Section 11.2 "Service Level Agreements" > on page 26): > > "In order to ensure a reliable system, Service Level Agreements > (SLAs) MUST be established for each of the parties that operate the > elements of the system. These SLAs would define the service > performance levels expected of each party and the penalties for > failing to meet them. [...] The TSG believes that defining the > service level performance requirements for each party and the manner > in which they are established, audited, and enforced, as well as > whether SLA performance should be reported publicly is outside the > scope of its remit and should be determined at the policy level." > > [punted to policy (again)] > > > -- Risks (Sections 11.4 (Risk to ICANN Org) and 11.5 (Risk to > Contracted Parties) on page 27): > > > "11.4 Risk to ICANN Org > > "The TSG notes that ICANN org will function as the coordinating > party of the system in the gTLD space and, depending on the policy > development outcome, may result in ICANN org shouldering the burden > of vetting and credentialing requestors. This may expose ICANN org > to significant operational and legal risks. It is recommended that > ICANN org identify, assess, and where possible take steps to > mitigate these risks." > > [wait, wasn't this study supposed to be all about risk assessment?] > > > > "11.5 Risks to Contracted Parties > > "The TSG was established to determine the feasibility of a system > that would mitigate some or all of the legal risks to CPs from the > disclosure of non-public registration data. The TSG cannot comment > on the validity of this assumption, and expects that the CPs will > come to their own determination based on their own legal advice." > > [wasn't this the precise charge to the group?] > > > -- "More Work is Required" (Section 12.1 (Future Work) on page 30): > > "The TSG’s Technical Model (TSG01) should be considered a proposal. > The Technical Model (TSG01) should be considered the start of some > work, rather than the end and is not sufficient to be directly > applicable for implementation. Future technical work is necessary to > complete the technical and specification process. [continues]" > > [it seems like much is pending policy development/policy decisions, > rather than technical considerations] > > I encourage all to read the entire document. > > Regards, > > Joe

3 2

Discussion of TSG01 at CENTR Jamboree, Amsterdam, 27 - 29 May 2019
by Gavin Brown May 10, 2019

May 10, 2019

Dear colleagues, Jaromir Talir of CZ.NIC approached me here in Bangkok regarding the above event. He is chairing a session titled "Using eID by domain registries" and feels that the TSG01 report is relevant to the session topic, and wondered if any TSG members could participate. Unfortunately I am unavailable, so I am passing on the invitation to the group to see if anyone else might be. Jaromir is CC'd on this email so if you are able to participate in the session you can reach out to him directly. More information at: https://www.centr.org/events/upcoming-events/centr-jamboree-2019.html Regards, -- Gavin Brown Chief Innovation Officer CentralNic Group plc (LSE:CNIC) https://www.centralnicgroup.com/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

1 0

Blog & Final Model Published
by Diana Middleton May 3, 2019

May 3, 2019

Dear TSG, Ram’s final blog has been published here<https://www.icann.org/news/blog/technical-study-group-publishes-tsg01-techn…>. We will continue to keep this list open and the team drive accessible for the time being. Please let us know if you have any questions. Best, Diana

4 3

Consensus policies definition
by Eleeza Agopian April 26, 2019

April 26, 2019

Dear team, As promised, I’m following up on a revised definition for consensus policies. The below is derived from language in the Registry Agreement (Specification 1, 1.1) and the Registrar Accreditation Agreement (Consensus Policies and Temporary Policies Specification, 1.1): Consensus Policies are those policies established (1) pursuant to the procedure set forth in ICANN's Bylaws and due process, and (2) covering those topics listed in (i) Section 1.2 of the Consensus and Temporary Policies Specifications of the Registrar Accreditation Agreement and the Registry Agreements that are modeled after the Base Registry Agreement and (ii) comparable provisions in Registry Agreements that are not modeled after the Base Registry Agreement. Please let me know of any objections. If none, will add to Section 2.1 of the model document. Thank you, Eleeza

3 2

Notes from TSG-Access-RD Meeting #15 - 23 Apr 2019
by Diana Middleton April 23, 2019

April 23, 2019

Dear all, See below for notes from meeting #15. Please let me know if you have any questions or concerns. Best, Diana ************************** Technical Study Group on Access to Non-Public Registration Data Meeting #15 23 April 2019 0900 PST / 1200 EST / 1700 UTC Attendees: Ram Mohan, Steve Crocker, Gavin Brown, Scott Hollenbeck, Jorge Cano, Jody Kolker, Benedict Addis, Diana Middleton, Eleeza Agopian, Gustavo Lozano, John Crain, Yvette Guigneaux Apologies: Tomofumi Okubo, Murray Kucherawy, Andy Newton, Francisco Arias, During this call we discussed the following: * Group reviewed document, resolved outstanding comments * Group reviewed TSG response to comments * Group reviewed updated swim lane graphic * Group discussed naming of document * Group discussed possible late comments received from CPH * Group discussed next steps after group closes We have the following action items: * Diana/Eleeza to check with Communications team about hyperlinks properly referenced when non-electronic version is used * Diana/Eleeza to check on official definition of Consensus Policy with Legal * Diana to add Wikipedia definition of non-caching reverse proxy, with appropriate reference to Wikipedia * Scott to add formal reference for RFC mentions DONE * Gustavo to add reference to PDP process * Diana/Eleeza to add reference to bylaws * Diana/Eleeza to ensure proper name of document consistent throughout (TSG01) DONE * Diana to add links to TSG member’s employers DONE * Diana/Eleeza to ensure “ICANN RDAP Gateway” is the consistent use across document * Ram to pen paragraph of naming adoption, group to review * Benedict, Gavin, Scott, & Jody to review any comments that come from the CPH * ICANN org staff to collect/collate any future comments received and decide if TSG needs to be reactivated for response * Group to formally disband after 30 June 2019, unless otherwise requested by Göran * Eleeza to check if Göran will pen final blog on TSG

1 0

sending my regrets for today
by Andrew Newton April 23, 2019

April 23, 2019

All, I will not be able to make the call today. Enjoy the last telecon. -andy

1 0

TSG response to community comments
by Eleeza Agopian April 23, 2019

April 23, 2019

Dear all, As promised during your face-to-face, I have compiled the team’s responses to community comments that were received in advance of this week’s meeting. Please review to confirm that I have accurately captured your responses. The document can be found on your team drive: https://docs.google.com/document/d/18bD9OQ19JRM8WtXWUedUPLDZvTq24RmloGIQ3Pi… Thank you, Eleeza

4 3

Notes: April F2F, Meetings #12 & #13
by Diana Middleton April 22, 2019

April 22, 2019

Dear all, Please see attached for notes from the following meetings: April’s Face-to-Face sessions Meeting #12 dated 2 April 2019 Meeting #13 dated 4 April 2019 Best, Diana

1 0

Naming our final report
by Ram Mohan April 19, 2019

April 19, 2019

Folks, Yesterday I was suggesting naming our final document something with a date. On further thought, and considering that there _*may*_ be instances where this document is referred to, I wonder if we are better off with a numbered doc instead. Of course, this means that a future TSG output would be expected to go to TSG002, etc. Something like: *TSG001, Technical Model for Access to Non-Public Registration**, published April 23, 2019* Any thoughts/objections/concerns? -Ram

5 9

FW: [Ext] InfoNetworks' TSG Comments
by Eleeza Agopian April 15, 2019

April 15, 2019

Dear all, You have received the attached comment from InfoNetworks. Thank you, Eleeza From: "mpalage(a)infonetworks.global" <mpalage(a)infonetworks.global> Date: Monday, April 15, 2019 at 2:57 AM To: "gdpr(a)icann.org" <gdpr(a)icann.org> Subject: [Ext] InfoNetworks' TSG Comments Dear ICANN org, Attached please find InfoNetworks comments in connection with the current work of the TSG regarding UAM. Should you have any questions please do not hesitate to contact us. Best regards, Michael Palage

1 0