Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be Tuesday, 12 October at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. Working Group Members to review the table on p. 14 of the Gaining FOA working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e2...>, which sets out the purposes/functions of the pre-GDPR Gaining FOA. The purposes/functions are listed in an effort to ensure that if the Gaining FOA is ultimately eliminated, any important purpose/function is covered elsewhere or in an updated step of the transfer process by Monday, 11 October. 2. TPR Support Staff to review the transcript from today's call and document the rationales described for why the Gaining FOA may be technically feasible, but it is NOT commercially feasible or legally authorized under the current data protection landscape. 3. Working Group Members to review the TAC Candidate Recommendations, beginning on p. 17 of the Auth-Info Code working document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A...>, and provide comments, concerns, and proposed edits, etc., by Monday, 11 October. Transfer Policy Review Phase 1 - Meeting #20 Tuesday 5 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) * Tucows has recently purchased the registry platform of another company. Sarah will continue to represent the RrSG but wanted to note this. * Thomas Keller has left the RrSG, and accordingly, has left the WG. 2. Welcome & Chair updates (5 minutes) 3. Upcoming meeting schedule and ICANN72 (5 minutes) * TPR session will be Tuesday, 26 October at 10:30-12:00 UTC. This will function as a normal WG meeting. * The Tuesday, 2 November meeting immediately following ICANN72 will be cancelled. 4. Gaining FOA (40 minutes) · Gaining FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdi...> · In reviewing the Gaining FOA, support staff has outlined the functions of the Gaining FOA to see if the functions and security measures are covered. * 1. Provides a verification step that is distinct from any processes with the Losing Registrar. * The Gaining and Losing FOA were methods of how to transfer the domain name. These were not really a verification step. With the verification of the TAC, this would be covered. * If the Gaining FOA is removed and the team is relying on stronger security features, wonder if now is a good time to discuss what some of those additional security features may be. For example, when thinking about the entire transfer process, is it worth giving initial indications about what additional security measures could be explored in the context of the Gaining FOA being removed. With respect to Charter question a3, the Temp Spec references other secure methods – is this something that should be explored here? * The team already put in details regarding the TAC – does anyone believe this requires more discussion? * The process the WG is going through is trying to capture the deliberation and rationale that is being proposed by the WG. Part of that process is trying to consider other possible aspects. For example, Charter question a3 – until such time as the RDAP service or other secure method…the Temp Spec is pointing to RDAP and/or some secure method for transferring the data. For now, set aside the questions of lawfulness – the group needs to provide appropriate rationale for why the Gaining FOA is no longer required. As a practical matter, pre-GDPR, the Gaining Registrar got information automated via Port43, and registrars whitelisted each other to facilitate this. Could it be conceivable that now that RDAP is partially initiated that in two years – could a whitelist function be implemented that would allow registrars to still obtain the email address of an registered name holder? Or if not as simple as whitelisting, is there some sort of authentication mechanism that could be considered? This is the kind of deliberation that needs to happen here to provide the rationale for why the Gaining FOA could be removed. * The technical answer is yes – there are many ways to facilitate this; however, we must consider data protection law. * There will not be a legal basis for this transfer – the Gaining FOA is not needed. This is also probably not commercially feasible. * This could end up being very confusing for the registrant. In some jurisdictions, this is not possible, and transfers would be handled differently from registrar to registrar – this is not ideal. * Could the SSAD, if it were to be approved, be a way for registrars to gain access to the registered name holder’s data? UDRP providers are envisioned to use SSAD to verify the respondent in a UDRP complaint; similarly, could gaining registrars use SSAD to verify the identity of the registered name holder for purposes of a transfer? * Prior to GDPR, there was a system called RADAR that registrars could use. The problem would be the level of effort where you are potentially losing a paying customer could be cost-prohibitive. This does not overcome the risk of the transfer of personal information under GDPR. * Worthy to note that yes, there may be technical solutions. Is legal advice necessary to make a determination about the lawfulness of the processing of data? One member noted that there is not a lawful basis to process this data. This warrants an action by this group to document the lawfulness or lack thereof of processing this data. This is important to document for the purpose of public comment and the board. The response that this is not lawful will not be adequate. In today’s world, there is still a balancing for disclosure to UDRP providers. Recommend the group is very technically and legally precise and makes this understandable for those outside of this group. * Support Staff to pull out the relevant portions of this conversation to document rationales discussed * It is not that the gaining FOA is not obtaining the PII. It used to be that the public WHOIS was used to send the FOA to the domain owner. The Team has to ground this transfer in necessity. Unlike the UDRP, where the data is necessary, the transfer process has functioned properly without the Gaining FOA for years without instances of increased domain name theft. * ICANN community seems to be very easy going on the data that is collected and processed. The data registrars have, in general, is high level data, and it poses a huge security risk. * Transfers used to be just FOAs and then auth-info codes were added to make it more secure. Auth-info codes obviated the need for Gaining FOAs, and the last three years have additionally proven this point. * Gaining FOA also provides notice that registrant will need to enter into Registration Agreement with new Registrar * The registrant will need to enter into a registration agreement, but the Gaining FOA is not the first interaction between the gaining registrar and the registrant. The terms of service and registration agreement should happen before the Gaining FOA step. * Confirm the transfer in a 5-day window – have to actively knowledge the transfer – this may be a security feature that is not covered in future-state. * Loosely provides instructions about how to stop the transfer. * This chart is helpful – the 5-day window is already covered (item 2) and provides instructions about to stop the transfer is already covered in item 5. * Encourage members to continue adding reasons to the right side of the column so that the rationale is clearly documented. * 2. Transfer may proceed only when RNH has responded to this notification, therefore the notification is always well in advance of the transfer taking place. * 3. Gaining Rr obtains PII from Losing Rr and uses it to send Gaining FOA. * 4. Express authorization by RNH is needed for transfer to proceed. * 5. If the RNH takes no action in response to the Gaining FOA, transfer does not proceed. * 6. The Gaining FOA provides documentation that RNH has authorized the transfer. 1. Review of draft responses to charter questions and candidate recommendations for AuthInfo Codes (30 minutes) · AuthInfo Codes working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...> · Based on the Team’s previous discussions, Support Staff drafted responses to the charter questions and accompanying candidate recommendations for the WG to review. · Note: these are not draft recommendations at this stage. · Candidate Recommendation 1: The Working Group recommends that the Transfer Policy and all related policies use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code.” This recommendation is for an update to terminology only and does not imply any other changes to the substance of the policies. · Candidate Recommendation 2: The Working Group recommends that the Transfer Authorization Code be defined as follows: “A Transfer Authorization Code (TAC) is a code created by a Registrar of Record to validate that a request to transfer domain name in a generic top-level domain (gTLD) is submitted by the authorized person. A TAC is required for a Registered Name Holder to transfer a domain name from one Registrar to another.” * It is reasonable in some situations where someone other than the domain owner would have the TAC. Not sure this should be limited to authorized person. WG considered that having the TAC makes someone an authorized person. · Candidate Recommendation 3: The Working Group recommends that the Transfer Policy require that the TAC must be a minimum of [16 characters] [32 characters] in length or any alternative minimum length prescribed by ICANN from time to time. * There were two suggestions for length, so both options are included in brackets. · Candidate Recommendation 4: The Working Group recommends that the Transfer Policy require that the TAC include at a minimum of one uppercase letter, one lowercase letter, one number, and one special character. * ICANN internal colleagues noted that entropy is important – for example, 128 bits of entropy. * Instead of specifying, perhaps reference a security standard like NIST. * The problem with specifying a current standard is what happens when the standard changes – how long do registrars have to implement the new standard? * Could consider adding – or different length as prescribed by ICANN * Could the policy recommendation be for ICANN to set the specific standard as prescribed by NIST – in other words, the policy itself would be specific, but the policy recommendation would not be specific to allow for flexibility. · Candidate Recommendation 5: The Working Group recommends that the registry verify that the TAC meets the requirements specified in Recommendations 3 and 4. * When should this verification take place? If anyone has comments, please populate in the document. · Candidate Recommendation 6: [The Working Group recommends that the Registrar of Record [and registrant] receive a notification after [number] failed attempts to enter the TAC. ICANN Org may change from time to time the number of failed attempts that trigger a notification.] OR [The Working Group recommends that after [number] failed attempts to enter the TAC, it is not possible to attempt a transfer for [period of time]. ICANN Org may change from time to time the number of failed attempts that trigger this result.]. 5. AOB (5 minutes) · Next meeting: 12 October 2021 @ 16.00 UTC