Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 15 November (note new schedule of twice-weekly meetings) at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope. Recommendation 2: 1. Staff to write up the recommendation to keep the Losing FOA functionality with flexibility on terminology and format. Recommendation 3: 1. (f) Proposed edit -- Staff to provide revised draft language to change to mandatory (“MUST”). 2. (g) Proposed Edit -- Staff to revise the language in the Working Document to change to “notification of TAC issuance” and WG to review/comment. Recommendation 4: 1. (c) Proposed Edit -- Staff to revise the recommendation text to include “For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request.” 2. (d) Proposed Edit -- Staff to provide draft language for the WG to consider. 3. (e) Proposed Edit -- Staff to revise as suggested in the proposed next step but also to confirm that this and similar language is consistent. Recommendation 5: 1. (b) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. Recommendation 6: 1. (a) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. 2. (b) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. 3. (c) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. 4. (d) Proposed Edit -- Registrars to discuss. Recommendation 7: 1. WG members to review prior to next Tuesday’s meeting: See the Working Document Tool at: https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgCS.... Notes: Transfer Policy Review - Meeting #65 Proposed Agenda 10 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Reminder that we have 10 more bi-weekly meetings to the end of the year with the goal to complete our review of the public comments. * Still working on the proposal relating to the Losing FOA based on our discussion during the call on 08 November – should have that to you to consider at the next meeting. 3. Continue Discussion of Notification of TAC Provision – Recommendation 3 (see Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1SaEV9vjiSZONj...>) e) Proposed edit ICANN org understands that notifications tend to be in the form of an email, and in general emails typically are not secure methods of communication. RFC9154 in subsection 7 of section 4.3, notes "The registrar's interface for communicating the authorization information with the registrant MUST be over an authenticated and encrypted channel." Thus, ICANN org suggests the WG consider updating the language in recommendation 3.2 to note "If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC." This suggested language change complies with RFC9154. Potential next step: Strawman revision: If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC. Discussion: * A lot of registrars are doing this, but does it need to be mandatory. * Do we know if we have problems with email? Seems like a real disruption to a user’s experience. * The WG needs to decide – it’s in the RFC: sending the TAC in email is not a good security practice. That is the reason why the language is in RFC9154. * It might be an overstep to say that everyone has to change their systems because many are likely not sending via email already. * The comment in the proposed edit (e) does quote directly from RFC9154 – but the group would not necessarily have to adopt the suggested revised language. * This is someone related to the mechanism currently known as the “Losing FOA” – if you lose control of your email and the TAC the registrant has a way of denying a transfer. These security mechanisms are interrelated/interdependent. * Policy can’t solve for accounts being compromised. * The WG is not agreed that this should be a mandatory requirement. f) Proposed edit Require that the notification be sent in English in addition to the language of the registration agreement. Potential next step: WG to consider if the notification should be sent in English in addition to the language of the registration agreement. Note that the FOA is currently communicated in English. Discussion: * The purpose of the comment was because the Losing FOA is communicating in the primary language as a standard and this would make it mandatory (a “MUST”). * This is a comment from John Poole. * Seems to be an easy small change so changing to a “MUST” would make sense. ACTION ITEM: Recommendation 3, (f) Proposed edit -- Staff to provide revised draft language to change to mandatory (“MUST”). g) Proposed edit The Registries note an ambiguity between Recommendations 3 and 12 that we believe should be clarified. Recommendation 3 states that the Registrar of Record is required to notify an RNH of the provision of a TAC within 10 minutes of its request. However, Recommendation 12 states that the TAC itself must be provided within at most 5 days. The use of “provision” and “provide” are ambiguous. Perhaps Recommendation 3 is intended to notify an RNH of the “request” for a TAC as opposed to its provision? Other resolutions are possible and our suggestion does not indicate a preferred choice. Rec 3: #13 Potential next step: The wording of the recommendation appears to be causing confusion. See suggested edit under c), which attempts to make clear that the notification is sent after the TAC is provided. Discussion: * Seems to be addressed by previous/earlier recommendation (edit under (c)). See: “Implementation Note: For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the TAC request.” * Should we use a different word than “provision” in the notification? “Provision” is the technical creating and there is a small delay between “provision” and “providing”. * Could be “Notification of TAC issuance”? WG agrees at least provisionally – make the change and review. ACTION ITEM: Recommendation 3, (g) Proposed Edit -- Staff to revise the language in the Working Document to change to “notification of TAC issuance” and WG to review/comment. h) Additional Consideration Corresponding PCRT comment(s) If i paid to transfer 25 domains at one time, i think there should be only one notification for those 25 domains, but not separately as it is currently for each domain. Rec 3: #9 Potential Next Step: In recommendation 4.2 the WG has provided for optional consolidation of notifications of transfer completion, where possible. The WG previously discussed the possibility of special processes for bulk use cases, but did not come to any agreement on recommendations. Is further discussion needed about any other opportunities to consolidate notices? Discussion: * Seems to make sense, but depends on the method of “issuance”. * Think we already have language that talks about consolidation so not sure if we have to add anything. * WG agrees not to modify the language of the recommendation because there is existing language elsewhere that envisions consolidation. i) Additional Consideration We recognize that some registrars have employed security protocols which provide additional and voluntary security for registrants while not unnecessarily impeding the portability of domain names. Where appropriate, such best practices deserve consideration for inclusion in Transfer Policy itself so that they become requirements of registrars. Rec 3: #10 Potential Next Step: This comment may require additional clarification about the type of security protocols envisioned in the comment. The WG has previously discussed that account security, for example, falls outside of the picket fence. Discussion: * The WG did consider better security mechanisms. * The thinking at the time of the comment is to leave the security protocols to registrars, there is the option to provide implementation guidance to registrars so they have best practices that they can add to their baseline protocols. Even if the WG doesn’t mandate these things, they could be helpful for registrars to know them. * It may be out of scope for the policy, but worthwhile including as guidance. 4. Continue Discussion of Notification of Transfer Completion – Recommendation 4 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RDMBC4fdaltBy...>), including the question for community input on Recommendation 4 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1tQTbM2dxdmVJk...>) a) Concern Corresponding PCRT comment(s) Notice should be sent without delay (rec #3 already mentioned a 10 minute standard). Rec 4: #9 Potential next step: Is it appropriate to revisit SLA for notice? What are the pros/cons and feasibility of shortening the SLA from 24 hours to 10 minutes? Discussion: * Already addressed in Recommendation #3 10-minute standard. b) Concern Corresponding PCRT comment(s) Notices should be sent to all contacts (including the tech contact) not just the RNH. Rec 4: #9, Rec 15: #4 Potential next step: This suggestion was discussed by the WG’s review of comments on the Notification of TAC provision and similar points raised in that discussion appear to apply here. Discussion: * Already addressed in previous discussions. c) Proposed edit If the intent of the WG is to have the notification sent once the transfer has been completed, reword the recommendation to make clear that the notification of transfer is sent only once the notification is successfully completed and that the recipient is the RNH as it was reflected the Registration Data at the time of the transfer request. Potential next step: Strawman revision: Recommendation 4: The working group recommends that the Losing Registrar MUST send a “Notification of Transfer Completion” to the RNH, as listed in the Registration Data at the time of the transfer request, without undue delay but no later than 24 hours after the transfer is completed. Implementation Note: For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request. [In cases where a customer uses a Privacy/Proxy service and the contact information associated with the underlying customer is known to the Registrar of Record, the Registrar of Record may send the notification directly to the underlying customer.] Discussion: * Strawman doesn’t change the intent – it’s not optional, but need to provide rationale. * Don’t think the language needs to be stricken. * Could we take out the stricken language and instead add the first sentence of the Implementation Note to the recommendation. ACTION ITEM: Recommendation 4, (c) Proposed Edit -- Staff to revise the recommendation text to include “For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request.” d) Proposed edit Similar to input on 3.2, require additional elements to be included as part of the “Notification of Transfer Completion”, such as the timing by when the RNH is required to take action if they believe the transfer is invalid. Potential next step: WG to consider whether it is appropriate to include these additional elements. Discussion: * Seems reasonable, but need to see it in writing. ACTION ITEM: Recommendation 4, (d) Proposed Edit -- Staff to provide draft language for the WG to consider. e) Proposed edit Require that the notification be sent in English in addition to the language of the registration agreement. Potential next step: A similar comment was discussed under review of input on the Notification of TAC Request and conclusions of that discussion likely apply here as well. Discussion: * WG agrees but staff should ensure that this and all similar language is consistent. ACTION ITEM: Recommendation 4, (e) Proposed Edit -- Staff to revise as suggested in the proposed next step but also to confirm that this and similar language is consistent. Note re: Additional Considerations (f) and (g) – save for Phase 2. Potential next step: WG to consider the merits of these points to determine if the recommendation should be revised. WG discussion and agreement: As relayed from TechOps discussions at the 2022 CP Summit: * Participants in the TechOps discussions acknowledged benefits of the RO providing the Gaining Registrar’s IANA ID to the Registrar of Record via poll message. * To the extent that the Losing FOA is retained, the Gaining Registrar’s IANA ID can be included in the Losing FOA, as well as in the Notification of Transfer Completion: * Gaining Rr submits TAC to RO. * RO verifies validity of request/TAC. * RO sets pending status. * RO sends poll message to Losing Rr, to include Gaining Rr’s IANA ID. Discussion: * WG agrees, but registries should consider and provide input – confirm on the next call. * Registries did provide the following comment: “Registry Operators acknowledge the security benefit of notifying a RNH both of a completed transfer and of the identity of the Gaining Registrar. This notification provides a confirmation to the RNH that the desired action was completed as requested. Further, Registry Operators understand that in order to achieve this it will be incumbent of Registry Operators to provide this information to the Losing Registrar via EPP upon completion of the transfer as the Losing Registrar would not otherwise have access to this information.” 5. Begin Discussion on Recommendation 5 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ssvbicQ7pkZiB...>) and Recommendation 6 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wr84v8XbEfe0n...>) Recommendation 5: a) Concern Corresponding PCRT comment(s) The TAC is a high-value target that should be eliminated. It should be replaced with the PTID. Rec 5: #5 Potential next step: See deliberations on this proposal under discussion of Recommendation 1. WG discussion and agreement: b) Proposed edit Corresponding PCRT comment(s) ICANN org acknowledges that this update should be made across all platforms including ICANN.org webpages, and suggests the WG consider including an implementation note that clarifies that updates include publications and webpages in accordance with the suggested terminology change. Rec 5: #3 Potential next step: WG to consider if there is any downside to adding an Implementation Note, and if not, add suggested language. Strawman revision: Implementation Note: ICANN publications and webpages should also be updated to reflect the recommended terminology change. WG discussion and agreement: Discussion: * WG agrees with the proposed strawman revision. ACTION ITEM: Recommendation 5, (b) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. Recommendation 6: a) Concern ICANN org acknowledges the concerns raised by the WG that adding language that the RNH’s authority supersedes that of the representative may conflict with agreements between the RNH and a third-party to which the RNH has given authority. Yet, ICANN org would like to point out that it is not uncommon for resellers or web-developers (example of these third-parties) to include general clauses in their agreements granting blanket authority to the reseller or web-developer to manage the domain name (which may be used by the third party to attempt to hinder or process an inter-registrar transfer where there is a dispute). Org would also like to note that “in the event of dispute” it is not within ICANN’s remit to determine how and to which extent an agreement a RNH may enter with a third party may suffice to diminish the protection and authority the Transfer Policy intends to afford to RNHs. Org’s recommendation is consistent with the current Transfer Policy which indicates that the RNH and the Administrative Contact “are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the Registered Name Holder's authority supersedes that of the Administrative Contact. “ This is regardless of whether or not the RNH and the Administrative Contact may have a separate agreement. Potential next step: WG to consider whether, in light of the above points, the recommendations should include the suggested language that the RNH’s authority supersedes that of the representative in the event of a dispute. Discussion: * The WG agrees with the suggested potential next step. ACTION ITEM: Recommendation 6, (a) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. b) Concern The TAC is a high-value target that should be eliminated. It should be replaced with the PTID. Conceivably the TAC can be generated by the registry, not just the registrar. Generation of the TAC on request (as opposed to always existing, like the current AuthInfo code) is a slight improvement, it is overstated as a huge improvement, because the existence of a domain name transfer lock blocks the persistent (always existing) AuthInfo code. Potential next step: See also deliberations on this proposal under discussion of Recommendation 1. Discussion: * WG agrees with the suggested potential next step. ACTION ITEM: Recommendation 6, (b) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. c) Proposed edit The WG may want to consider including the term “to request” in addition to obtaining the TAC. Specifically, an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf. This is to avert instances where a representative may obtain the TAC that the RNH never intended to request for a transfer the RNH never wanted. Potential next step: Strawman revision: “ "Designated representative" means an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf.” Discussion: * This makes it clear that the “Designated representative” is authorized to request the TAC. * WG agrees with the suggested potential next step. ACTION ITEM: Recommendation 6, (c) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. d) Proposed edit Org would also like to note that based on our experience in implementing other recommendations, it is a good idea to have important definitions embedded in the policy recommendations themselves (as opposed to in a footnote) as it will allow ICANN Compliance the ability to easily enforce the requirements when included and clearly described within the text of the policy language. Potential next step: Make the definition of the designated representative a standalone recommendation: Recommendation xx: "Designated representative" means an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf. Discussion: * Suggestion is to make this a recommendation as opposed to just a footnote. * Concern is that we haven’t fully defined what “Designated representative” means. Has it been defined in other ICANN policies? * Staff notes that “Designated Agent” is defined elsewhere, but not “Designated Representative”. This is different from the “Designated Agent”. * From the Transfer Policy: "Designated Agent" means an individual or entity that the Prior Registrant or New Registrant explicitly authorizes to approve a Change of Registrant on its behalf. * We are acknowledging that in some cases “Designated Representatives” exist and they can obtain the TAC. ACTION ITEM: Recommendation 6, (d) Proposed Edit -- Registrars to discuss. Recommendation 7: ACTION ITEM: Recommendation 7 -- WG members to review prior to next Tuesday’s meeting: See the Working Document Tool at https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgCS.... 6. AOB