Dear TPR WG members,

Please find below the notes and action items from today’s meeting.

The next meeting will be on Tuesday 25 October at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

1. ACTION ITEM: Staff to create a diagram comparing the timeline of the existing Losing FOA with the proposed notification of TAC request discussed during the meeting on 18 October.
2. ACTION ITEM: 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.

Notes:

Transfer Policy Review - Meeting #62

Proposed Agenda

18 October 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Doodle poll to pick another weekly time slot: choice was 16:00 UTC on Thursdays.  We will start on 10 November.
• Good conversation from last meeting.  Seemed to be agreement that we need an explicit window to NACK. Proposal to make a mandatory notification of transfer requests at the time of request that goes to the registrant on record.  Didn’t yet agree on a time window – need to get ideas on that.  Moves us from recommendations 1 to recommendations 2 and 3.

3. Continue Discussion of Comments on Elimination of the Losing FOA – Recommendations 2 (see Public Comment Review Tool and Working Document [docs.google.com])

Look at the working document bottom of page 3:

Proposal: Make a notification of TAC (transfer) request mandatory. The registrant has the option to accept or reject the release of the TAC. If there is no response by x period of time (a period of less than 5 days), the Registrar may proceed to issue the TAC.

Discussion:

• If this were an email notice that might fit a NACK-like behavior.
• Good point.  It is something beyond the registrar’s portal – outside of that.  We have avoided stipulating the method of communication.  It just has to be separate, so a multi-factor concept.
• Regarding format of notifications from the Initial Report: The working group recognizes that this notification MAY be sent via email, SMS, or other secure messaging system. These examples are not intended to be limiting, and it is understood that additional methods of notification MAY be created that were not originally anticipated by the working group.
• Clarify/reiteration from last week’s discussion – once the transfer is submitted it is done; so no NACK process.  Instead, when you request a TAC you get a notification that you have requested a TAC and the registrant has the option to confirm (yes) or not (no).  Notice has two parts – confirm or deny.
• (For notification of TAC provision and notification of transfer completion, but presumably would also apply to this additional notification).
• Provisioning a TAC does not initiate a transfer.
• Because we are frontloading things are we also frontloading hurtles to those who want to transfer?  Are we still getting them the TAC to allow them to do what they want to do.  Getting the TAC to the RNH might be important, but are we adding that agility at the expense of being flexible to transfer.
• If a registrar does not allow a registrant to leave, then they are violating the existing Transfer Policy.
• What problem are we solving from a technical concern – being able to deny the transfer before it starts?  Don’t see the problem from a systems point of view.  Small group will get together during CPH meeting to compile a list of attack vectors and how our recommendations solve them, or not (and explain why not).
• The registrant may not be the person making the request for the transfer.  The problem we are solving isn’t a technical problem but a security issue to make sure the registrant agrees to the transfer occurring -- what was the Losing FOA.
• The provisioning of the TAC does not initiate the transfer.  Notification versus confirm/cancel are two different things.  Doing this on the provisioning of the TAC is increasing the difficulty of transfer.  Commenters want the chance to deny the transfer that is about to go through – but this proposal doesn’t do that.
• In our current recommendations once the TAC is communicated the transfer can happen nearly simultaneous.  In our new proposal when the NACK can happen doesn’t matter, just that we put the ability to deny before the TAC provision.  This is the Losing FOA --  it requires the registrar to do something to allow the transfer to go through; just bringing back the same window that the registrars have.  We are saying there has to be an explicit window for the registrants to deny it.
• This is a compromise on what we proposed previously.  This covers a lot of things, but not a technical fix.  Giving the registrants what they want.  This is our response to the feedback we got.
• Think this is a worse situation as it still exposes us to complaints that we’ve removed the Losing FOA and removed a window that allows the transfer to be NACKed at the last minute.  It requires registrars to change their code without any real benefit.   Why not just put the Losing FOA back?
• Does it make sense that we are adding the FOA into the 5-day window? Why not just leave the FOA?  What’s the benefit?  We are lengthening the transfer process by having two windows – one for the registrar and one for the registrant.  Does it make sense to streamline into one 5-day window?
• Going back to the principles of the public comment review: when we are going through the comments on the recommendations the goal is to get consensus on the final recommendation.  If we can’t get consensus on change from the status quo then we go back to the status quo, which is the Losing FOA.  There are also previous discussions on way to improve the Losing FOA that might be a way forward.
• Might want to consider what rollback (Phase 2) might look like.  Some of this might be disrupted.  Don’t know if we can come back to address something from Phase 1.
• A claw-back will help us but that is reactive, rather than proactive like the Losing FOA.
• What we said at the end of the last call was bringing the Losing FOA back in its functionality.  Does it stay at the end (as it was today) or move it out front to the 5-day window that the registrar have to provide the TAC.
• What is the second 5-day window?  We currently have that, but the recommendation is a single 5-day window and the proposal is to put the notification into the (now) single 5-day window.
• If we combine the windows change it from “Losing FOA”.
• In today’s world the registrars and registrants are used to two 5-day windows. We are proposing one 5-day window.  If we don’t get consensus on changes then we will go back to two 5-day window.
• It would help to get a “time line “ displayed indicating the alternatives, inc. when the RNH can NACK the transfer.
• Registrars should look at proposed edits (b) and (c) as a possible middle path to no FOA or a proposed FOA. CPH Tech Ops may consider at its next meeting.
• If we are keeping the functionality should it stay at the end, or do we go to one 5-day period and put the notification at the beginning?
• The other question is whether the 5-day window is correct, or should it be shorter?
• The original timeline reflected business days.
• It was up to 5 days, but it could be less.  Once they get the TAC it can be fairly immediate.
• Question: What is wrong with the status quo?  Answer: Those who are seeking to streamline are looking for better ways to serve their customers’ needs.
• In my view, 5 days is OK. More critical (in time) is the (potential) 30 days transfer lock due to a material change of registrant data.

ACTION ITEM: Staff to create a diagram comparing the timeline of the existing Losing FOA with the proposed notification of TAC request discussed during the meeting on 18 October.

4. Begin Discussion of Notification – Recommendations 3 and 4 (see Recommendation 3 Public Comment Review Tool and Working Document [docs.google.com] and Recommendation 4 Public Comment Review Tool and Working Document [docs.google.com])

From the Working Document:

Recommendation 3: The working group recommends that the Registrar of Record MUST send a “Notification of TAC Provision” to the RNH, as listed in the registration data at the time of the TAC request, without undue delay but no later than after the Registrar of Record provides the TAC.

3.1: This notification MUST be written in the language of the registration agreement and MAY also be provided in English or other languages.

3.2: The following elements MUST be included in the “Notification of TAC Provision”:

• Domain name(s)
• Date and time that the TAC was provided and information about when the TAC will expire
• Instructions detailing how the RNH can take action if the request is invalid (how to invalidate the TAC)
• If the TAC has not been provided via another method of communication, this communication will include the TAC

Discussion:

• These recommendations are tied to what we do with recommendations and whether we go back to retaining the Losing FOA.  Do they make sense no matter what we do?  Don’t think there’s any reason to change recommendation 3.
• Think it’s useful to cover the comments on recommendation 3.

Public Comments Suggested Edits on Privacy/Proxy Services (Proposed Edit (c)):

• Use of the term “Registration Data” (“as listed in the Registration Data at the time of the TAC request”) could suggest that this applies to Privacy/Proxy service data. Add an Implementation Note clarifying that “Registration Data” in case of a domain with an active P/P service means the underlying customer data, not the publicly-displayed P/P data.
• The recommendation refers to the registered name holder (RNH) obtaining the TAC, however for domain names that utilize Privacy/Proxy services, it is possible that the underlying customer may obtain the TAC rather than the RNH. According to Section 1.3 of the Specification on Privacy and Proxy Registrations of the 2013 RAA, a Proxy Service is considered the RNH and licenses use of the domain name to the customer. It is impractical for a Proxy Provider to obtain TACs on behalf of customers, and this recommendation should be updated to accommodate Privacy/Proxy service customers.
• The term “RNH, as listed in the Registration Data at the time of the TAC request” is incorrect as it should simply be “the RNH at the time of the TAC request” to allow for registrants who use Privacy/Proxy service data. We suggest removal of “, as listed in the Registration Data” so that it reads “to the RNH at the time of the TAC request”. c.f. Recommendation 14.

Potential next step: Strawman revision:

Recommendation 3: The working group recommends that the Registrar of Record MUST send a “Notification of TAC Provision” to the RNH, as listed in the registration data at the time of the TAC request, without undue delay but no later than after the Registrar of Record provides the TAC.

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. In cases where a customer uses a Privacy/Proxy service, the Registrar of Record should send the notification directly to contact information associated with the underlying customer where it is possible to do so.

Public Comment Proposed Edit (d):

Include additional elements required to be included in the “Notification of TAC Provision” such as:

* An element that explains that the TAC will enable the transfer of the domain name to another registrar.

* The deadline by which the RNH must take action if the request is invalid so that the registrar has sufficient time to NACK the transfer, where applicable (note that, at the time the RNH receives the “Notification of TAC Provision”, the TAC may have already been provided and the transfer command sent to the registry operator).

* Required actions registrars must take (and by when) upon receiving notification by the RNH of an invalid request.

Public Comment Proposed Edit (e):

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.

See further public comments and proposed edits in the working document.

5. AOB