I think we all agreed earlier that there would not be a cut-off line for new documents. Especially with a long PDP such as this one, we can expect things in the real world to change, and we should take note of such changes in our work to ensure we remain current. Best, Volker Am 15.07.2016 um 14:42 schrieb h.raiche@internode.on.net:

A really big plus one for Andrew.

I share concerns wth those who question whether the place to start is with uses. It implicitly assumes that all of the current 'uses' of the information should continue. General data protection law strongly suggests otherwise.

However, we are starting with uses - and as long as everyone realises that the current uses of the data will not be permitted under data protection law, then let's proceed. And yes, we will come down to Andrew's fundamental question - what personal information that is collection should be accessible to all - OR NOT. And, in the end, I am not sure how much more information we need. From my perspective, I know I will not have time to read all of what is on the list already, let alone new stuff. So maybe let's focus on the information identified in public comment as the critical information for this issue and start talking about uses - what of the uses should be maintained, and what - for strong data protection reasons - should not.

Holly

----- Original Message ----- From: "Andrew Sullivan" <ajs@anvilwalrusden.com>

To: <gnso-rds-pdp-wg@icann.org> Cc:

Sent: Fri, 15 Jul 2016 08:10:25 -0400 Subject: [gnso-rds-pdp-wg] The overflowing list (was Re: A new and rather important document with respect to jurisdiction issues)

On Thu, Jul 14, 2016 at 11:32:13PM -0400, Stephanie Perrin wrote: > May I suggest that we add it to our already overflowing list of important > documents?

I don't object, but I'm wondering whether there is really anything new in most of the additional documents people are bringing.

It seems to me that we have a fundamental question we're going to have to answer. I know that we've decided that now is not the time for deliberation, so I don't encourage discussion about this question. But I'm decreasingly convinced that more material is going to help us come to any decision about balancing the desire of some, on one side, to have a lot of personally identifying information about domain name registrants; and the desire of others to ensure that such personally identifying information is protected on privacy grounds.

We can probably continue to find additional examples of people insisting they need one or the other of these, but I do not really see any way that more evidence that someone really really wants one of them (with all the attendant arguments rehearsed) is going to help us come to a conclusion.

Best regards,

A

-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

My apologies if I sounded as if I want to cut off new documentation.  But as Greg says - and I agree, noone will read every word of every document.  But of course, if there are new developments that impinge of what we are doing, we need to be aware of that. And of course, we are well before decising who has access to what data and on what terms.  The EWG started that discussion. And it is a discussion that must be continued.  So Greg and others: I think it is safe to say that data protection laws do apply and will call into question what data is collected, how it is used, and who has access.  True - we haven't even started that discussion, so it is premature to say what data will or won't be collected and/or accessed.  But it is also safe to say that the current arrangements will be under discussion and debate. Holly ----- Original Message ----- From: "Greg Shatan" To:"Volker Greimann" Cc:"RDS PDP WG" Sent:Fri, 15 Jul 2016 10:45:03 -0400 Subject:Re: [gnso-rds-pdp-wg] The overflowing list (was Re: A new and rather important document with respect to jurisdiction issues) I agree with Volker on this one -- there should be no cut-off date.  More generally, we should stick with the working methods we've agreed to, rather than (repeatedly) re-opening them for discussion, except under truly exceptional circumstances.  That  In response to Holly, the reason we are distilling and extracting information from these resources is intended to deal with the fact that no one will read every word of every document.  I would also resist the urge to focus largely on comments. They are certainly important, but the resource-gathering mission is intended to broaden our horizons beyond the somewhat self-contained world of commenters.  Finally, I would say that it is highly conclusory, premature and just plain wrong to flatly claim "that the current uses of the data will not be permitted under data protection law,"  Even laws against murder have exceptions....  I'll adhere to my own admonition to stick to our working methods and save further discussion on that point for the appropriate phase of our work. Greg On Fri, Jul 15, 2016 at 8:46 AM, Volker Greimann wrote: I think we all agreed earlier that there would not be a cut-off line for new documents. Especially with a long PDP such as this one, we can expect things in the real world to change, and we should take note of such changes in our work to ensure we remain current. Best, Volker Am 15.07.2016 um 14:42 schrieb h.raiche@internode.on.net [2]: A really big plus one for Andrew. I share concerns wth those who question whether the place to start is with uses.  It implicitly assumes that all of the current 'uses' of the information should continue.  General data protection law strongly suggests otherwise. However, we are starting with uses - and as long as everyone realises that the current uses of the data will not be permitted under data protection law, then let's proceed.  And yes, we will come down to Andrew's fundamental question - what personal information that is collection should be accessible to all - OR NOT.  And, in the end, I am not sure how much more information we need.  From my perspective, I know I will not have time to read all of what is on the list already, let alone new stuff.  So  maybe let's focus on the information identified in public comment as the critical information for this issue and start talking about uses - what of the uses should be maintained, and what - for strong data protection reasons - should not. Holly ----- Original Message ----- From: "Andrew Sullivan" [3] To: [4] Cc: Sent: Fri, 15 Jul 2016 08:10:25 -0400 Subject: [gnso-rds-pdp-wg] The overflowing list (was Re: A new and rather important document with respect to jurisdiction issues) On Thu, Jul 14, 2016 at 11:32:13PM -0400, Stephanie Perrin wrote:

May I suggest that we add it to our already overflowing list of important documents?

I don't object, but I'm wondering whether there is really anything new in most of the additional documents people are bringing. It seems to me that we have a fundamental question we're going to have to answer. I know that we've decided that now is not the time for deliberation, so I don't encourage discussion about this question. But I'm decreasingly convinced that more material is going to help us come to any decision about balancing the desire of some, on one side, to have a lot of personally identifying information about domain name registrants; and the desire of others to ensure that such personally identifying information is protected on privacy grounds. We can probably continue to find additional examples of people insisting they need one or the other of these, but I do not really see any way that more evidence that someone really really wants one of them (with all the attendant arguments rehearsed) is going to help us come to a conclusion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com [5] _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org [6] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [7] _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org [8] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [9] -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net [10] Web: www.key-systems.net [11] / www.RRPproxy.net [12] www.domaindiscount24com [13] / www.BrandShelter.com [14] Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems [15] www.twitter.com/key_systems [16] Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu [17] Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net [18] Web: www.key-systems.net [19] / www.RRPproxy.net [20] www.domaindiscount24.com [21] / www.BrandShelter.com [22] Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems [23] www.twitter.com/key_systems [24] CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu [25] This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org [26] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [27] Links: ------ [1] mailto:vgreimann@key-systems.net [2] mailto:h.raiche@internode.on.net [3] mailto:ajs@anvilwalrusden.com [4] mailto:gnso-rds-pdp-wg@icann.org [5] mailto:ajs@anvilwalrusden.com [6] mailto:gnso-rds-pdp-wg@icann.org [7] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [8] mailto:gnso-rds-pdp-wg@icann.org [9] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg [10] mailto:vgreimann@key-systems.net [11] http://www.key-systems.net [12] http://www.RRPproxy.net [13] http://www.domaindiscount24.com [14] http://www.BrandShelter.com [15] http://www.facebook.com/KeySystems [16] http://www.twitter.com/key_systems [17] http://www.keydrive.lu [18] mailto:vgreimann@key-systems.net [19] http://www.key-systems.net [20] http://www.RRPproxy.net [21] http://www.domaindiscount24.com [22] http://www.BrandShelter.com [23] http://www.facebook.com/KeySystems [24] http://www.twitter.com/key_systems [25] http://www.keydrive.lu [26] mailto:gnso-rds-pdp-wg@icann.org [27] https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

On Fri, Jul 15, 2016 at 02:46:10PM +0200, Volker Greimann wrote:

I think we all agreed earlier that there would not be a cut-off line for new documents.

I, at least, was not advocating a cut-off. I was more pleading that, when people offer new things that are supposed to offer some new perspective, that there actually be some new perspective there. A great deal of the material that I've read so far is mostly the same things over and over. I hardly see how that helps us narrow the use cases or figure out what the right thing to do is. It won't do to try to argue from the size of the stack of reports arguing for one view or the other. I think Chuck's suggestion is a good one: if you add something new to the pile, it'd be helpful to say what's new about it apart from the authors. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

Thanks, Stephanie, for the quick issue list. There's one thing that I want to draw out here so that we can keep it foremost when thinking of issues: On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote:

* Where the RDS (whether a central database or federated or completely disaggregated) resides becomes important for law enforcement access.

This "where data resides" issue is bound to vex us, no matter what kind of policy we come up with. But it's really important to keep in mind that the different styles of system design will yield very different properties. In the taxonomy I offered before (http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html), models I and V have a clear since answer to, "Where does the data reside?" because they have a single database backing them up. In models II-IV, however, the answer to, "Where does the data reside?" is actually not entirely meaningful. There are multiple places where the data are, and for data with respect to any given domain name each datum might be in a different place. (Indeed, part of the design of RDAP is precisely to make such arrangements easier to deal with.) It is therefore better to try to find a way, consistent with all of the various requirements documents, to answer some other questions. I think these might be helpful in building use cases: 1. For any given datum, who has control of and access to the datum? 2. For any given datum, what are the conditions under which the datum ought to be accessible? 3. For any given set of related data, how can it be accessed? Notice that answering (3) will provides use cases for data access, whereas (1) and (2) provide for limit conditions on how and when use cases might be apply. I hope these framing questions are helpful in figuring out which use cases we can bring to bear on requirements. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

On Sat, Jul 16, 2016 at 01:12:30AM -0400, Stephanie Perrin wrote:

images of video tapes that have not been used in 15 years). To be clear, we need to talk about control of data elements.

I agree (these are the same as "datum" in the questions I asked -- the individual elements of a set of data).

If I understand RDAP correctly, it would permit duly authorized data access from anywhere, to elements that could be scattered.

In principle, it could.

current data mining techniques. The problem, as I see it, and I beg to be corrected if I am wrong, is how do we manage a remote authorization scheme to individual data elements, if indeed some data is held by the registrar, some by the registry, and some (outside ICANN's remit, but an answer to LEA demands) by the ISP?

This is a great question. RDAP itself does not actually answer this, because RDAP just uses http(s). The idea in the design was exactly that we could then re-use any authentication and authorization mechanisms that http(s) offers, and so if a new one was invented we'd get that benefit too. (All good designs proceed from a basic laziness: don't re-invent something if you can just re-use something others have already got working.) The initial answer is just basic http authentication, and that would require each to-be-authenticated individual to get such authentication logins with everyone providing RDS, which would be awful. So that's not actually the plan. Scott Hollenbeck, who is participating in this WG, has a nice draft that'll probably see some discussion at the IETF meeting in Berlin next week (https://tools.ietf.org/html/draft-hollenbeck-regext-rdap-openid-00#ref-OIDCC). It's a way of using RDAP with OpenID Connect, which is a federated authentication and authorization mechanism. (It's really intended to provide an identity layer on top of OAuth.) I'm waving away some details and distinctions, but this is the sort of thing that you use when you "sign in using Facebook" or "sign in using Google" or whatever. Using this sort of thing, you could have one credential that various RDS operators would accept. Once you're authenticated, the credential would continue to work across referrals from one RDS to another (using RDAP), so that the _user_ experience is of a single monolithic system while the _technical_ operation is of a distributed system. Moreover, individual RDS operators could use different policies based on local law to provide the kinds of responses appropriate to the legal conditions under which they operate. This would of course mean that registrations in some jurisdictions might release more information than others, but that's consistent with the legal obligations and norms that arise from having multiple jurisdictions in the first place. Now, there are important details in the operation of any such federated identity system, and questions we'd have to ask about how the vetting process for identification would work and whether we'd need multiple additional tokens (for instance, an identity presented with an id of a subpoena might have different qualifications than an identity without such a subpoena). That's all policy that would need to be developed, but it would all be policy that could avoid specifying details of technical implementations, which would be an improvement over historic whois policy :) If any of that is not clear, or if we need to develop some more detailed tutorial-like info for participants here to read offline or something, I hope people will let me know. We really do now have the technlogy to enable quite fine policy distinctions, and I think that basic fact is useful for our future deliberations. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

Hi Andrew, my concern with re-using the mechaisms offered by http(s) is that to my knowledge it does not support differentiated or tiered access. So once you have access to a certain level of information, the protocol does not care what you use that access for. Say I am a Turkish "law enforcement official" (whatever that means in these days) and have access to certain data fields because we decided that this is the level of access given to law enforcement. I can now access this level of information for anything. So we need not only authentication, but also protection from abuse of such authenticated users. We need granulatity to be able to not only to say that user A has access to information level B, but also ensure that this information can only be requested for purpose C and prevent any access to the same information for abusive use D. If for example law enforcement has the ability to access certain information based on a court order, we would have to ensure that this access level can only be used if such a court order is present, otherwise how to shoield users from abuse of the access we grant by policy? I hope we will get to ask these questions further down the road and find a workable solution to them. In the meantime, I just wanted to note that authentication is not the solution, but only a step on the way towards the solution. The solution must be broader. Best, Volker

This is a great question.

RDAP itself does not actually answer this, because RDAP just uses http(s). The idea in the design was exactly that we could then re-use any authentication and authorization mechanisms that http(s) offers, and so if a new one was invented we'd get that benefit too. (All good designs proceed from a basic laziness: don't re-invent something if you can just re-use something others have already got working.)

The initial answer is just basic http authentication, and that would require each to-be-authenticated individual to get such authentication logins with everyone providing RDS, which would be awful. So that's not actually the plan.

Scott Hollenbeck, who is participating in this WG, has a nice draft that'll probably see some discussion at the IETF meeting in Berlin next week (https://tools.ietf.org/html/draft-hollenbeck-regext-rdap-openid-00#ref-OIDCC). It's a way of using RDAP with OpenID Connect, which is a federated authentication and authorization mechanism. (It's really intended to provide an identity layer on top of OAuth.) I'm waving away some details and distinctions, but this is the sort of thing that you use when you "sign in using Facebook" or "sign in using Google" or whatever.

Using this sort of thing, you could have one credential that various RDS operators would accept. Once you're authenticated, the credential would continue to work across referrals from one RDS to another (using RDAP), so that the _user_ experience is of a single monolithic system while the _technical_ operation is of a distributed system. Moreover, individual RDS operators could use different policies based on local law to provide the kinds of responses appropriate to the legal conditions under which they operate. This would of course mean that registrations in some jurisdictions might release more information than others, but that's consistent with the legal obligations and norms that arise from having multiple jurisdictions in the first place.

Now, there are important details in the operation of any such federated identity system, and questions we'd have to ask about how the vetting process for identification would work and whether we'd need multiple additional tokens (for instance, an identity presented with an id of a subpoena might have different qualifications than an identity without such a subpoena). That's all policy that would need to be developed, but it would all be policy that could avoid specifying details of technical implementations, which would be an improvement over historic whois policy :)

If any of that is not clear, or if we need to develop some more detailed tutorial-like info for participants here to read offline or something, I hope people will let me know. We really do now have the technlogy to enable quite fine policy distinctions, and I think that basic fact is useful for our future deliberations.

Best regards,

A

-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote:

my concern with re-using the mechaisms offered by http(s) is that to my knowledge it does not support differentiated or tiered access.

I'm not sure this attends to how the layers work in this protocol. Https in the case of RDAP is just the protocol by which you carry the bits. RDAP is an application protocol. So https provides the TLS-based authentication mechanism of the accessing application. Once you have the TLS credential, your RDAP server is in a position to examine the presented credentials and make a decision about what data to return. This is part of the RDAP server application. But RDAP has the capability to do that _built in_ by virtue of having access to authentication credentials that are not available as part of the whois protocol.

Say I am a Turkish "law enforcement official" (whatever that means in these days) and have access to certain data fields because we decided that this is the level of access given to law enforcement. I can now access this level of information for anything. So we need not only authentication, but also protection from abuse of such authenticated users. We need granulatity to be able to not only to say that user A has access to information level B, but also ensure that this information can only be requested for purpose C and prevent any access to the same information for abusive use D.

I think this conflates policies that are amenable to technical imposition, and policies that are not. For a given authenticated user, that authenticated user has access to certain data. The data fields in question are available to the user, and other data fields are not. That's something that can be imposed technically: for any login that meets the same profile, the restrictions in question yield the same access controls. There is literally nothing technically possible to do about someone using data they obtain this way for purposes for which the data were not intended. It may be that ICANN ought to have additional policies about what happens if someone uses data outside the scope that the data was supposed to be used -- the classic example is people using privileged information access to dig up info on former romantic partners. Normally, the way we solve that is that we fire people who abuse their credentials when we catch them. So, ICANN could have a policy about suspending credentials, similarly.

If for example law enforcement has the ability to access certain information based on a court order, we would have to ensure that this access level can only be used if such a court order is present, otherwise how to shoield users from abuse of the access we grant by policy?

It _might_ be possible to do something technical about one off cases like this. For instance, it might be possible to create special-use permissions for data related to a specific kind of request -- say, for instance, some mechanism that allows communication of the terms of a subpoena so that the request can get access to data related to that subpoena, but can't re-use the credential for access to data that are unrelated to the case in question. This sort of thing would probably require some development of the federated authentication systems we've talked about, and might be too complicated to be bothered implementing. But it is not technically impossible, just expensive.

I hope we will get to ask these questions further down the road and find a workable solution to them. In the meantime, I just wanted to note that authentication is not the solution, but only a step on the way towards the solution. The solution must be broader.

Obviously, authentication isn't magic: you need to decide what to do on the basis of the credential that's presented. But the general point is that, in the presence of authentication, you have a whole bunch of policy options that were simply not available with whois, because whois is too primitive a protocol. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

I realize that this discussion is premature but it is very important. Despite our reliance in this group on the work of the EWG, it is important to note a few things that we addressed in a very insufficient manner in that report, and in my view they are deal-breakers: 1) How to authenticate law enforcement, private cybersecurity actors, and lawyers/paralegals when they are requesting access to greater levels of detail. Court orders cover only certain cases, most are not covered. Who are they, what do they get, why do they get it, and how do you audit what they actually did? THese are to my non technical mind, separate authentication issues. The actors need to be authenticated, the request needs to be signed and authenticated as coming from an appropriate authority, the scope needs to be established and signed, the trail needs to be auditable (and thus authenticated). Guys like Brad Malin who have done interesting work on anonymization of hospital records have tackled these problems, but I cannot imagine how we apply it to this honking big global system. 2) Nation states do not sign MLATS with all countries. Why would ICANN engineer a system that overrides national sovereignty and permits actors in untrusted jurisdictions to request data they could not get through another country's justice department? 3) Limiting the scope of data search. Given the nature of cybercrime and intellectual property abuse/crime, is it not the case that requests will be very expansive in scope? If I understand Scott's intervention, he is working on a standard that will actually limit data elements to those relevant. The problem is, how does one determine what is relevant? As mentioned in this thread, some things lend themselves to technical intervention better than others. I have spoken to a former federal court judge in our own jurisdiction who admitted it was impossible to tell from the applications for Court orders what was actually being requested, and one of our Federal Court judges was actually recently taking our Solicitor General to court for not telling the truth in its applications. Bottom line, it is hard to limit scope in human space, let alone on a system. Furthermore, the examples I mention here are from Canada, where despite the protests of those of us in civil society, the degree of abuse of surveillance is somewhat limited. We have to build a system that is resilient in all possible cases where abuse might be expected (Please do not tell me I am catastrophizing here, we are talking about fundamental human rights and due process, it is important to be cautious.) I would love it if we could figure out how to do this automatically as a request comes in, and there is work on AI in the legal sphere that might be useful....but it is years away from actually working according to the most recent material on robotics that I have seen. 4) Jurisdiction. There are important recent cases on jurisdiction, some of which found their way on to our massive document list. The EWG gave only a cursory glance at jurisdiction, in my view, and it is a very hard problem. We discussed location of the RDS in basic terms (eg. does the jurisdiction have privacy law). Human rights are safeguarded in our respective constitutions, criminal procedure, and Charters of rights. Moving data outside of the individual's jurisdiction usually guts those rights. Data localization is not the answer, assuring a universal high standard of protection of basic rights is the answer. hard to do. Stephanie Perrin On 2016-07-20 6:08, Andrew Sullivan wrote:

On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote:

...

my concern with re-using the mechaisms offered by http(s) is that to my knowledge it does not support differentiated or tiered access. I'm not sure this attends to how the layers work in this protocol.

Https in the case of RDAP is just the protocol by which you carry the bits. RDAP is an application protocol. So https provides the TLS-based authentication mechanism of the accessing application. Once you have the TLS credential, your RDAP server is in a position to examine the presented credentials and make a decision about what data to return. This is part of the RDAP server application. But RDAP has the capability to do that _built in_ by virtue of having access to authentication credentials that are not available as part of the whois protocol.

...

Say I am a Turkish "law enforcement official" (whatever that means in these days) and have access to certain data fields because we decided that this is the level of access given to law enforcement. I can now access this level of information for anything. So we need not only authentication, but also protection from abuse of such authenticated users. We need granulatity to be able to not only to say that user A has access to information level B, but also ensure that this information can only be requested for purpose C and prevent any access to the same information for abusive use D. I think this conflates policies that are amenable to technical imposition, and policies that are not.

For a given authenticated user, that authenticated user has access to certain data. The data fields in question are available to the user, and other data fields are not. That's something that can be imposed technically: for any login that meets the same profile, the restrictions in question yield the same access controls.

There is literally nothing technically possible to do about someone using data they obtain this way for purposes for which the data were not intended. It may be that ICANN ought to have additional policies about what happens if someone uses data outside the scope that the data was supposed to be used -- the classic example is people using privileged information access to dig up info on former romantic partners. Normally, the way we solve that is that we fire people who abuse their credentials when we catch them. So, ICANN could have a policy about suspending credentials, similarly.

...

If for example law enforcement has the ability to access certain information based on a court order, we would have to ensure that this access level can only be used if such a court order is present, otherwise how to shoield users from abuse of the access we grant by policy? It _might_ be possible to do something technical about one off cases like this. For instance, it might be possible to create special-use permissions for data related to a specific kind of request -- say, for instance, some mechanism that allows communication of the terms of a subpoena so that the request can get access to data related to that subpoena, but can't re-use the credential for access to data that are unrelated to the case in question. This sort of thing would probably require some development of the federated authentication systems we've talked about, and might be too complicated to be bothered implementing. But it is not technically impossible, just expensive.

...

I hope we will get to ask these questions further down the road and find a workable solution to them. In the meantime, I just wanted to note that authentication is not the solution, but only a step on the way towards the solution. The solution must be broader. Obviously, authentication isn't magic: you need to decide what to do on the basis of the credential that's presented. But the general point is that, in the presence of authentication, you have a whole bunch of policy options that were simply not available with whois, because whois is too primitive a protocol.

Best regards,

A

I'm at a loss as to why folks can't respect where we are in the work plan, despite numerous reminders from Chuck. This is premature. Full stop. Kiran Malancharuvil Policy Counselor MarkMonitor 415-419-9138 (m) Sent from my mobile, please excuse any typos. On Jul 20, 2016, at 10:17 AM, Sam Lanfranco <sam@lanfranco.net<mailto:sam@lanfranco.net>> wrote: ICANN is neither Star Trek’s Starship Enterprise nor Nanny ICANN. In response to Stephanie’s questions here are short comments. For RDS ICANN is not going where nobody has gone before and it is not some sort of global Internet Nanny. ICANN should restrict itself to the minimum dataset it needs to conduct its business with Registries and Registrars within it DNS Remit. Full Stop! Let Registries and Registrars deal with the “how to authenticate law enforcement requests” at the national and multilateral level. ICANN can, in the public interest, advise one and all on best policy there but it cannot weld an authentication process into its contracts. Within its remit ICANN has no right to do so. One might suspect that the Registries and Registrars are trying to off load onto ICANN work they should be sorting out among themselves, both nationally and multilaterally. That is how the rest of the world does it. There seems to be a tendency toward ICANN exceptionalism here. What ICANN does is important but it is not exceptional, it is business in the public interest. How it does it is exceptional: consensus policy (within the REMIT) based on a multistakeholder process. Lastly, and this is important, this process is not about fixing something that is broken. Much of what works badly is actually at the national and multilateral level and outside ICANN’s remit in any event. At best the goal here is to improve a process, but there is no urgency. The work can be tiring but in the absence of urgency the rational decision is to slow the process down, to make it less burdensome and not result in hasty rash bad decisions. Sam L. NPOC/CSIH _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

ICANN is neither Star Trek’s Starship Enterprise nor Nanny ICANN. In response to Stephanie’s questions here are short comments. For RDS ICANN is not going where nobody has gone before and it is not some sort of global Internet Nanny. ICANN should restrict itself to the minimum dataset it needs to conduct its business with Registries and Registrars within it DNS Remit. Full Stop!

Agreed regarding the restriction to a minimum data set.

Let Registries and Registrars deal with the “how to authenticate law enforcement requests” at the national and multilateral level. ICANN can, in the public interest, advise one and all on best policy there but it cannot weld an authentication process into its contracts. Within its remit ICANN has no right to do so. One might suspect that the Registries and Registrars are trying to off load onto ICANN work they should be sorting out among themselves, both nationally and multilaterally. That is how the rest of the world does it. There seems to be a tendency toward ICANN exceptionalism here. What ICANN does is important but it is not exceptional, it is business in the public interest. How it does it is exceptional: consensus policy (within the REMIT) based on a multistakeholder process.

I disagree that the problem of how to authenticate law enforcement requests should be dumped at the doorstep of contracted parties. The policy must be complete and give structure to this issue.

Lastly, and this is important, this process is not about fixing something that is broken. Much of what works badly is actually at the national and multilateral level and outside ICANN’s remit in any event. At best the goal here is to improve a process, but there is no urgency. The work can be tiring but in the absence of urgency the rational decision is to slow the process down, to make it less burdensome and not result in hasty rash bad decisions.

Agreed that ICANN should not solve the problem of international law enforcement information requests and jurisdictional issues. These should be left to the governmental level. If governments want to improve how these existing systems work, they can do so by means of multi-lateral agreements, not by influencing ICANN policy.

Sam L. NPOC/CSIH

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

As I continue to say over and over again: * This is all great discussion but it is way ahead of where we are. * We will have to repeat it later. * It detracts from our current tasks and takes time away from getting them completed. Here are the tasks that the WG should be focusing on right now: 1. Complete the Doodle poll about a possible face-to-face WG meeting at ICANN 57 in Hyderabad if you haven't already done so: http://doodle.com/poll/zezbbghrmwavtdma 2. Review the D3Triage document with focus on ensuring that pre-requisites/dependencies and assigned phase are correct 3. Volunteer to develop use cases of your own interest to be presented during next week's meeting using the template provided; note that we only need one or two of these this week but others could be used in the coming weeks. Please focus on our current tasks. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Sam Lanfranco Sent: Thursday, July 21, 2016 9:35 AM To: Volker Greimann; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) In response to my comments of the ICANN scope of remit within DNS and the RDS Volker Greimann wrote: I disagree that the problem of how to authenticate law enforcement requests should be dumped at the doorstep of contracted parties. The policy must be complete and give structure to this issue. I agree with the sense of Volker's position and did not mean that ICANN should or can wash it hands clean of the process of defining how to authenticate law enforcement requests, but it should not try to go it alone on just DNS data. Here, I would separate out the "how to authenticate" from the rest of the RDS discussion. I would suggest that it be carried out in a wider multistakeholder discussion where ICANN is an interested stakeholder working with interested constituencies (human rights, etc.) governments and law enforcement officials, working to fashion a policy that probably results in multilateral agreements. There will not be a authentication process for DNS data that is separate from the authentication process for data elsewhere in the Internet and digital ecosystem. As current case after case demonstrates, law enforcement access to DNS related data is only a small slice of the data now being requested. The trans-border nature of data means that multilateral agreements are inevitable and the only path to a sustainable (and hopefully sane) policy. Sam Lanfranco, NPOC/CSIH

Comments inline From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Wednesday, July 20, 2016 9:42 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) I realize that this discussion is premature but it is very important. Despite our reliance in this group on the work of the EWG, it is important to note a few things that we addressed in a very insufficient manner in that report, and in my view they are deal-breakers: 1) How to authenticate law enforcement, private cybersecurity actors, and lawyers/paralegals when they are requesting access to greater levels of detail. Court orders cover only certain cases, most are not covered. Who are they, what do they get, why do they get it, and how do you audit what they actually did? THese are to my non technical mind, separate authentication issues. The actors need to be authenticated, the request needs to be signed and authenticated as coming from an appropriate authority, the scope needs to be established and signed, the trail needs to be auditable (and thus authenticated). Guys like Brad Malin who have done interesting work on anonymization of hospital records have tackled these problems, but I cannot imagine how we apply it to this honking big global system. [Mark Svancarek] As Volker mentions, the technical aspects of authorization (differential or otherwise) are pretty straightforward and well understood. It's nice that he's investigating right now but this isn't an area I am particularly worried about implementing if and when the time comes. Likewise, I'm not worried about implementing the audit capabilities either. IMO the tough parts will be (1) agreeing on the policies which define what data can be seen by which actors under which circumstances and (b) ensuring that actors are assigned the correct levels of access defined in (1) in the first place. So I request we focus on the policy aspects now and the technical details later. 2) Nation states do not sign MLATS with all countries. Why would ICANN engineer a system that overrides national sovereignty and permits actors in untrusted jurisdictions to request data they could not get through another country's justice department? [Mark Svancarek] I don't recall anyone actually advocating for this, and I am not aware of any proposals which imply such a situation, either. Can you clarify? 3) Limiting the scope of data search. Given the nature of cybercrime and intellectual property abuse/crime, is it not the case that requests will be very expansive in scope? If I understand Scott's intervention, he is working on a standard that will actually limit data elements to those relevant. The problem is, how does one determine what is relevant? As mentioned in this thread, some things lend themselves to technical intervention better than others. I have spoken to a former federal court judge in our own jurisdiction who admitted it was impossible to tell from the applications for Court orders what was actually being requested, and one of our Federal Court judges was actually recently taking our Solicitor General to court for not telling the truth in its applications. Bottom line, it is hard to limit scope in human space, let alone on a system. Furthermore, the examples I mention here are from Canada, where despite the protests of those of us in civil society, the degree of abuse of surveillance is somewhat limited. We have to build a system that is resilient in all possible cases where abuse might be expected (Please do not tell me I am catastrophizing here, we are talking about fundamental human rights and due process, it is important to be cautious.) I would love it if we could figure out how to do this automatically as a request comes in, and there is work on AI in the legal sphere that might be useful....but it is years away from actually working according to the most recent material on robotics that I have seen. [Mark Svancarek] I have some ideas how we can implement the authorization specific to each level of access (as do Volker and others, of course), which can be defined as granularly as desired based on the policy decisions we make. As Stephanie notes, we should be very clear what is viewable based on each granular level of access so that a judge can make an informed decision based on which data should be turned as a result of a court order. 4) Jurisdiction. There are important recent cases on jurisdiction, some of which found their way on to our massive document list. The EWG gave only a cursory glance at jurisdiction, in my view, and it is a very hard problem. We discussed location of the RDS in basic terms (eg. does the jurisdiction have privacy law). Human rights are safeguarded in our respective constitutions, criminal procedure, and Charters of rights. Moving data outside of the individual's jurisdiction usually guts those rights. Data localization is not the answer, assuring a universal high standard of protection of basic rights is the answer. hard to do. [Mark Svancarek] As we mention in the draft problem statement, we will be going forward in a pragmatic and practical way while acknowledging that this is in some ways new territory, legally speaking. However, please note that [PR-D30-R05] & [UP-D30-R06] already attempt to capture this requirement. We don't need to debate the importance of the issue if it's already captured in the proposed requirements (and if it's not, the process should be to add it, rather than discuss in email)... does that make sense? Stephanie Perrin On 2016-07-20 6:08, Andrew Sullivan wrote: On Wed, Jul 20, 2016 at 11:24:37AM +0200, Volker Greimann wrote: my concern with re-using the mechaisms offered by http(s) is that to my knowledge it does not support differentiated or tiered access. I'm not sure this attends to how the layers work in this protocol. Https in the case of RDAP is just the protocol by which you carry the bits. RDAP is an application protocol. So https provides the TLS-based authentication mechanism of the accessing application. Once you have the TLS credential, your RDAP server is in a position to examine the presented credentials and make a decision about what data to return. This is part of the RDAP server application. But RDAP has the capability to do that _built in_ by virtue of having access to authentication credentials that are not available as part of the whois protocol. Say I am a Turkish "law enforcement official" (whatever that means in these days) and have access to certain data fields because we decided that this is the level of access given to law enforcement. I can now access this level of information for anything. So we need not only authentication, but also protection from abuse of such authenticated users. We need granulatity to be able to not only to say that user A has access to information level B, but also ensure that this information can only be requested for purpose C and prevent any access to the same information for abusive use D. I think this conflates policies that are amenable to technical imposition, and policies that are not. For a given authenticated user, that authenticated user has access to certain data. The data fields in question are available to the user, and other data fields are not. That's something that can be imposed technically: for any login that meets the same profile, the restrictions in question yield the same access controls. There is literally nothing technically possible to do about someone using data they obtain this way for purposes for which the data were not intended. It may be that ICANN ought to have additional policies about what happens if someone uses data outside the scope that the data was supposed to be used -- the classic example is people using privileged information access to dig up info on former romantic partners. Normally, the way we solve that is that we fire people who abuse their credentials when we catch them. So, ICANN could have a policy about suspending credentials, similarly. If for example law enforcement has the ability to access certain information based on a court order, we would have to ensure that this access level can only be used if such a court order is present, otherwise how to shoield users from abuse of the access we grant by policy? It _might_ be possible to do something technical about one off cases like this. For instance, it might be possible to create special-use permissions for data related to a specific kind of request -- say, for instance, some mechanism that allows communication of the terms of a subpoena so that the request can get access to data related to that subpoena, but can't re-use the credential for access to data that are unrelated to the case in question. This sort of thing would probably require some development of the federated authentication systems we've talked about, and might be too complicated to be bothered implementing. But it is not technically impossible, just expensive. I hope we will get to ask these questions further down the road and find a workable solution to them. In the meantime, I just wanted to note that authentication is not the solution, but only a step on the way towards the solution. The solution must be broader. Obviously, authentication isn't magic: you need to decide what to do on the basis of the credential that's presented. But the general point is that, in the presence of authentication, you have a whole bunch of policy options that were simply not available with whois, because whois is too primitive a protocol. Best regards, A

On 21 Jul 2016, at 12:41 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:

I realize that this discussion is premature but it is very important. Despite our reliance in this group on the work of the EWG, it is important to note a few things that we addressed in a very insufficient manner in that report, and in my view they are deal-breakers:

1) How to authenticate law enforcement, private cybersecurity actors, and lawyers/paralegals when they are requesting access to greater levels of detail. Court orders cover only certain cases, most are not covered. Who are they, what do they get, why do they get it, and how do you audit what they actually did? THese are to my non technical mind, separate authentication issues. The actors need to be authenticated, the request needs to be signed and authenticated as coming from an appropriate authority, the scope needs to be established and signed, the trail needs to be auditable (and thus authenticated). Guys like Brad Malin who have done interesting work on anonymization of hospital records have tackled these problems, but I cannot imagine how we apply it to this honking big global system.

While these are obviously complicated issues, they are primarily policy issues not technical ones. It is my opinion that there are potential technical mechanisms that could provide support for relatively efficient technical implication of these mechanisms if needed. The efficient policy implementation of these issues is more complex, but surely the process you describe is aspirational at best in some jurisdictions.

2) Nation states do not sign MLATS with all countries. Why would ICANN engineer a system that overrides national sovereignty and permits actors in untrusted jurisdictions to request data they could not get through another country's justice department?

It is important to understand that all LEAs are not equal, even that complying with a lawful order in one jurisdiction might be illegal in another. We should also understand that some voluntary cooperation with some requests from outside national jurisdictions is also a possibility. Cross-jurisdictional requests are something that we should consider carefully. David

Dear Stephanie Perrin and Andrew, (inline) On Sat, Jul 16, 2016 at 10:42 AM, Stephanie Perrin < stephanie.perrin@mail.utoronto.ca> wrote:

I think these are really important questions Andrew. Unfortunately when we talk about privacy and data control, we often use idioms that are technologically out of date (eg video surveillance, which conjures up mental images of video tapes that have not been used in 15 years). To be clear, we need to talk about control of data elements. Fortunately, despite a lot of FUD to the contrary, the EU data protection authorities have focused on data controllers and data processors, and we have good documents with summaries for those concepts. They have not changed with the new regulation, so they are still valid.

If I understand RDAP correctly, it would permit duly authorized data access from anywhere, to elements that could be scattered. This would match current data mining techniques. The problem, as I see it, and I beg to be corrected if I am wrong, is how do we manage a remote authorization scheme to individual data elements, if indeed

some data is held by the registrar, some by the registry, and some (outside ICANN's remit, but an answer to LEA demands) by the ISP?

​I will start with the disclaimer that I am writing this WITHOUT a good understanding of the technical operations concerning the present RDAP nor about the advances in data mining technology. ​The question "where data resides" ​and if the design of RDAP is to make it easier to answer that question, and on a superficial level "data" here means Registration Data, this is very much becomes a whois design question. If some data is held by Registrar, some by Registry and some by the ISP, there may be a way of streamlining this by modifying the manner in which Registrant data is gathered and stored at the time of registration. Some attention to the VISA/MASTERCARD method of collecting and handling credit card information could help ICANN come up with a streamlined design for handling Registrant data. If such a model is to be emulated, a Registrant going to a sub-Reseller going through a Reseller going through a Registrar under a Registry would gather the Registrant data on a secure form interjected by an operator like Verisign, -verisign here is not to be confused with Verisign the Registry, or Verisign the RZM operator, but that division of Verisign which serves the secure form-, independent of and regardless of the insecurity of the Sub-Reseller's webspace. This could be verisign or even an IAB designed secure form. This verisign form ( I will call it the Verisign form, for illustration) could then be used to collect: a) all Registrant data and then automatically distribute the basic data back to the Sub-Reseller and Reseller, basic + quasi-sensitive data to the Registrar under whom the Reseller operates and retain a copy of the above + Sensitive data with the Registry, while ultra-sensitive data, if any so categorised by any name, together with all of the above would stay only with ICANN. (the categorization of data as basic etc is arbitrary. This is a generalized description of how it would work, there may be existing classes and sub-classes or ICANN may come up with suitable sub-classes of Registrant data) b) The Sensitive and Ultra-sensitive user data alone could be gathered by the Verisign form after the basic data is collected by the Reseller in his own form that may be shared with the Registrar. This would prevent Registrant data abuse in a situation where there are a multitude of Resellers. The Resellers would retain the basic contact information for them the opportunity to maintain contact with their customers, Registrars would get a copy of whatever commercial data that they require from the Resellers or from their direct customers, the Registry would still retain most of the data with a copy for the ICANN in a database, and only ICANN retain the ultra-sensitive data, if there is any part of Registrant data is ultra-sensitive by any other name. This would require assurances from ICANN that it would enforce a well designed process involving a highly ethical team of community members to screen requests from Law and Order authorities anywhere to access data, and to determine what portion of data they would access. The caution needed here is that such a system may have to be well thought of, the privacy and security concerns to be examined in extensive detail, the commercial privileges concerning Registrant data prevailing among Resellers, Registrars and Registries have be examined, the ability of ICANN / Internet Community to judge the validity of Law and Order requests and the strength of ICANN to deny some requests if deemed necessary - all these aspects have to be examined in detail. If the question "where does data reside" extends beyond Registrant data, the answer would be far more complicated. That would draw the Internet Community's attention to questions concerning content in a very interesting way. Sivasubramanian M

Cheers Stephanie

On 2016-07-16 1:00, Andrew Sullivan wrote:

Thanks, Stephanie, for the quick issue list. There's one thing that I want to draw out here so that we can keep it foremost when thinking of issues:

On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote:

* Where the RDS (whether a central database or federated or completely disaggregated) resides becomes important for law enforcement access.

This "where data resides" issue is bound to vex us, no matter what kind of policy we come up with. But it's really important to keep in mind that the different styles of system design will yield very different properties.

In the taxonomy I offered before (http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html), models I and V have a clear since answer to, "Where does the data reside?" because they have a single database backing them up. In models II-IV, however, the answer to, "Where does the data reside?" is actually not entirely meaningful. There are multiple places where the data are, and for data with respect to any given domain name each datum might be in a different place. (Indeed, part of the design of RDAP is precisely to make such arrangements easier to deal with.)

It is therefore better to try to find a way, consistent with all of the various requirements documents, to answer some other questions. I think these might be helpful in building use cases:

1. For any given datum, who has control of and access to the datum?

2. For any given datum, what are the conditions under which the datum ought to be accessible?

3. For any given set of related data, how can it be accessed?

Notice that answering (3) will provides use cases for data access, whereas (1) and (2) provide for limit conditions on how and when use cases might be apply.

I hope these framing questions are helpful in figuring out which use cases we can bring to bear on requirements.

Best regards,

A

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Sivasubramanian, You are getting way ahead of where we are in our work plan. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Sivasubramanian M Sent: Saturday, July 16, 2016 4:06 AM To: Stephanie Perrin Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) Dear Stephanie Perrin and Andrew, (inline) On Sat, Jul 16, 2016 at 10:42 AM, Stephanie Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> wrote: I think these are really important questions Andrew. Unfortunately when we talk about privacy and data control, we often use idioms that are technologically out of date (eg video surveillance, which conjures up mental images of video tapes that have not been used in 15 years). To be clear, we need to talk about control of data elements. Fortunately, despite a lot of FUD to the contrary, the EU data protection authorities have focused on data controllers and data processors, and we have good documents with summaries for those concepts. They have not changed with the new regulation, so they are still valid. If I understand RDAP correctly, it would permit duly authorized data access from anywhere, to elements that could be scattered. This would match current data mining techniques. The problem, as I see it, and I beg to be corrected if I am wrong, is how do we manage a remote authorization scheme to individual data elements, if indeed some data is held by the registrar, some by the registry, and some (outside ICANN's remit, but an answer to LEA demands) by the ISP? ​I will start with the disclaimer that I am writing this WITHOUT a good understanding of the technical operations concerning the present RDAP nor about the advances in data mining technology. ​The question "where data resides" ​and if the design of RDAP is to make it easier to answer that question, and on a superficial level "data" here means Registration Data, this is very much becomes a whois design question. If some data is held by Registrar, some by Registry and some by the ISP, there may be a way of streamlining this by modifying the manner in which Registrant data is gathered and stored at the time of registration. Some attention to the VISA/MASTERCARD method of collecting and handling credit card information could help ICANN come up with a streamlined design for handling Registrant data. If such a model is to be emulated, a Registrant going to a sub-Reseller going through a Reseller going through a Registrar under a Registry would gather the Registrant data on a secure form interjected by an operator like Verisign, -verisign here is not to be confused with Verisign the Registry, or Verisign the RZM operator, but that division of Verisign which serves the secure form-, independent of and regardless of the insecurity of the Sub-Reseller's webspace. This could be verisign or even an IAB designed secure form. This verisign form ( I will call it the Verisign form, for illustration) could then be used to collect: a) all Registrant data and then automatically distribute the basic data back to the Sub-Reseller and Reseller, basic + quasi-sensitive data to the Registrar under whom the Reseller operates and retain a copy of the above + Sensitive data with the Registry, while ultra-sensitive data, if any so categorised by any name, together with all of the above would stay only with ICANN. (the categorization of data as basic etc is arbitrary. This is a generalized description of how it would work, there may be existing classes and sub-classes or ICANN may come up with suitable sub-classes of Registrant data) b) The Sensitive and Ultra-sensitive user data alone could be gathered by the Verisign form after the basic data is collected by the Reseller in his own form that may be shared with the Registrar. This would prevent Registrant data abuse in a situation where there are a multitude of Resellers. The Resellers would retain the basic contact information for them the opportunity to maintain contact with their customers, Registrars would get a copy of whatever commercial data that they require from the Resellers or from their direct customers, the Registry would still retain most of the data with a copy for the ICANN in a database, and only ICANN retain the ultra-sensitive data, if there is any part of Registrant data is ultra-sensitive by any other name. This would require assurances from ICANN that it would enforce a well designed process involving a highly ethical team of community members to screen requests from Law and Order authorities anywhere to access data, and to determine what portion of data they would access. The caution needed here is that such a system may have to be well thought of, the privacy and security concerns to be examined in extensive detail, the commercial privileges concerning Registrant data prevailing among Resellers, Registrars and Registries have be examined, the ability of ICANN / Internet Community to judge the validity of Law and Order requests and the strength of ICANN to deny some requests if deemed necessary - all these aspects have to be examined in detail. If the question "where does data reside" extends beyond Registrant data, the answer would be far more complicated. That would draw the Internet Community's attention to questions concerning content in a very interesting way. Sivasubramanian M Cheers Stephanie On 2016-07-16 1:00, Andrew Sullivan wrote: Thanks, Stephanie, for the quick issue list. There's one thing that I want to draw out here so that we can keep it foremost when thinking of issues: On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote: * Where the RDS (whether a central database or federated or completely disaggregated) resides becomes important for law enforcement access. This "where data resides" issue is bound to vex us, no matter what kind of policy we come up with. But it's really important to keep in mind that the different styles of system design will yield very different properties. In the taxonomy I offered before (http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html), models I and V have a clear since answer to, "Where does the data reside?" because they have a single database backing them up. In models II-IV, however, the answer to, "Where does the data reside?" is actually not entirely meaningful. There are multiple places where the data are, and for data with respect to any given domain name each datum might be in a different place. (Indeed, part of the design of RDAP is precisely to make such arrangements easier to deal with.) It is therefore better to try to find a way, consistent with all of the various requirements documents, to answer some other questions. I think these might be helpful in building use cases: 1. For any given datum, who has control of and access to the datum? 2. For any given datum, what are the conditions under which the datum ought to be accessible? 3. For any given set of related data, how can it be accessed? Notice that answering (3) will provides use cases for data access, whereas (1) and (2) provide for limit conditions on how and when use cases might be apply. I hope these framing questions are helpful in figuring out which use cases we can bring to bear on requirements. Best regards, A _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Any volunteers to develop Andrew's suggestions into use cases? Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Saturday, July 16, 2016 1:00 AM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) Thanks, Stephanie, for the quick issue list. There's one thing that I want to draw out here so that we can keep it foremost when thinking of issues: On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote:

* Where the RDS (whether a central database or federated or completely disaggregated) resides becomes important for law enforcement access.

This "where data resides" issue is bound to vex us, no matter what kind of policy we come up with. But it's really important to keep in mind that the different styles of system design will yield very different properties. In the taxonomy I offered before (http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html), models I and V have a clear since answer to, "Where does the data reside?" because they have a single database backing them up. In models II-IV, however, the answer to, "Where does the data reside?" is actually not entirely meaningful. There are multiple places where the data are, and for data with respect to any given domain name each datum might be in a different place. (Indeed, part of the design of RDAP is precisely to make such arrangements easier to deal with.) It is therefore better to try to find a way, consistent with all of the various requirements documents, to answer some other questions. I think these might be helpful in building use cases: 1. For any given datum, who has control of and access to the datum? 2. For any given datum, what are the conditions under which the datum ought to be accessible? 3. For any given set of related data, how can it be accessed? Notice that answering (3) will provides use cases for data access, whereas (1) and (2) provide for limit conditions on how and when use cases might be apply. I hope these framing questions are helpful in figuring out which use cases we can bring to bear on requirements. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Thanks Mark. Chuck -----Original Message----- From: Mark Svancarek [mailto:marksv@microsoft.com] Sent: Monday, July 18, 2016 1:40 PM To: Gomes, Chuck; 'Andrew Sullivan'; gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) I'll take a stab at it. I've also asked our IP/Brand people and digital crimes people to help me document how Microsoft uses WhoIs data today, but not ETA when that will be ready. -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Gomes, Chuck Sent: Saturday, July 16, 2016 6:29 AM To: 'Andrew Sullivan' <ajs@anvilwalrusden.com>; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) Any volunteers to develop Andrew's suggestions into use cases? Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Saturday, July 16, 2016 1:00 AM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list ) Thanks, Stephanie, for the quick issue list. There's one thing that I want to draw out here so that we can keep it foremost when thinking of issues: On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote:

* Where the RDS (whether a central database or federated or completely disaggregated) resides becomes important for law enforcement access.

This "where data resides" issue is bound to vex us, no matter what kind of policy we come up with. But it's really important to keep in mind that the different styles of system design will yield very different properties. In the taxonomy I offered before (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmm.icann.org...), models I and V have a clear since answer to, "Where does the data reside?" because they have a single database backing them up. In models II-IV, however, the answer to, "Where does the data reside?" is actually not entirely meaningful. There are multiple places where the data are, and for data with respect to any given domain name each datum might be in a different place. (Indeed, part of the design of RDAP is precisely to make such arrangements easier to deal with.) It is therefore better to try to find a way, consistent with all of the various requirements documents, to answer some other questions. I think these might be helpful in building use cases: 1. For any given datum, who has control of and access to the datum? 2. For any given datum, what are the conditions under which the datum ought to be accessible? 3. For any given set of related data, how can it be accessed? Notice that answering (3) will provides use cases for data access, whereas (1) and (2) provide for limit conditions on how and when use cases might be apply. I hope these framing questions are helpful in figuring out which use cases we can bring to bear on requirements. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or... _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...

I support Chuck's comments. When exploring new documents, we should pull out what's different. Volume doesn't equal right, but rather the careful application and relevance to the situation we are exploring. (Incidentally, this is why use cases are necessary.) Thanks, Kiran Kiran Malancharuvil Policy Counselor MarkMonitor 415-419-9138 (m) Sent from my mobile, please excuse any typos.

On Jul 15, 2016, at 7:31 AM, Gomes, Chuck <cgomes@verisign.com> wrote:

I want to Segway off of Andrew's thoughts.

We all recognize that there is a huge amount of duplication in the large list of resources we have identified so I suggest this: as we identify new resources and even as we consider those that have already been identified, let's all try to focus on any new points that are added and call attention to those.

Chuck

-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, July 15, 2016 8:10 AM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] The overflowing list (was Re: A new and rather important document with respect to jurisdiction issues)

...

On Thu, Jul 14, 2016 at 11:32:13PM -0400, Stephanie Perrin wrote: May I suggest that we add it to our already overflowing list of important documents?

I don't object, but I'm wondering whether there is really anything new in most of the additional documents people are bringing.

It seems to me that we have a fundamental question we're going to have to answer. I know that we've decided that now is not the time for deliberation, so I don't encourage discussion about this question. But I'm decreasingly convinced that more material is going to help us come to any decision about balancing the desire of some, on one side, to have a lot of personally identifying information about domain name registrants; and the desire of others to ensure that such personally identifying information is protected on privacy grounds.

We can probably continue to find additional examples of people insisting they need one or the other of these, but I do not really see any way that more evidence that someone really really wants one of them (with all the attendant arguments rehearsed) is going to help us come to a conclusion.

Best regards,

A

-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Good suggestions Sam. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Sam Lanfranco Sent: Tuesday, July 19, 2016 8:38 AM To: Andrew Sullivan; gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] The overflowing list (was Re: A new and rather important document with respect to jurisdiction issues) On July 15th Andrew Sullivan posted with regard to additional documents: “I don't object, but I'm wondering whether there is really anything new in most of the additional documents people are bringing.”. While it is agreed that there is no cut off date for additional documents one simple practice that would make additions manageable is that the contributor/poster offer a very short explanation of the relevance of the document. Possible points would include: * Is this a new point to consider, or does it add weight to an existing point already being considered? * Does it address a principle, a single or cluster of proposed data points, or a use case? * Does it address the issue of what is within or outside the ICANN remit in this exercise? * Does it reference an external factor that would impact on the public interest dimensions of a data decision? Sam L. NPOC