Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 14 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items Revisit TAC recommendations (60 minutes) – see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...> (beginning on p. 15) Recommendation 1: Revise text to (new text in brackets): “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”[ and related terms].” Recommendation 2: Revise the wording (new text in brackets) to ““A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the registrant or [their designated representative.] Change “registrant” to “Registered Name Holder” throughout. Recommendation 3: WG members to suggest alternate/revised language. Recommendation 4: Change “created” to “stored”. Recommendation 5: WG to review revised text as suggested: “The Working Group recommends that the Registry notify the Registrar of Record after the Gaining Registrar has made [3-5] failed attempts to present a valid TAC to the Registry for a domain name, and for each successive failed attempt as long as a TAC is present. The Registrar of Record must notify the registrant that the failed attempts have taken place, and may take additional action, for example resetting the TAC.” Recommendations 6-11: WG to review and comment. Transfer Policy Review Phase 1 - Meeting #27 Tuesday 07 December 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates (5 minutes) * Owen Smigelski: Questions about registrar type in the survey. Provided responses grouped by type and size. See attached. There are several types and we had responses to the survey from several different types and sizes. Could not correlate between type and size. Did seems to be more support for having locks than not, but could not correlate that response by type or size. 3. Rationale for elimination of the Gaining FOA (15 minutes) – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdi...> (beginning on p. 16) * Have not seen comments on the final revisions. We will read it out to see if there are more comments. We will come back to it so we aren’t done yet. * In October the WG agreed that we would draft a summary of the discussion on the elimination of the Gaining FOA. * We provided some of the background for context. Discussion: * Question: Why do we say this? “The Working Group believes that the notifications detailed in recommendations [xxx-xxx] ensure that the Registered Name Holder receives the necessary information when a key change has been made to their account.” This is no longer true based on current discussion. Answer: We have updated the text to reflect the recent discussion in the Losing FOA document and we’ll update the language here to be consistent. 4. Revisit TAC recommendations (60 minutes) – see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...> (beginning on p. 15) * We updated this to no longer be candidate recommendations since we’ve reviewed it several times – now these are draft recommendations. * Not every charter question ended up with a recommendation. Charter Question b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? Recommendations 1-5: Recommendation 1: * Big change was to eliminate the confusion over terminology. * As an editorial comment – in place of the currently used term also add “and related terms” to be more inclusive. Don’t want to lose the opportunity to cover everything appropriate. ACTION ITEM: Revise text to (new text in brackets): “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”[ and related terms].” Recommendation 2: * Are we consistent in terminology throughout when referencing the registrant? Should we be using Registered Name Holder? * Registrant and admin are the only ones authorized. * Registrant is not necessarily the account holder. Good to show the ultimate decision maker as the registrant. * Suggest change to “registrant or [their] designated representative” – new text in brackets. Need to be mindful of how this policy will work with the transfer dispute policy. * Some registrars use a designated agent for a transfer, so “designated representative” is still accurate. * The Definition should not exclude other security mechanisms. * Avoid using the administrative contact language since that is going away. * Question: To be precise, the admin contact in RDDS is going away, but is it conceivable that via the account panel that the RNH will assign a non-RDDS admin contact? How does a RNH go about designating that person? Answer: Could be that their provider that allows a log in for the account that provides access to certain things – they could give that info to a representative, but we shouldn’t get too specific here. * The sole Point is to reach the registrant, so we do not need to define the various opportunities. So, “send to the registrant” is sufficient. * Change “registrant” to Registered Name Holder” throughout? ACTION ITEM: Revise the wording (new text in brackets) to ““A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the registrant or [their designated representative.] Change “registrant” to “Registered Name Holder” throughout. Recommendation 3: * Question re: “ICANN org may change these requirements from time to time in response to new or updated standards, but any changes to the requirements must go in effect with sufficient [notification and] time for registrarsregistries to implement the necessary updates.” Is it normal for ICANN Org to establish this type of requirement? * If this were a protocol issue those statements would be done in the IETF. This is a security requirement. IETF is a source we can go to for this. Could be a statement that it “should be based on applicable security standards” and add a reference. * The key here is that ICANN would be initiating it – should other parties be able to initiate? * In the last sentence, change “registrars and registries” to “contracted parties”. * See IETF language at: https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/ ACTION ITEM: WG members to suggest alternate/revised language. Recommendation 4: * Suggest it should say “stored” or “set” rather than “created”. ACTION ITEM: Change “created” to “stored”. Recommendation 5: * May need to look at this recommendation again for bulk transfers. * Question: Are we failing to set a new TAC, or providing the wrong TAC? Answer: We need to revise the language to make it clearer. * Question: If we are setting the number of failed attempts as a trigger, can ICANN Org change it later? Or is that a policy change? * Question: Should we set a period of time? * If you want to detect brute-force attempts then we should make that clear. Brute force was one example, could also just be a system error. * Could change to: “The Working Group recommends that, if the Gaining Registrar presents an invalid TAC [$number] times, or [$number within $period] times, the Registry MUST notify the Registrar of Record of the invalid attempts.” * Comment: from a security perspective – from the principle of wanting to provide protection to the registrant in this case there may be a malefactor involved so we are trying to provide an extra layer of protection. If everything is working as it should then the only risk here is that the value has been mis-entered. We should put a number here; a small number of attempts. Something to think about is the transfer should not be allowed if you have entered X number of failed attempts. Maybe the registry disables the transfer and make them go to get another TAC. * One thing to keep in mind, in order for this system to work if the registry is going to be telling you something it should be required – “MUST” not “MAY”. As a security mechanism using “MUST” makes more sense. * Number of failed attempts could be between 3-5. * Recalling earlier discussions: there were originally two formations of this recommendation. It sounded like the recommendation to cancel the transfer was not selected because it would be a way to derail a transfer. * If after the failed attempts (3 or 5), a notification to the registrant is sufficient. I think changing it automatically isn’t a good idea, as it’s done its job. * Clarify that this is per domain (issue of bulk transfers). * From a security perspective if you aren’t going to disable the transfer then you could force a reset; if you don’t want to do that you should say that the registry after X number of attempts an any attempt that failed you MUST send a notification. * A notification is sufficient of the failed attempts. * Suggest, “registrar of record MUST notify the registrant and MAY take further action such as resetting the TAC.” If we do say the registrar MUST notify we should decide if we need to provide a template for that communication. * What is the process for changing the number of failed attempts? If we put a number here do we need policy to change it? Maybe suggest a number to the IRT that they can update. ACTION ITEM: WG to review revised text as suggested: “The Working Group recommends that the Registry notify the Registrar of Record after the Gaining Registrar has made [3-5] failed attempts to present a valid TAC to the Registry for a domain name, and for each successive failed attempt as long as a TAC is present. The Registrar of Record must notify the registrant that the failed attempts have taken place, and may take additional action, for example resetting the TAC.” 5. AOB (5 minutes) * Next call: Tuesday 14 December 2021 at 16:00 UTC