Dear Working Group Members,

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

The next meeting will be during ICANN71 on Wednesday, 16 June at 12:30 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

--

Action Items

Please refer to the Work Plan and Action Items List for updated action items.

Transfer Policy Review Phase 1 - Meeting #05

Proposed Agenda

Tuesday 8 June 2021 at 16.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Welcome & Chair updates (5 minutes)

• Support Staff plans to share the draft SO/AC/SG/Cs outreach document with the WG following this call.
• The proposed deadline for adding comments and proposing additional questions will be 24 June. Support Staff will aim to finalize the document during the 29 June call.
• We intend to use Google Drive as our primary method for working on shared documents, pending no objections. (No objections were raised during the call.)

3. Discussion of AuthInfo Codes (75 minutes)

• The first section of the document provides the relevant policy language from the Transfer Policy and the Interim Registration Data Policy.
• The working definition can evolve over time. The definition, as written, was pulled from ICANN’s website. As the Team is working through the charter questions, please have the working definition in mind so that we can finalize this for the report later in the process.
• Regarding “unique codes”, curious how this actually works for the non-technical or non-registrar members. Is it possible that two registrars could develop the same random code, for example? Has this ever happened? Is an authinfo code collision possible?
• From a technology point of view, yes – this is possible, but something to keep in mind is the code has to be correlated to something. The likelihood of this happening in terms of the same two people trying to transfer a domain name – is next to zero. If this is a concern, the domain name could be hashed.

• 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?

• As a starting point, it’s important to know what we are trying to achieve with the auth-info code as an overarching question before reviewing who the manager of the code should be.
• In terms of evidence, there must be some evidence that we can look at – like ICANN compliance tickets re: auth codes being insecure, people not being able to get access, etc.
• Since the dependency on auth codes have changed, it may be helpful to look backwards and forwards – (pre-Temp Spec elimination of Gaining FOA and post-Temp Spec elimination of Gaining FOA).
• Do not think if asking if auth codes are secure enough at the right question? The real question is – what are we trying to achieve with auth codes – what we are trying to derive from a security point of view.
• What is the difference between the auth code and the one-time password referenced in the document?
• In EPP, it’s called authinfo; however, it’s called other names such as password, authorization code. Use of onetime password is a way of saying this is a goal we are trying to achieve. A onetime password has all of the goals you would want to achieve.
• "Transfer Authorization Code" may be an optional replacement of the term auth code because it is more descriptive
• There should be one standard term used across the board, so registrants don't get confused
• From a security point of view with no consideration to business processes, our use of authinfo codes is not secure enough. There are changes that are necessary and should be made. For one, it is not uniformly managed and processed at independent registrars. We need to create homogeneity about what it means to create an authinfo code. With that in mind, there is discussion to be had about how a transfer works and how we adapt the security principles that come with a onetime password and make sure they are covered.
• If we create a transfer authorization code, are we creating an identification that could be PII which could be problematic with data privacy laws?
• Many systems are adopting two-factor authorization – suggest that, if possible, recommend that two-factor authentication be enabled such that the domain name owner can verify this is a genuine transfer request
• The auth code could be personal data, but not necessarily. The auth code does not say who someone is, so it would be difficult to identify a natural person, although in some edge cases, it could be used to validate information. This should be protected similar to how passwords are protected. If it is personal data, there would be a legitimate interest for processing the personal data.
• The goal should be secure transfers. The authinfo code is a good method for registrar transfers. There are small things to do to make it more secure, such as TTL – which makes it a onetime password.
• The whole transfer process is a pain and a lot of people do not understand it. Making it secure does not mean that people will use it. Usability is another issue the group should consider.
• The question about usability and bulk are excellent and important questions – that is why we need to talk about the business processes that need to be in place. What are the uniform steps that we are going to follow to make this work? Where is the uniformity within each of those steps that we all agree to abide by? Is bulk a separate process, or will it be incorporated in? These are all choices to be made, and they’re all related.
• It’s not just about the security about the auth code itself; it’s also about getting the auth code. There should be an easy way for the registrar to actually get the auth code
• There should be requirements regarding explaining how a registrant can get its auth code
• If it comes to security level of the auth code, we could have a look at ccTLDs. We could copy what is already out there.
• It sounds like the group thinks the auth code is a secure mechanism that needs improvements
• With respect to onetime use, the first issue is whether or not we believe the goal is to make sure that we are correlating the registrant at both ends – from the incumbent registrar to the gaining registrar. With that in mind, a onetime password might be enough. Two-factor authentication may be overkill for this application but could be dissuaded if others disagree with this position. We should have guidance about how to create an auth code, how long it has to be, and other technical guidance regarding its lifetime and when they come into existence and when they don’t. When you start getting into where and how it’s used, then you talk about the management. How much of a role do registries have? There are a few things we need to get through and not prepared to answer these questions without more information.
• Registrars have to answer the question about two-factor authentication. You would want one system that everyone is going to have so there is interoperability.
• 2FA is more of a hindrance – this would not go down well, and not sure this is what we are trying to achieve. In terms of looking at best practices, it could be optional, but some smaller registrars may not have the capability and it would not be a fair approach.
• We should not lock down to one specific type of security. Many registrars already use 2FA.
• Some people think a transfer should be instant – how would the code be evaluated and provided in this instance
• Regarding when not to provide an auth code, this comes to provisioning.
• To the extent there’s a security impact, then it’s a policy consideration.  For example, minimum length for the auth info would be policy consideration.  For example, uniqueness of an auth info would be a policy consideration.  Guidance but not requirements on how to create an auth info would be helpful but not necessarily binding. Is it created as needed? Does it have a lifetime? These are policy considerations that have a security impact. If authinfo is going to replace the FOA, there needs to be some considerations added.
• Who is going to have the operational burden? The second part that needs to be determined whether the registrar is responsible for doing certain checks or the registry.
• Design of a specific onetime password scheme is better done by specialists, not a group like this.  What this group will be good at is setting general requirements and evaluating a proposed scheme in terms of its usability, cost of implementation, etc.
• This group needs determine what the concerns are and have a technical group design something with these concerns in mind and pass it back to the WG for confirmation

4. Next steps & closing (5 minutes)

Next meeting (ICANN71 session): 16 June 2021 @ 12:30 UTC