ICANN 71: Difference between revisions
No edit summary |
|||
Line 61: | Line 61: | ||
#::NIS2 will require the distinction and must publish legal data, leading to an unequal playing field. Those subject to EU regulations will have to and others will not. | #::NIS2 will require the distinction and must publish legal data, leading to an unequal playing field. Those subject to EU regulations will have to and others will not. | ||
# Feasibility of unique contacts/anonymized emails: possible policy stances include that they are feasible, required, suggested with guidance, or not at all. | # Feasibility of unique contacts/anonymized emails: possible policy stances include that they are feasible, required, suggested with guidance, or not at all. | ||
* GNSO [[Policy Development Process to Review the Transfer Policy]] [[WG]] | * GNSO [[Policy Development Process to Review the Transfer Policy]] [[WG]] | ||
: The session was dedicated to determining PDP Goals, specifically around the retention/overall security of [[Transfer Authorization Code]] (TAC). The hope is that if the TAC is strong enough, the WG could recommend eliminating [[FOA]]s. The WG decided to include a request to tech ops to determine whether TACs would be secure enough to ensure that the requesting registrant owns the domain in question. [[James Galvin]] raised several questions about the TAC mechanism. He asked about specifications such as one-time use, lifetime, and length. Galvin also reminded the group that ICANN uses FOAs for a paper trail as security/authorization. If the WG wants to recommend using TACs, it will have to be properly implemented to be as secure as possible. [[Roger Carney]] said that the goal is to remove or make optional FOAs and only use the code (TAC), which has been used for the last 3 years. There was also a discussion over the metrics for determining the secureness of TACs. There is anecdotal evidence but by security principles, the mechanism is not yet entirely secure. | : The session was dedicated to determining PDP Goals, specifically around the retention/overall security of [[Transfer Authorization Code]] (TAC). The hope is that if the TAC is strong enough, the WG could recommend eliminating [[FOA]]s. The WG decided to include a request to tech ops to determine whether TACs would be secure enough to ensure that the requesting registrant owns the domain in question. [[James Galvin]] raised several questions about the TAC mechanism. He asked about specifications such as one-time use, lifetime, and length. Galvin also reminded the group that ICANN uses FOAs for a paper trail as security/authorization. If the WG wants to recommend using TACs, it will have to be properly implemented to be as secure as possible. [[Roger Carney]] said that the goal is to remove or make optional FOAs and only use the code (TAC), which has been used for the last 3 years. There was also a discussion over the metrics for determining the secureness of TACs. There is anecdotal evidence but by security principles, the mechanism is not yet entirely secure. |