Logo

050040040 Transfer Policy PDP WG - Shared screen with speaker view
Owen Smigelski (RrSG)
27:49
Jody will be arriving late to the call today
Julie Bisland - ICANN Org
28:57
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en
Jody Kolker (RrSG)
29:19
Actually I'm here (sorry Owen, I didn't post this otherwise)
Zak Muscovitch (BC)
30:14
Welcome, Keiron!
Keiron Tobin (RrSG)
30:32
Thank you
Prudence Malinki (RrSG)
30:34
Welcome on board Keiron!
Sarah Wyld (RrSG)
33:11
This doc seems like it will be very helpful, thanks to the Staff team!
Emily Barabas - ICANN Org
33:18
Here is the link: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit?usp=sharing
Berry Cobb
38:10
Repost to all panelist & attendees: We'd note, there does not appear to be a definition in the agreements, thus the reference source.
Berry Cobb
38:27
Repost to all attendees: And in terms of nailing down a concrete definition, the term is also applicable. Should it always be referred to "Auth-Info Code" or "Authorization Code", etc...
Kristian Ørmen (RrSG)
40:18
Yes, it’s possible
Sarah Wyld (RrSG)
40:21
Sure that's possible. And although the registrar-generated code must be unique, if a registrant can themselves set a code they might set the same code on multiple domains, nothing stops them
Sarah Wyld (RrSG)
40:45
I don't think that's a significant concern
Sarah Wyld (RrSG)
40:48
(As Jim just said)
Berry Cobb
41:07
Coolio. Thanks. Informative.
Sarah Wyld (RrSG)
43:41
This order seems reasonable to me, thank you
Sarah Wyld (RrSG)
44:08
Sorry are we looking at blue-box questions or the bullets under the box on screen now?
Emily Barabas - ICANN Org
44:46
@Sarah, the blue box questions
Sarah Wyld (RrSG)
45:00
Thanks Emily! OK - so yes I think they're in a good order.
Sarah Wyld (RrSG)
45:18
+1 Jim
Sarah Wyld (RrSG)
53:22
It's also often colloquially called the EPP Code! Just to make things extra confusing :)
Berry Cobb
53:33
How is it referred to within RFC from IETF, if it exists?
Sarah Wyld (RrSG)
53:35
I personally like "Transfer Authorization Code" because I think it's very clearly descriptive of what it's for
Sarah Wyld (RrSG)
54:06
Berry, I believe it's "authinfo", e.g. https://datatracker.ietf.org/doc/html/rfc5731
Owen Smigelski (RrSG)
54:21
+1 Sarah
Sarah Wyld (RrSG)
54:35
it's a bit long but we don't need to save bytes, right?
Jim Galvin (RySG)
54:54
+1 Sarah. Good choice for all textual discussions.
Berry Cobb
55:00
Ripe for an acronym? ;-) TAC
Sarah Wyld (RrSG)
55:19
oh there is *always* room for a new acronym!
Owen Smigelski (RrSG)
55:32
Hopefully we don’t confuse TAC with NAC ;-)
Berry Cobb
55:48
And TEAC
Barbara Knight - RySG
56:55
I believe that currently the EPP Auth Info code is used only for transfers but could it be used more broadly in the future that may preclude us from referring to it as Transfer Authorization Code?
Jim Galvin (RySG)
01:00:51
That’s a good question Barbara. I wouldn’t think so but then again who knows what might be invented in the future. Have to think about it some more.
Jody Kolker (RrSG)
01:01:47
The Authorization Code can be used by a registrar that is not the registrar of record for a domain to gain additional information for a domain than what the non registrar of record could gain. It could be used for validating contact information related to the domain if you have the authcode for the domain. Would anyone use this? Not sure.
Steinar Grøtterød (At-Large)
01:05:20
Question: How can 2FA be used in the transfer?
DANIEL K. NANGHAKA (At-Large)
01:05:28
The AuthInfo Code does not identify the natural person but it posses a security threat when accessed despite the fact that some domains have the Domain Lock
Sarah Wyld (RrSG)
01:06:27
Daniel, I agree that the authcode is a security concern rather than a data processing concern. But I think if the domain is locked, then someone possessing the authcode is not necessarily able to unlock the domain also (if they don't have access to the account in the registrar where the domain is)
Sarah Wyld (RrSG)
01:06:44
Yeah, TTL will be a good security measure
Keiron Tobin (RrSG)
01:07:21
It might not be at the moment, but with NSI2 and DSA, and the new Brazilian laws coming, I think brining someone in who can legally confirm privacy in different jurisdictional might be in our interest
Steve Crocker (SME)
01:07:27
I agree with everything Jim said about improving the security of the authcode. The authcode is a form of one time password, and thus it should be treated the same way. E.g. unguessable, short-lived, etc. That said, one of the scenarios that may be important from a business perspective is the transfer of a large number of domain names. What is the posture of the registrar stakeholder group regarding bulk transfers?
DANIEL K. NANGHAKA (At-Large)
01:08:17
@Steve if you are doing a bulk transfer then each domain should have an AuthInfoCode
Crystal Ondo - Google (RrSG)
01:08:47
+1 Steve. I think it's worth discussing if a single authcode would suffice for a bulk transfer.
Barbara Knight - RySG
01:08:53
It is not a one time use today.
Jody Kolker (RrSG)
01:09:03
+1 Crystal/Steve.
Sarah Wyld (RrSG)
01:09:39
Absolutely agree, Tom!
Sarah Wyld (RrSG)
01:11:18
One authcode for multiple domains (bulk transfer) seems like it introduces security concerns but maybe isn't super helpful, it makes me very nervous. Definitely need to think that one through.
Crystal Ondo - Google (RrSG)
01:12:22
It's a much better customer experience, a single code to authorize a bulk transfer. Do think it's doable, but yes should be discussed.
Sarah Wyld (RrSG)
01:13:14
Crystal that's probably true, but it depends on how the code is obtained, right? If there's a button in the CP that says "get my auth code" and you can select one domain from a list or multiple, then it's just as easy for the RNH to get a different code per domain, right? But maybe that's too specific. Anyways, definitely looking forward to discussing it!
Crystal Ondo - Google (RrSG)
01:13:19
Agree, Keiron
Jim Galvin (RySG)
01:13:41
i suggest that bulk transfers is a separate process and then yes, one authcode for the bulk is a reasonable construct if all the other elements are in place.
DANIEL K. NANGHAKA (At-Large)
01:16:36
I would not support one code for a bulk transfer because of the security concerns in the transfer
Sarah Wyld (RrSG)
01:16:40
Yeah - cant make it prohibitive or people will find ways around the security processes
Keiron Tobin (RrSG)
01:16:44
If a registrant wanted a single auth-code for multiple domains, maybe they should have to request it and it takes time to generate (24 hours). As a suggestion
Sarah Wyld (RrSG)
01:17:10
If the RNH can set their own code on domains, they could set the same code on all domains. It's only the Rr that has the unique code requirement
Caitlin Tubergen - ICANN org
01:17:36
I.5.3 Registrars may not employ any mechanism for complying with a Registered Name Holder's request to remove the "ClientTransferProhibited" status or obtain the applicable "AuthInfo Code" that is more restrictive than the mechanisms used for changing any aspect of the Registered Name Holder's contact or name server information.
Sarah Wyld (RrSG)
01:17:57
Thanks Caitlin
DANIEL K. NANGHAKA (At-Large)
01:18:07
If a AuthInfo Code is requested, I would not see a challenge to verify the request through 2FA
Sarah Wyld (RrSG)
01:18:25
So maybe we should consider if 1.5.3 is helpful enough. If the method to change RNH contact/NS info requires sending in a certified mail, that may be problematic...
Thomas Keller (RrSG)
01:18:49
There is a 2FA, FOA 2
Owen Smigelski (RrSG)
01:18:54
@Daniel- that might require a lot of work for registrars who are not currently setup for 2FA (likely smaller registrars)
DANIEL K. NANGHAKA (At-Large)
01:19:56
2FA is becoming a security standard - they could jump onboard based on Policy recommendation
Keiron Tobin (RrSG)
01:20:00
I agree, that data from ICANN would be useful
Sarah Wyld (RrSG)
01:20:03
Maybe we can put out a survey to CPs
Sarah Wyld (RrSG)
01:20:20
True, yeah
Thomas Keller (RrSG)
01:20:25
See what ccTLDs are doing
Sarah Wyld (RrSG)
01:20:35
but if we want to gather data about current experiences from CPs I feel like that'd be useful?
Emily Barabas - ICANN Org
01:20:56
There are some questions included in the survey that was part of the Transfer Policy Status Report
Emily Barabas - ICANN Org
01:21:07
The comments are summarised in the Issue Report
Sarah Wyld (RrSG)
01:21:13
Thanks Emily, clearly I need to go back to that report and see what data was included!! I remember it seemed useful at the time when I did read it...
Emily Barabas - ICANN Org
01:21:21
But of course, the group may have new or additional questions for contracted parties
Steve Crocker (SME)
01:23:13
I’m guessing the business situation is bimodal. Having an efficient way of transferring a large number of registrations probably applies to a small fraction of the RNHs. And “large number” is probably — I’m guessing — 20 or more. If the RNH wants to transfer more than one but not too many, treating each as a separate transaction is tolerable.
Jim Galvin (RySG)
01:23:23
to know whether we need 2FA we really need to answer the question of the goal we’re trying to achieve. my current belief is we don’t need it but I’m certainly open to a description of a threat we need to cover.
Keiron Tobin (RrSG)
01:24:48
+1 Jim
Sarah Wyld (RrSG)
01:25:24
+1 Jim
Barbara Knight - RySG
01:26:29
+1 Jim
Jim Galvin (RySG)
01:30:38
to the extent there’s a security impact, then it’s a policy consideration. for example, minimum length for the authInfo would be policy consideration. for example, uniqueness of an authInfo would be a policy consideration. guidance but not requirements on how to create an authInfo would be helpful but not necessarily binding.
Holida Yanik (ICANN Org)
01:32:02
Compliance is currently working on compiling updated Transfer-related metrics
DANIEL K. NANGHAKA (At-Large)
01:32:20
Thanks @Holida
Sarah Wyld (RrSG)
01:33:19
Thank you Holida!
Keiron Tobin (RrSG)
01:33:39
Have we decided a name for the instant transfer process haha?
Sarah Wyld (RrSG)
01:35:50
oh good question
Sarah Wyld (RrSG)
01:36:37
Makes sense to me
Sarah Wyld (RrSG)
01:36:41
provisioning and also NOT provisioning
Kristian Ørmen (RrSG)
01:38:37
I think we need to define a minimum level of security around the authcode
Steve Crocker (SME)
01:40:34
Design of a specific one time 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.
Thomas Keller (RrSG)
01:47:58
Once a month but can be speed up
Thomas Keller (RrSG)
01:50:34
Can we have a look at the tech/ops doc at some time?
Emily Barabas - ICANN Org
01:50:39
Next meeting (ICANN71 session): 16 June 2021 @ 12:30 UTC
Sarah Wyld (RrSG)
01:52:42
Thanks, all!
Kristian Ørmen (RrSG)
01:52:47
Thanks
Catherine Merdinger (RrSG)
01:52:47
Thanks all!
Jody Kolker (RrSG)
01:52:49
thanks all!
Zak Muscovitch (BC)
01:52:51
many thanks!
Sarah Wyld (RrSG)
01:52:51
Rogerian brevity!
Prudence Malinki (RrSG)
01:52:56
Thanks everyone!
Thomas Keller (RrSG)
01:52:57
See you all