Thank you Evin. that is very helpful My suggestion is that you put the text of my email, Alan’s response and my response to him - (the last two are very recent) and then everyone can both read and comment on this issue Thanks again for being so helpful Holly On 17 Apr 2018, at 5:48 pm, Evin Erdogdu <evin.erdogdu@icann.org> wrote:

Dear Holly, Alan and All,

I have created a workspace for the Data Protection/Privacy Issues Update: Soliciting Community Input on Article 29 Guidance.

Holly, I have assigned you as penholder, but please let me know if that was not your intention.

Thank you, Evin

From: ALAC <alac-bounces@atlarge-lists.icann.org> on behalf of Alan Greenberg <alan.greenberg@mcgill.ca> Date: Tuesday, April 17, 2018 at 9:59 AM To: Holly Raiche <h.raiche@internode.on.net>, ALAC <alac@atlarge-lists.icann.org> Subject: Re: [ALAC] ALAC Response to Accreditation Model - due date 20 April

Holly I have been travelling and am ties up in meetings all day (Brussels time), but I hope to add some comments later tonight.

I caution care in interpreting the Article 29 letter. Despite some valid concerns, it shows an astounding lack of knowledge of the Internet and ICANN's mission. As a prime example is their advice to just focus on our own business and not that of others such as law enforcement or those combatting cyber issues. Our mission is to protect the DNS and that includes making it reliable and safe. But we do not have the ability to do that ourselves and thus must provide the tools for others to do that. If we fail, we are NOT carrying out our mission.

This will get more interesting in coming weeks.

Alan

At 16/04/2018 07:58 PM, Holly Raiche wrote:

Folks

We are fast running out of time to develop any kind of response to the accreditation model, even though the deadline for a response has been extended to this Friday. And in the interim, ICANN has received advice from Article 29 on the Interim model. (Article 29 is an advisory Group made up of a data protection authority from each EU member state). Their letter to ICANN, and Marby?s response, are on the home page of ICANN - and for those interested in the issue, I highly recommend reading both. Clearly, the implications of the Article 29 letter are that the Interim Model that we did comment on still raises concerns with them. Those concerns fall under the headings: Breadth of purpose - saying the proposed purposes are too widely drawn the link of purpose to processing - again, because the Whois data has been used does not qualify it as a purpose publication of the data must be linked to the original (and narrowly defined) purpose any access should be limited - not blanket access discussion about the length of retention of data discussion about the transfer of data Accreditation (particularly important in this context) - should only be for legitimate purpose, limited to the original purpose, not blanket access, and under limited conditions

Below, I have copied in an email from Scott Hollenbeck, a long standing member of ICANN and one of those involved in the development of the RDAP (access protocol that would allow gated access to registration data) - simply because he has been involved in this issue for a long time and shows he has already worked on a technical solution to this issue - how access to data could work under GDPR.

I will try to attend as much as possible of the capacity building webinar on this issue, but have been scheduled to attend an all-day course in the Sydney CBD so may have to miss some of the discussion. I imagine Tom will be very up to date on these issues, but I would like to have been attending the whole of the webinar myself

In any case, if at all possible, we should be saying something. Quite apart from the original contribution from the IPC/BC model, the NCSG and Registrars have also made comments (largely challenging the IPC/BC model). I hope we are the one constituency that doesn?t make comments - although I realise that agreement on what to say will be difficult at the best of times.

And if it isn?t too late - maybe put this issue on the ALAC policy page - and with it, links to the Article 29 letter, Marby?s response, the registrars? response and the NCSG response (and any others I have missed - I have copies if that helps)

Holly

Hi all.

After reading the Article 29 WP letter to ICANN ( awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby- 11apr18-en.pdf), I started envisioning what process and system could achieve GDPR compliance. What I came to is a token-based system, which would work like this: - Every request is analyzed by a human at an "RDS Clearinghouse". Each request can be for a single data element (like "owner of domain X") or to multiple data elements (like "domains owned by the same owner of domain X"), but requests for multiple data elements are only foreseen to be processed by contracted parties with "Search WHOIS" contract requirements. - Clearinghouse issues a token with query parameters, data elements authorized for response, identity of authorized party, reason for authorization, validity (probably in the order of days), also informing which endpoint to go to. - Authorized party uses that token to access that endpoint, managed by the party with most data about that element (usually a registrar).

Note that is not a replacement for credentialing; credentials would still be necessary to get tokens. This is also orthogonal to discussions like which use cases are legitimate or not, GDPR-compliant or not etc.; it's just a more granular approach to authorization that looks more inline with privacy-oriented guidelines including but not limited to GDPR.

Rubens, at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.

Scott,

I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably could be made to work like this. And some level of asynchronous communications could even make way for a quick look human analysis.

Rubens

I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search for ?draft Hollenbeck RDAP OpenID? using your favorite search engine. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics: 1;YTOPR01MB0396;27:E+eV2ZOSHNubNtVECuy/VM/L0xhmfXbZcuSQZbzTXSXqae7LUG8EA97rPf+2WwLbTntAgo7cpRKp5nw8d8T6ebvY8Vy/iFaEy7AJW3LXmiMa8o52Hh4X6vuxt8b9Dc+H X-Microsoft-Antispam-Message-Info: mbIfSQV0+eZC39ENiUAspKdQkF0+JSTZwhHzgGzIJcnMTMtI1YFjxfAYUWl5x8Xsb0hCkvQc7VzC4AbTCpUbUGRQU6RcE5UUx1wEGk3WXKVvz27yXSf3osNfP8UwExDIUIL1xB46d04FaxAvbFZx3V7Y2ZVoGnlOF9jsJrXvgUSoJT4DsABV8smZdk4vNHRjunBYHmX/Uyc08KK5W5zM0fDRY7NEhuy8gp+3GzVz4A/5TqlICRbEqPiDy4iZWnOAaPiE4ELCAfZPmhMusibjqJno9CcaR04f9ovSYOL+LGRVBVtQ1M9b/SxTHtnAjl+ENjnGKfOC/j1+ryUspB55Z6d0P1zabIZYAwo87l1z4xMWzu3tmPExSwczo7sS129laKLyfrpQKQl6gt36u0ia78/RPd+UH+swgobcmXrp+pNPCIV60r6mKu9CLHxwfljZtI62wcXHykdzvBpIoyKjBQ==

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac[atlarge-lists.icann.org]

At-Large Online: http://www.atlarge.icann.org[atlarge.icann.org] ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC[community.icann.org] )

I said *I* would try to add some comments tonight. Add to what you had said (on Wiki now that it is there). Still hope to but time running out. To be clear, it IS *OUR* job to make sure that the DNS is safe and reliable. That is our only job! Law enforcement, or anyone else that can justify their need can get data only if we first collect it. But that is not relevant to the accreditation model as Scott says. At 17/04/2018 07:13 AM, Holly Raiche wrote:

Hi Alan

When you say 'we can add some comments tonight' my questions are * what comments? * and add to what? There is no link on the policy page to the accreditation model.

And next - I'd have to differ on your views. Article 29 starts from basic privacy principles - as followed in over 100 countries around the globe with data protection regimes. First basic principle: only collect personal information that is necessary to do YOUR job. You don't collect information you don't need. Next principle: You tell the data subject why you need their personal information, and the circumstances in which that information will be shared. It is to THAT limited use and disclosure that people consent to giving their personal information. And it is in those LIMITED circumstances in which personal information is disclosed. The fact that others may want access is irrelevant.

So that right away limits who gets information - and in limited circumstances only.

In almost every data protection regime, law enforcement will be a circumstance in which personal information is made available. But again - not blanket permission, but in circumstances where there is a reasonable chance that illegal/harmful activity is or has taken place. And a further read suggests that access would also be given to Government/government authorised authorities as well. Two examples in Australia would be ASIC, our prudential regulator, and the ACCC, our competition and consumer watchdog. So the category of law enforcement probably extends to other regulatory/enforcement agencies - again, in situations where harm is suspected/occuring.

So - far from having an outstanding lack of knowledge about the Internet and ICANN, Article 29 know exactly what is going on. And it is what now amounts to unlawful release of personal information - and not just in the EU.

If there is to be any even slightly middle ground, it will be close to the model that Scott has already tested - access is possible, but to specific, accredited people and for specific situations. And it is in THAT context that the DNS will be protected. (and, as the cyber security advisor to our Prime Minister said, when asked how to make the Internet safe, replied that it isn't possible to make it safe, only safer.)

Holly

On 17 Apr 2018, at 4:58 pm, Alan Greenberg <<mailto:alan.greenberg@mcgill.ca>alan.greenberg@mcgill.ca> wrote:

...

Holly I have been travelling and am ties up in meetings all day (Brussels time), but I hope to add some comments later tonight.

I caution care in interpreting the Article 29 letter. Despite some valid concerns, it shows an astounding lack of knowledge of the Internet and ICANN's mission. As a prime example is their advice to just focus on our own business and not that of others such as law enforcement or those combatting cyber issues. Our mission is to protect the DNS and that includes making it reliable and safe. But we do not have the ability to do that ourselves and thus must provide the tools for others to do that. If we fail, we are NOT carrying out our mission.

This will get more interesting in coming weeks.

Alan

At 16/04/2018 07:58 PM, Holly Raiche wrote:

...

Folks

We are fast running out of time to develop any kind of response to the accreditation model, even though the deadline for a response has been extended to this Friday. And in the interim, ICANN has received advice from Article 29 on the Interim model. (Article 29 is an advisory Group made up of a data protection authority from each EU member state). Their letter to ICANN, and Marby's response, are on the home page of ICANN - and for those interested in the issue, I highly recommend reading both. Clearly, the implications of the Article 29 letter are that the Interim Model that we did comment on still raises concerns with them. Those concerns fall under the headings: * Breadth of purpose - saying the proposed purposes are too widely drawn * the link of purpose to processing - again, because the Whois data has been used does not qualify it as a purpose * publication of the data must be linked to the original (and narrowly defined) purpose * any access should be limited - not blanket access * discussion about the length of retention of data * discussion about the transfer of data * Accreditation (particularly important in this context) - should only be for legitimate purpose, limited to the original purpose, not blanket access, and under limited conditions

Below, I have copied in an email from Scott Hollenbeck, a long standing member of ICANN and one of those involved in the development of the RDAP (access protocol that would allow gated access to registration data) - simply because he has been involved in this issue for a long time and shows he has already worked on a technical solution to this issue - how access to data could work under GDPR.

I will try to attend as much as possible of the capacity building webinar on this issue, but have been scheduled to attend an all-day course in the Sydney CBD so may have to miss some of the discussion. I imagine Tom will be very up to date on these issues, but I would like to have been attending the whole of the webinar myself

In any case, if at all possible, we should be saying something. Quite apart from the original contribution from the IPC/BC model, the NCSG and Registrars have also made comments (largely challenging the IPC/BC model). I hope we are the one constituency that doesn't make comments - although I realise that agreement on what to say will be difficult at the best of times.

And if it isn't too late - maybe put this issue on the ALAC policy page - and with it, links to the Article 29 letter, Marby's response, the registrars' response and the NCSG response (and any others I have missed - I have copies if that helps)

Holly

...

...

...

Hi all.

After reading the Article 29 WP letter to ICANN (<awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-> awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby- 11apr18-en.pdf), I started envisioning what process and system could achieve GDPR compliance. What I came to is a token-based system, which would work like this: - Every request is analyzed by a human at an "RDS Clearinghouse". Each request can be for a single data element (like "owner of domain X") or to multiple data elements (like "domains owned by the same owner of domain X"), but requests for multiple data elements are only foreseen to be processed by contracted parties with "Search WHOIS" contract requirements. - Clearinghouse issues a token with query parameters, data elements authorized for response, identity of authorized party, reason for authorization, validity (probably in the order of days), also informing which endpoint to go to. - Authorized party uses that token to access that endpoint, managed by the party with most data about that element (usually a registrar).

Note that is not a replacement for credentialing; credentials would still be necessary to get tokens. This is also orthogonal to discussions like which use cases are legitimate or not, GDPR-compliant or not etc.; it's just a more granular approach to authorization that looks more inline with privacy-oriented guidelines including but not limited to GDPR.

Rubens, at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.

Scott,

I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably could be made to work like this. And some level of asynchronous communications could even make way for a quick look human analysis.

Rubens

I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search for "draft Hollenbeck RDAP OpenID" using your favorite search engine. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics:

1;YTOPR01MB0396;27:E+eV2ZOSHNubNtVECuy/VM/L0xhmfXbZcuSQZbzTXSXqae7LUG8EA97rPf+2WwLbTntAgo7cpRKp5nw8d8T6ebvY8Vy/iFaEy7AJW3LXmiMa8o52Hh4X6vuxt8b9Dc+H X-Microsoft-Antispam-Message-Info:

mbIfSQV0+eZC39ENiUAspKdQkF0+JSTZwhHzgGzIJcnMTMtI1YFjxfAYUWl5x8Xsb0hCkvQc7VzC4AbTCpUbUGRQU6RcE5UUx1wEGk3WXKVvz27yXSf3osNfP8UwExDIUIL1xB46d04FaxAvbFZx3V7Y2ZVoGnlOF9jsJrXvgUSoJT4DsABV8smZdk4vNHRjunBYHmX/Uyc08KK5W5zM0fDRY7NEhuy8gp+3GzVz4A/5TqlICRbEqPiDy4iZWnOAaPiE4ELCAfZPmhMusibjqJno9CcaR04f9ovSYOL+LGRVBVtQ1M9b/SxTHtnAjl+ENjnGKfOC/j1+ryUspB55Z6d0P1zabIZYAwo87l1z4xMWzu3tmPExSwczo7sS129laKLyfrpQKQl6gt36u0ia78/RPd+UH+swgobcmXrp+pNPCIV60r6mKu9CLHxwfljZtI62wcXHykdzvBpIoyKjBQ==

_______________________________________________ ALAC mailing list <mailto:ALAC@atlarge-lists.icann.org>ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA... )

I forgot to add that we must comply with GDPR, and try to negotiate with Article 29 in Brussels to have a waiver for a few more months to finalize our interim model. ----------------------------------------------------------------------------- Tijani BEN JEMAA Executive Director Mediterranean Federation of Internet Associations (FMAI) Phone: +216 98 330 114 +216 52 385 114 -----------------------------------------------------------------------------

Le 17 avr. 2018 à 22:39, Holly Raiche <h.raiche@internode.on.net> a écrit :

Hi Alan

I am not disputing the ALAC’s rightful concern with making the DNS as safe and reliable as possible. But we need to do that in the legal framework we are given.

So yes, the model Scott explained does try to provide access to those entitled to access within a legal framework - both are important..

I do hope others comment because this is a very important discussion

Holly

On 18 Apr 2018, at 6:06 am, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>> wrote:

...

I said *I* would try to add some comments tonight. Add to what you had said (on Wiki now that it is there). Still hope to but time running out.

To be clear, it IS *OUR* job to make sure that the DNS is safe and reliable. That is our only job! Law enforcement, or anyone else that can justify their need can get data only if we first collect it.

But that is not relevant to the accreditation model as Scott says.

At 17/04/2018 07:13 AM, Holly Raiche wrote:

...

Hi Alan

When you say ‘we can add some comments tonight’ my questions are what comments? and add to what? There is no link on the policy page to the accreditation model.

And next - I’d have to differ on your views. Article 29 starts from basic privacy principles - as followed in over 100 countries around the globe with data protection regimes. First basic principle: only collect personal information that is necessary to do YOUR job. You don’t collect information you don’t need. Next principle: You tell the data subject why you need their personal information, and the circumstances in which that information will be shared. It is to THAT limited use and disclosure that people consent to giving their personal information. And it is in those LIMITED circumstances in which personal information is disclosed. The fact that others may want access is irrelevant.

So that right away limits who gets information - and in limited circumstances only.

In almost every data protection regime, law enforcement will be a circumstance in which personal information is made available. But again - not blanket permission, but in circumstances where there is a reasonable chance that illegal/harmful activity is or has taken place. And a further read suggests that access would also be given to Government/government authorised authorities as well. Two examples in Australia would be ASIC, our prudential regulator, and the ACCC, our competition and consumer watchdog. So the category of law enforcement probably extends to other regulatory/enforcement agencies - again, in situations where harm is suspected/occuring.

So - far from having an outstanding lack of knowledge about the Internet and ICANN, Article 29 know exactly what is going on. And it is what now amounts to unlawful release of personal information - and not just in the EU.

If there is to be any even slightly middle ground, it will be close to the model that Scott has already tested - access is possible, but to specific, accredited people and for specific situations. And it is in THAT context that the DNS will be protected. (and, as the cyber security advisor to our Prime Minister said, when asked how to make the Internet safe, replied that it isn’t possible to make it safe, only safer.)

Holly

On 17 Apr 2018, at 4:58 pm, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca> > wrote:

...

Holly I have been travelling and am ties up in meetings all day (Brussels time), but I hope to add some comments later tonight.

I caution care in interpreting the Article 29 letter. Despite some valid concerns, it shows an astounding lack of knowledge of the Internet and ICANN's mission. As a prime example is their advice to just focus on our own business and not that of others such as law enforcement or those combatting cyber issues. Our mission is to protect the DNS and that includes making it reliable and safe. But we do not have the ability to do that ourselves and thus must provide the tools for others to do that. If we fail, we are NOT carrying out our mission.

This will get more interesting in coming weeks.

Alan

At 16/04/2018 07:58 PM, Holly Raiche wrote:

...

Folks

We are fast running out of time to develop any kind of response to the accreditation model, even though the deadline for a response has been extended to this Friday. And in the interim, ICANN has received advice from Article 29 on the Interim model. (Article 29 is an advisory Group made up of a data protection authority from each EU member state). Their letter to ICANN, and Marby’s response, are on the home page of ICANN - and for those interested in the issue, I highly recommend reading both. Clearly, the implications of the Article 29 letter are that the Interim Model that we did comment on still raises concerns with them. Those concerns fall under the headings: Breadth of purpose - saying the proposed purposes are too widely drawn the link of purpose to processing - again, because the Whois data has been used does not qualify it as a purpose publication of the data must be linked to the original (and narrowly defined) purpose any access should be limited - not blanket access discussion about the length of retention of data discussion about the transfer of data Accreditation (particularly important in this context) - should only be for legitimate purpose, limited to the original purpose, not blanket access, and under limited conditions

Below, I have copied in an email from Scott Hollenbeck, a long standing member of ICANN and one of those involved in the development of the RDAP (access protocol that would allow gated access to registration data) - simply because he has been involved in this issue for a long time and shows he has already worked on a technical solution to this issue - how access to data could work under GDPR.

I will try to attend as much as possible of the capacity building webinar on this issue, but have been scheduled to attend an all-day course in the Sydney CBD so may have to miss some of the discussion. I imagine Tom will be very up to date on these issues, but I would like to have been attending the whole of the webinar myself

In any case, if at all possible, we should be saying something. Quite apart from the original contribution from the IPC/BC model, the NCSG and Registrars have also made comments (largely challenging the IPC/BC model). I hope we are the one constituency that doesn’t make comments - although I realise that agreement on what to say will be difficult at the best of times.

And if it isn’t too late - maybe put this issue on the ALAC policy page - and with it, links to the Article 29 letter, Marby’s response, the registrars’ response and the NCSG response (and any others I have missed - I have copies if that helps)

Holly

...

>> >> Hi all. >> >> After reading the Article 29 WP letter to ICANN >> ( awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby- <awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-> >> 11apr18-en.pdf), I started envisioning what process and system could >> achieve GDPR compliance. What I came to is a token-based system, which >> would work like this: >> - Every request is analyzed by a human at an "RDS Clearinghouse". Each >> request can be for a single data element (like "owner of domain X") or to >> multiple data elements (like "domains owned by the same owner of domain >> X"), but requests for multiple data elements are only foreseen to be >> processed by contracted parties with "Search WHOIS" contract requirements. >> - Clearinghouse issues a token with query parameters, data elements >> authorized for response, identity of authorized party, reason for >> authorization, validity (probably in the order of days), also informing >> which endpoint to go to. >> - Authorized party uses that token to access that endpoint, managed by the >> party with most data about that element (usually a registrar). >> >> Note that is not a replacement for credentialing; credentials would still >> be necessary to get tokens. This is also orthogonal to discussions like >> which use cases are legitimate or not, GDPR-compliant or not etc.; it's >> just a more granular approach to authorization that looks more inline with >> privacy-oriented guidelines including but not limited to GDPR. > > Rubens, at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.

Scott,

I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably could be made to work like this. And some level of asynchronous communications could even make way for a quick look human analysis.

Rubens

I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search for “draft Hollenbeck RDAP OpenID” using your favorite search engine. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics: 1;YTOPR01MB0396;27:E+eV2ZOSHNubNtVECuy/VM/L0xhmfXbZcuSQZbzTXSXqae7LUG8EA97rPf+2WwLbTntAgo7cpRKp5nw8d8T6ebvY8Vy/iFaEy7AJW3LXmiMa8o52Hh4X6vuxt8b9Dc+H X-Microsoft-Antispam-Message-Info: mbIfSQV0+eZC39ENiUAspKdQkF0+JSTZwhHzgGzIJcnMTMtI1YFjxfAYUWl5x8Xsb0hCkvQc7VzC4AbTCpUbUGRQU6RcE5UUx1wEGk3WXKVvz27yXSf3osNfP8UwExDIUIL1xB46d04FaxAvbFZx3V7Y2ZVoGnlOF9jsJrXvgUSoJT4DsABV8smZdk4vNHRjunBYHmX/Uyc08KK5W5zM0fDRY7NEhuy8gp+3GzVz4A/5TqlICRbEqPiDy4iZWnOAaPiE4ELCAfZPmhMusibjqJno9CcaR04f9ovSYOL+LGRVBVtQ1M9b/SxTHtnAjl+ENjnGKfOC/j1+ryUspB55Z6d0P1zabIZYAwo87l1z4xMWzu3tmPExSwczo7sS129laKLyfrpQKQl6gt36u0ia78/RPd+UH+swgobcmXrp+pNPCIV60r6mKu9CLHxwfljZtI62wcXHykdzvBpIoyKjBQ==

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org <mailto:ALAC@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/alac <https://atlarge-lists.icann.org/mailman/listinfo/alac>

At-Large Online: http://www.atlarge.icann.org <http://www.atlarge.icann.org/> ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA... <https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...> )

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)

Alan, Of course, we must ensure the safety and reliability of the DNS. Bute can you explain how collecting such huge amount of registrant data can make us sure that the DNS is safe and reliable? In case of unlawful harmful use, the registrar can immediately stop it, and this is true whatever the amount of data collected is. On the other hand, what you say is almost as if you say: since we know there will be criminals, we must surveil all the population so that we can catch anyone who will act badly. ----------------------------------------------------------------------------- Tijani BEN JEMAA Executive Director Mediterranean Federation of Internet Associations (FMAI) Phone: +216 98 330 114 +216 52 385 114 -----------------------------------------------------------------------------

Le 17 avr. 2018 à 21:06, Alan Greenberg <alan.greenberg@mcgill.ca> a écrit :

I said *I* would try to add some comments tonight. Add to what you had said (on Wiki now that it is there). Still hope to but time running out.

To be clear, it IS *OUR* job to make sure that the DNS is safe and reliable. That is our only job! Law enforcement, or anyone else that can justify their need can get data only if we first collect it.

But that is not relevant to the accreditation model as Scott says.

At 17/04/2018 07:13 AM, Holly Raiche wrote:

...

Hi Alan

When you say ‘we can add some comments tonight’ my questions are what comments? and add to what? There is no link on the policy page to the accreditation model.

And next - I’d have to differ on your views. Article 29 starts from basic privacy principles - as followed in over 100 countries around the globe with data protection regimes. First basic principle: only collect personal information that is necessary to do YOUR job. You don’t collect information you don’t need. Next principle: You tell the data subject why you need their personal information, and the circumstances in which that information will be shared. It is to THAT limited use and disclosure that people consent to giving their personal information. And it is in those LIMITED circumstances in which personal information is disclosed. The fact that others may want access is irrelevant.

So that right away limits who gets information - and in limited circumstances only.

In almost every data protection regime, law enforcement will be a circumstance in which personal information is made available. But again - not blanket permission, but in circumstances where there is a reasonable chance that illegal/harmful activity is or has taken place. And a further read suggests that access would also be given to Government/government authorised authorities as well. Two examples in Australia would be ASIC, our prudential regulator, and the ACCC, our competition and consumer watchdog. So the category of law enforcement probably extends to other regulatory/enforcement agencies - again, in situations where harm is suspected/occuring.

So - far from having an outstanding lack of knowledge about the Internet and ICANN, Article 29 know exactly what is going on. And it is what now amounts to unlawful release of personal information - and not just in the EU.

If there is to be any even slightly middle ground, it will be close to the model that Scott has already tested - access is possible, but to specific, accredited people and for specific situations. And it is in THAT context that the DNS will be protected. (and, as the cyber security advisor to our Prime Minister said, when asked how to make the Internet safe, replied that it isn’t possible to make it safe, only safer.)

Holly

On 17 Apr 2018, at 4:58 pm, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca> > wrote:

...

Holly I have been travelling and am ties up in meetings all day (Brussels time), but I hope to add some comments later tonight.

I caution care in interpreting the Article 29 letter. Despite some valid concerns, it shows an astounding lack of knowledge of the Internet and ICANN's mission. As a prime example is their advice to just focus on our own business and not that of others such as law enforcement or those combatting cyber issues. Our mission is to protect the DNS and that includes making it reliable and safe. But we do not have the ability to do that ourselves and thus must provide the tools for others to do that. If we fail, we are NOT carrying out our mission.

This will get more interesting in coming weeks.

Alan

At 16/04/2018 07:58 PM, Holly Raiche wrote:

...

Folks

We are fast running out of time to develop any kind of response to the accreditation model, even though the deadline for a response has been extended to this Friday. And in the interim, ICANN has received advice from Article 29 on the Interim model. (Article 29 is an advisory Group made up of a data protection authority from each EU member state). Their letter to ICANN, and Marby’s response, are on the home page of ICANN - and for those interested in the issue, I highly recommend reading both. Clearly, the implications of the Article 29 letter are that the Interim Model that we did comment on still raises concerns with them. Those concerns fall under the headings: Breadth of purpose - saying the proposed purposes are too widely drawn the link of purpose to processing - again, because the Whois data has been used does not qualify it as a purpose publication of the data must be linked to the original (and narrowly defined) purpose any access should be limited - not blanket access discussion about the length of retention of data discussion about the transfer of data Accreditation (particularly important in this context) - should only be for legitimate purpose, limited to the original purpose, not blanket access, and under limited conditions

Below, I have copied in an email from Scott Hollenbeck, a long standing member of ICANN and one of those involved in the development of the RDAP (access protocol that would allow gated access to registration data) - simply because he has been involved in this issue for a long time and shows he has already worked on a technical solution to this issue - how access to data could work under GDPR.

I will try to attend as much as possible of the capacity building webinar on this issue, but have been scheduled to attend an all-day course in the Sydney CBD so may have to miss some of the discussion. I imagine Tom will be very up to date on these issues, but I would like to have been attending the whole of the webinar myself

In any case, if at all possible, we should be saying something. Quite apart from the original contribution from the IPC/BC model, the NCSG and Registrars have also made comments (largely challenging the IPC/BC model). I hope we are the one constituency that doesn’t make comments - although I realise that agreement on what to say will be difficult at the best of times.

And if it isn’t too late - maybe put this issue on the ALAC policy page - and with it, links to the Article 29 letter, Marby’s response, the registrars’ response and the NCSG response (and any others I have missed - I have copies if that helps)

Holly

...

...

> > Hi all. > > After reading the Article 29 WP letter to ICANN > ( awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby- <awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-> > 11apr18-en.pdf), I started envisioning what process and system could > achieve GDPR compliance. What I came to is a token-based system, which > would work like this: > - Every request is analyzed by a human at an "RDS Clearinghouse". Each > request can be for a single data element (like "owner of domain X") or to > multiple data elements (like "domains owned by the same owner of domain > X"), but requests for multiple data elements are only foreseen to be > processed by contracted parties with "Search WHOIS" contract requirements. > - Clearinghouse issues a token with query parameters, data elements > authorized for response, identity of authorized party, reason for > authorization, validity (probably in the order of days), also informing > which endpoint to go to. > - Authorized party uses that token to access that endpoint, managed by the > party with most data about that element (usually a registrar). > > Note that is not a replacement for credentialing; credentials would still > be necessary to get tokens. This is also orthogonal to discussions like > which use cases are legitimate or not, GDPR-compliant or not etc.; it's > just a more granular approach to authorization that looks more inline with > privacy-oriented guidelines including but not limited to GDPR.

Rubens, at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.

Scott,

I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably could be made to work like this. And some level of asynchronous communications could even make way for a quick look human analysis.

Rubens

I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search for “draft Hollenbeck RDAP OpenID” using your favorite search engine. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics: 1;YTOPR01MB0396;27:E+eV2ZOSHNubNtVECuy/VM/L0xhmfXbZcuSQZbzTXSXqae7LUG8EA97rPf+2WwLbTntAgo7cpRKp5nw8d8T6ebvY8Vy/iFaEy7AJW3LXmiMa8o52Hh4X6vuxt8b9Dc+H X-Microsoft-Antispam-Message-Info: mbIfSQV0+eZC39ENiUAspKdQkF0+JSTZwhHzgGzIJcnMTMtI1YFjxfAYUWl5x8Xsb0hCkvQc7VzC4AbTCpUbUGRQU6RcE5UUx1wEGk3WXKVvz27yXSf3osNfP8UwExDIUIL1xB46d04FaxAvbFZx3V7Y2ZVoGnlOF9jsJrXvgUSoJT4DsABV8smZdk4vNHRjunBYHmX/Uyc08KK5W5zM0fDRY7NEhuy8gp+3GzVz4A/5TqlICRbEqPiDy4iZWnOAaPiE4ELCAfZPmhMusibjqJno9CcaR04f9ovSYOL+LGRVBVtQ1M9b/SxTHtnAjl+ENjnGKfOC/j1+ryUspB55Z6d0P1zabIZYAwo87l1z4xMWzu3tmPExSwczo7sS129laKLyfrpQKQl6gt36u0ia78/RPd+UH+swgobcmXrp+pNPCIV60r6mKu9CLHxwfljZtI62wcXHykdzvBpIoyKjBQ==

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org <mailto:ALAC@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/alac <https://atlarge-lists.icann.org/mailman/listinfo/alac>

At-Large Online: http://www.atlarge.icann.org <http://www.atlarge.icann.org/> ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA... <https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...> )

---

ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)

It's not possible to make the issue simple. But always good to go back to the basics. 1. Registrant need an anchor, very solid data to make sure domain is recognizable as an asset of the registrant to do the job: delegate, change technical data, transfer, pay, etc. This might be personal data (such as ID or passport or combination of properties); 2. Registrar binds to registrant solid data to make sure domain is under registrant control and thing works. Technically, there is no need for registrar to keep all personal data (and WHOIS it) to maintain its operations, but only portion which says it is registrant's domain. But this is registrant-registrar relations, it's not public WHOIS issue. The trust for this pair can be done via keys for example or chain of blocks :) 3. Registry takes care of the domain name hierarchy and keeps some of the registrant technical data to make sure domain name is running. Also there are tools to keep domain name with registrant if registrar fails. There is no need to keep personal data (and WHOIS it). 1, 2 and 3 trust the jurisdiction (ID, passport, credit card) registrant belongs to, only for the reason to do administrative things with domain names. A. There are governments, they need to know the "owner" of the domain name for many reasons. They do need to know the personal data and some kind of tool to dig down to the owner (lets assume it is WHOIS). They also have enforcement tools to get it (lets assume there is no problem with international user data transfer); B. There are legal guys in some jurisdictions trying to get a digging tool to keep their legal properties under control (lets assume it is WHOIS). But this won't work in many jurisdictions, so they have a path through point (A); C. There are collective EU bureaucrats taking care of the privacy issues, trying to make sure personal data of the European registrants is protected from the bad guys. Those guys look like a superuser with an assumption everybody around are the bad guys. D. There are new players on the legal market, like this "article" whatever, balancing between 1, 2, 3, A, B and C. Lets say good luck for those guys. As I see a combination of the issues from the end user point of view (the guy with personal data): it is not AtLarge role to make sure A, B and C are happy with whatever legal version of digital divide achieved. We must maintain our focus to a simple things: user can register and run domain, transfer it, pay, change NSes, etc. There is risk that end user's life will be more complicated, because there will be new stuff in a simple process of registering and running the domain name. Lets focus on this. --andrei 2018-04-17 20:06 GMT+00:00 Alan Greenberg <alan.greenberg@mcgill.ca>:

I said *I* would try to add some comments tonight. Add to what you had said (on Wiki now that it is there). Still hope to but time running out.

To be clear, it IS *OUR* job to make sure that the DNS is safe and reliable. That is our only job! Law enforcement, or anyone else that can justify their need can get data only if we first collect it.

But that is not relevant to the accreditation model as Scott says.

At 17/04/2018 07:13 AM, Holly Raiche wrote:

Hi Alan

When you say ‘we can add some comments tonight’ my questions are

- what comments? - and add to what?

There is no link on the policy page to the accreditation model.

And next - I’d have to differ on your views. Article 29 starts from basic privacy principles - as followed in over 100 countries around the globe with data protection regimes. First basic principle: only collect personal information that is necessary to do YOUR job. You don’t collect information you don’t need. Next principle: You tell the data subject why you need their personal information, and the circumstances in which that information will be shared. It is to THAT limited use and disclosure that people consent to giving their personal information. And it is in those LIMITED circumstances in which personal information is disclosed. The fact that others may want access is irrelevant.

So that right away limits who gets information - and in limited circumstances only.

In almost every data protection regime, law enforcement will be a circumstance in which personal information is made available. But again - not blanket permission, but in circumstances where there is a reasonable chance that illegal/harmful activity is or has taken place. And a further read suggests that access would also be given to Government/government authorised authorities as well. Two examples in Australia would be ASIC, our prudential regulator, and the ACCC, our competition and consumer watchdog. So the category of law enforcement probably extends to other regulatory/enforcement agencies - again, in situations where harm is suspected/occuring.

So - far from having an outstanding lack of knowledge about the Internet and ICANN, Article 29 know exactly what is going on. And it is what now amounts to unlawful release of personal information - and not just in the EU.

If there is to be any even slightly middle ground, it will be close to the model that Scott has already tested - access is possible, but to specific, accredited people and for specific situations. And it is in THAT context that the DNS will be protected. (and, as the cyber security advisor to our Prime Minister said, when asked how to make the Internet safe, replied that it isn’t possible to make it safe, only safer.)

Holly

On 17 Apr 2018, at 4:58 pm, Alan Greenberg <alan.greenberg@mcgill.ca > wrote:

Holly I have been travelling and am ties up in meetings all day (Brussels time), but I hope to add some comments later tonight.

I caution care in interpreting the Article 29 letter. Despite some valid concerns, it shows an astounding lack of knowledge of the Internet and ICANN's mission. As a prime example is their advice to just focus on our own business and not that of others such as law enforcement or those combatting cyber issues. Our mission is to protect the DNS and that includes making it reliable and safe. But we do not have the ability to do that ourselves and thus must provide the tools for others to do that. If we fail, we are NOT carrying out our mission.

This will get more interesting in coming weeks.

Alan

At 16/04/2018 07:58 PM, Holly Raiche wrote:

Folks

We are fast running out of time to develop any kind of response to the accreditation model, even though the deadline for a response has been extended to this Friday. And in the interim, ICANN has received advice from Article 29 on the Interim model. (Article 29 is an advisory Group made up of a data protection authority from each EU member state). Their letter to ICANN, and Marby’s response, are on the home page of ICANN - and for those interested in the issue, I highly recommend reading both. Clearly, the implications of the Article 29 letter are that the Interim Model that we did comment on still raises concerns with them. Those concerns fall under the headings:

- Breadth of purpose - saying the proposed purposes are too widely drawn - the link of purpose to processing - again, because the Whois data has been used does not qualify it as a purpose - publication of the data must be linked to the original (and narrowly defined) purpose - any access should be limited - not blanket access - discussion about the length of retention of data - discussion about the transfer of data - Accreditation (particularly important in this context) - should only be for legitimate purpose, limited to the original purpose, not blanket access, and under limited conditions

Below, I have copied in an email from Scott Hollenbeck, a long standing member of ICANN and one of those involved in the development of the RDAP (access protocol that would allow gated access to registration data) - simply because he has been involved in this issue for a long time and shows he has already worked on a technical solution to this issue - how access to data could work under GDPR.

I will try to attend as much as possible of the capacity building webinar on this issue, but have been scheduled to attend an all-day course in the Sydney CBD so may have to miss some of the discussion. I imagine Tom will be very up to date on these issues, but I would like to have been attending the whole of the webinar myself

In any case, if at all possible, we should be saying something. Quite apart from the original contribution from the IPC/BC model, the NCSG and Registrars have also made comments (largely challenging the IPC/BC model). I hope we are the one constituency that doesn’t make comments - although I realise that agreement on what to say will be difficult at the best of times.

And if it isn’t too late - maybe put this issue on the ALAC policy page - and with it, links to the Article 29 letter, Marby’s response, the registrars’ response and the NCSG response (and any others I have missed - I have copies if that helps)

Holly

Hi all.

After reading the Article 29 WP letter to ICANN ( awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby- 11apr18-en.pdf), I started envisioning what process and system could achieve GDPR compliance. What I came to is a token-based system, which would work like this: - Every request is analyzed by a human at an "RDS Clearinghouse". Each request can be for a single data element (like "owner of domain X") or to multiple data elements (like "domains owned by the same owner of domain X"), but requests for multiple data elements are only foreseen to be processed by contracted parties with "Search WHOIS" contract requirements. - Clearinghouse issues a token with query parameters, data elements authorized for response, identity of authorized party, reason for authorization, validity (probably in the order of days), also informing which endpoint to go to. - Authorized party uses that token to access that endpoint, managed by the party with most data about that element (usually a registrar).

Note that is not a replacement for credentialing; credentials would still be necessary to get tokens. This is also orthogonal to discussions like which use cases are legitimate or not, GDPR-compliant or not etc.; it's just a more granular approach to authorization that looks more inline with privacy-oriented guidelines including but not limited to GDPR.

Rubens, at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.

Scott,

I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably could be made to work like this. And some level of asynchronous communications could even make way for a quick look human analysis.

Rubens

I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search for “draft Hollenbeck RDAP OpenID” using your favorite search engine. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics: 1;YTOPR01MB0396;27:E+eV2ZOSHNubNtVECuy/VM/ L0xhmfXbZcuSQZbzTXSXqae7LUG8EA97rPf+2WwLbTntAgo7cpRKp5nw8d8T6ebvY8Vy/ iFaEy7AJW3LXmiMa8o52Hh4X6vuxt8b9Dc+H X-Microsoft-Antispam-Message-Info: mbIfSQV0+eZC39ENiUAspKdQkF0+JSTZwhHzgGzIJcnMTMtI1YFjxfAYUW l5x8Xsb0hCkvQc7VzC4AbTCpUbUGRQU6RcE5UUx1wEGk3WXKVvz27yXSf3os NfP8UwExDIUIL1xB46d04FaxAvbFZx3V7Y2ZVoGnlOF9jsJrXvgUSoJT4DsA BV8smZdk4vNHRjunBYHmX/Uyc08KK5W5zM0fDRY7NEhuy8gp+3GzVz4A/ 5TqlICRbEqPiDy4iZWnOAaPiE4ELCAfZPmhMusibjqJno9CcaR04f9ovSYOL +LGRVBVtQ1M9b/SxTHtnAjl+ENjnGKfOC/j1+ryUspB55Z6d0P1zabIZYAwo87l1z4x MWzu3tmPExSwczo7sS129laKLyfrpQKQl6gt36u0ia78/RPd+UH+swgobcmXrp+ pNPCIV60r6mKu9CLHxwfljZtI62wcXHykdzvBpIoyKjBQ==

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+ Advisory+Committee+(ALAC )

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+ Advisory+Committee+(ALAC)

-- Andrey Kolesnikov RIPN.NET

Agreed - thank Carlton And yes, this is all early too late, but then nothing they have said hasn’t been said before - if anyone was listening. Holly On 17 Apr 2018, at 6:26 pm, Carlton Samuels <carlton.samuels@gmail.com> wrote:

In my own view the expectations by ICANN from the request to Article 29 WP folks presaged either a woeful misunderstanding of the role/function of the Article 29 WP in the EU/EC framework or the first move in a fiendishly clever ploy to get them on record for purpose.

Because quite frankly, them fellas didn't say anything that a moderately sentient observer that is conversant with the issues and have some time in place could not have anticipated.

-Carlton

============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround =============================

On Mon, Apr 16, 2018 at 6:58 PM, Holly Raiche <h.raiche@internode.on.net> wrote: Folks

We are fast running out of time to develop any kind of response to the accreditation model, even though the deadline for a response has been extended to this Friday. And in the interim, ICANN has received advice from Article 29 on the Interim model. (Article 29 is an advisory Group made up of a data protection authority from each EU member state). Their letter to ICANN, and Marby’s response, are on the home page of ICANN - and for those interested in the issue, I highly recommend reading both. Clearly, the implications of the Article 29 letter are that the Interim Model that we did comment on still raises concerns with them. Those concerns fall under the headings: Breadth of purpose - saying the proposed purposes are too widely drawn the link of purpose to processing - again, because the Whois data has been used does not qualify it as a purpose publication of the data must be linked to the original (and narrowly defined) purpose any access should be limited - not blanket access discussion about the length of retention of data discussion about the transfer of data Accreditation (particularly important in this context) - should only be for legitimate purpose, limited to the original purpose, not blanket access, and under limited conditions

Below, I have copied in an email from Scott Hollenbeck, a long standing member of ICANN and one of those involved in the development of the RDAP (access protocol that would allow gated access to registration data) - simply because he has been involved in this issue for a long time and shows he has already worked on a technical solution to this issue - how access to data could work under GDPR.

I will try to attend as much as possible of the capacity building webinar on this issue, but have been scheduled to attend an all-day course in the Sydney CBD so may have to miss some of the discussion. I imagine Tom will be very up to date on these issues, but I would like to have been attending the whole of the webinar myself

In any case, if at all possible, we should be saying something. Quite apart from the original contribution from the IPC/BC model, the NCSG and Registrars have also made comments (largely challenging the IPC/BC model). I hope we are the one constituency that doesn’t make comments - although I realise that agreement on what to say will be difficult at the best of times.

And if it isn’t too late - maybe put this issue on the ALAC policy page - and with it, links to the Article 29 letter, Marby’s response, the registrars’ response and the NCSG response (and any others I have missed - I have copies if that helps)

Holly

...

...

...

Hi all.

After reading the Article 29 WP letter to ICANN (awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby- 11apr18-en.pdf), I started envisioning what process and system could achieve GDPR compliance. What I came to is a token-based system, which would work like this: - Every request is analyzed by a human at an "RDS Clearinghouse". Each request can be for a single data element (like "owner of domain X") or to multiple data elements (like "domains owned by the same owner of domain X"), but requests for multiple data elements are only foreseen to be processed by contracted parties with "Search WHOIS" contract requirements. - Clearinghouse issues a token with query parameters, data elements authorized for response, identity of authorized party, reason for authorization, validity (probably in the order of days), also informing which endpoint to go to. - Authorized party uses that token to access that endpoint, managed by the party with most data about that element (usually a registrar).

Note that is not a replacement for credentialing; credentials would still be necessary to get tokens. This is also orthogonal to discussions like which use cases are legitimate or not, GDPR-compliant or not etc.; it's just a more granular approach to authorization that looks more inline with privacy-oriented guidelines including but not limited to GDPR.

Rubens, at a high level you just described how OpenID and OAuth work, except for the "Every request is analyzed by a human" part.

Scott,

I believe you are right, although most OAuth models I saw were not that granular to the point of saying "example.TLD, owner, e-mail address, valid until April 20 2018". That's not an OAuth limitation though, just common usage, and it probably could be made to work like this. And some level of asynchronous communications could even make way for a quick look human analysis.

Rubens

I have this very model, with human involvement, up and running right now as part of the gTLD RDAP Pilot. All of the attributes you mentioned can be encoded as OAuth claims. The model is described in an Internet-Draft that I first wrote in 2015. Just search for “draft Hollenbeck RDAP OpenID” using your favorite search engine.

_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac

At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)