Responses to your inline comments. I will chop some discussion out for clarity.
David, I’m new to this discussion, and don’t have all the context of the prior discussion. Also, I may not use the right terminology.
Yes, and this working group (and ICANN in general) tends to grind very fine, with a lot of focus on specific details. All of your comments are useful, but some are not applicable to the precise task we are dealign with right now.
This shouldn’t discourage you from commenting, just don’t get surprised when you have to make the same arguments later in a different context. Possibly a LOT later on some issues (we are not yet addressing specific implementation issues, that comes later in ‘Phase 2').
David
That is close to our understanding, that WHOIS data is one of the methods used to demonstrate domain control.
Disputes in the working group have centered around issues of data exactly what constitutes legitimate data collection, and its implications. As CAs, we have no position on what data collection is “legitimate” – but we view the WhoIs record is like an auto registry system or real estate registry system – it is intended to show (1) ownership (with enough information to disambiguate if there ar 5 “David Cakes” in your city – so address and phone number help here, (2) means of contacting the owner for a valid purpose (e.g., a complaint if the registered car was part of an auto accident, an offer to buy the registered house from the owner, or a lawsuit against the registered domain owner if libelous information was posted on the site). In other parts of society, the gathering of ownership and contact information is generally viewed as legitimate as part of everyday commerce. For a domain owner, listing ownership and contact information in the WhoIs record is a normal part of doing other transactions that are beneficial to the domain owner, such as ordering a digital certificate to encrypt your website.
The discussion of ownership, and the requirement to demonstrate it, is very helpful and very germane to our current question.
I added the point about disambiguation into the discussion of 3.2.2.4.1
The means of contacting the owner for a valid purpose is very applicable to this stage of the working groups work, but NOT to this drafting team, which is very specifically about Domain Name Certification as a purpose.
Which does not mean that those other purposes are not applicable to the work of CAs - obviously, CAs might have their own business disputes with their customers, or may wish to contact another domain name that is involved in their business about a technical problem. But those other purposes are being discussed in detail in other drafting teams.
but in the rest of the world, there may ALSO be a reason why the public can see the information, and don’t have to get the owner’s permission to see it (for example, who owns the house next door to yours if the house is sliding down the hill and you need to ready the home owner.) If could be reasonable to have a rule set for domains that allows the domain owner to approve release of ownership/contact information on a case by case basis, but it’s likely a system like that will be ignored by most domain owners and they will not respond to a valid and beneficial request for access to the information (e.g., to allow a CA to issue a cert at the domain owner’s request)
Quite true, though again largely outside this Drafting Teams scope.
It may also be that those that wish more granular control over their data, as you describe, may have to use a proxy or privacy service (a service many registrars offer for a small additional fee, though there are also independent providers).
Does the GDPR allow exceptions to privacy when reasonably necessary for the provision of goods and services to the data owner?
The short answer is yes, but the long answer seems to involve paying lawyers for some very long documents. Some legal analyses of the details are available in the group wiki or elsewhere on the ICANN web site. This working group commissioned some legal responses, ICANN in general has also acquired separate legal responses from a different firm, and there are other documents (including response from the Data Protection Agencies that administer the GDPR) as well. A significant issue is whether or not the customer has specifically consented.
On the provision of EV certificates, most of the identity information comes from third party data sources (state and national corporate registry agencies (Secretary of State’s records, Companies House UK), private corporate data sources like Hoover’s/Dun & Bradstreet, etc.) However, EV certificates also require confirmation of domain ownership or control for domains to be included in the certificate, which defaults back to the 10 methods for domain validation – which also includes access to WhoIs data for some of the validation methods.
That is pretty much as we thought. The EV certificates still require one of the Baseline Methods for demonstrating control, but that is the only use of
Proving control of a domain by making an agreed upon change to the website is Method 6 (BR 3.2.2.4.6), and by making a change to the DNS record is Method 7 (BR 3.2.2.4.7). But other methods, like Methods 1, 2, and 3 require access to WhoIs records, and is generally easier for the domain owner to complete. In some companies, the person who buys a certificate for the website is not the same person who controls the webpages or who controls the DNS records, and it can be hard to coordinate within the company if Methods 6 or 7 are used.
Yes. I’ve worked for web site clients and I’m well aware of the issues and alternatives here. The issues are largely around consent and defaults - I do not think anyone wants methods 1,2 and 3 to become impossible for those that opt-in to use them.
I would recommend that a standard form of access agreement (giving CAs access to WhoIs data of Registrars and Registries) be created, to be used on an optional basis by registrars and registries to set the terms and conditions for access to the data. This could include terms prohibiting the CA from mining the data and reselling it, etc. It might even be possible for the CA/Browser Forum to adopt “Standard Terms and Conditions for access to WhoIs Data by Certification Authorizes” in the Forum’s Baseline Requirements document (non-mandatory), in consultation with ICANN, so that participating registrars and registries can simply make a statement “We are hereby giving access to our WhoIs data to the Certification Authorities listed here (ccadb.org list) subject to the Standard Terms and Conditions found here (link to standard document in CA/Browser Forum Baseline Requirements) – in that way, the registrars/registries would not have to come up with their own legal terms, and would not have to sign an agreement one-by-one with each CA in the world. If ICANN is interested in that approach for access to WhoIs data, the Forum can work on it.
That certainly sounds like a reasonable starting point, though there are many details to be worked out.
But the working group also has to address some more complex issues (such as access by law enforcement, or access by those who make a living by resolving abuse issues on behalf of clients) and I suspect that we may end up with a more complex and nuanced access system in place.
But again, that is very much outside the scope of this Drafting Team, and also quite a long way from where the working group is in its current discussion, which is very much focussed on purpose for data collection and access.
Just one slight point here – in most cases we use WhoIs data to prove control, but for certificates that contain identity data also, we use the WhoIs data to link the proof of domain control to a proven identity – so we prove Foo Corporation exists at a location, and then we prove foo.com is owned by Foo Corporation before putting it in the OV or EV certificate.
Is this just proof of domain control in the sense of 3.2.2.4, or is there something else here?
I do know there are a couple of points that maybe deserve a slightly closer look, like county information, but the current questions are just about identity.
David