gdpr domain industry playbook - eco€¦ · or fundamental rights and freedoms of the data subject...
TRANSCRIPT
1
GDPR Domain Industry Playbook
v.061(justminoreditscomparedtov.06)
PLEASENOTEASUMMARYISPROVIDEDWITHASEPARATEDOCUMENT
Authors:
JuliaGarbaciok*AndreasKonrad**
MartinLose*ThomasRickert**JanSchlepper**OliverSüme*
*FieldfisherGermanyLLP,Hamburg,Germany,fieldfisher.com**RickertRechtsanwaltsgesellschaftmbH,Bonn,Germany,rickert.net
Illustrations:JefferyFrankenhauser,dougstudio.com
2
PartA-Introduction/Scope 6
I. PrincipleofDataMinimization 7
II. Ourapproachtodevelopadatamodel 8
1. Whatisprocessing? 8
2. Whatislawfulprocessing? 8
3. Risksassociatedwithdataprocessing 9
a) Consent 9
b) Legitimateinterest 10
c) Performanceofacontract 10
4. Compliancerequirements 10
5. Alayeredmodel 11
6. Internationaltransfers 12
PartB–Processingofdatafordomainregistrationsandmaintainingdomainregistrations 14
I. Registrationandmanagementofthedomain 14
1. Currentdatarecords 14
2. ICANNrequirements 18
II. DRL1registrarandregistrydatawithoutadditionaleligibility/nexuscriteria 19
1. Registrar 20
a) Necessarydatarecord–registrar 20
aa)RegistrationDataRegistrar 20
bb)TechnicalData 21
cc)AccountingData 21
dd)Admin,Tech,andBillingContacts 23
ee)FurtherData 23
b) Reasons 24
aa)Contractprocessing 24
3
bb)Contacting/Transferissues 24
cc)Abuse 25
dd)Ownershipposition 25
ee)Transfers 25
ff)Result 25
2. Registry 26
a) Necessarydatarecord–registry 26
aa)Qualificationofthedomainnameaspersonaldata 28
bb)Result 29
b)Reasons 30
3. Datacontroller 30
a) DefinitionsArt.4no.(7)andno.(2)GDPR 30
b) Jointresponsibility(Art.26GDPRinconjunctionwithArt.4no.(7)GDPR) 30
aa)Hamiltonopinion 31
bb)Comment 31
(i)Differentiationofprocessorvs.controller 32
(ii)PurposeofArt.26GDPR 32
(iii)Setofoperations 33
(iv)Assessment 34
(v)Legalconsequence 35
(1) Liability 35
(2) Datasubject’sclaims 35
(3) Fines 35
(4) Agreement 35
(5) Jointcontactpoint 36
(6) Procedurerecord 36
cc)Responsibilityforotherdata 36
III. DRL1registrarandregistrywitheligibility/nexusrequirements 37
4
1. Obligation 37
2. Purpose 37
3. Responsibility 38
4. Authorization 39
IV. DataEscrow 39
1. Obligation 39
2. Purpose/necessity 40
3. Registrar 40
4. Affecteddata 40
5. Responsibility 40
6. Authorization 41
V. EBERO 41
1. Obligation 41
2. Affecteddata 42
3. Responsibility 42
VI. Resellersituation 43
1. Responsibility 43
a) AccountData 44
b) Registrationdata 44
2. Resellerchains 45
VII. DRL2–Transferofregistrantdatatotheregistry 45
1. Authorization 46
a) MitigatingAbuse 46
b) Centralmanagement 46
2. Responsibility 47
3. Risk 47
4. Conclusion 48
VIII. DRL3–Datacollectedbasedonconsent 48
5
PartC–DisclosureofData 49
I.NoJustificationforaPublicWHOISundGDPR 49
1. LegallyIneffectiveConsent 50
2. NoJustificationunderStatutoryLaw 50
II.LegalGroundsforDisclosureofRegistrationDatato3rdParties 51
1. LegalGroundsandCriteriaforDisclosure 52
a) Art.6(1)lit.b)GDPR-PerformanceofaContract–(PrivateSectorOnly) 52
b) Art.6(1)lit.c)GDPR(PublicSectorOnly) 53
c) Art.6(1)lit.f)GDPR–LegitimateInterests(PrivateSectorOnly) 55
aa)"LegitimateInterests" 55
bb)BalancingofInterests 56
cc)NecessityofDataProcessing 57
dd)RighttoObject,Art.21GDPR 57
ee)Legitimate3rdPartyInterestsforDisclosureofWhoisData 58
d) Otherrequests 59
e) Note:DataSubject´sRights,Art.12etseq.GDPR 59
f) Disclaimer 59
2. ProceduralAspects 59
a)CertificationofPublicAuthorities 59
b)CertificationofPrivate3rdParties 61
c)LogicalStructureofaDisclosureProcess 62
3. ProposalofaTrustedDataClearinghouse(TDC) 64
PartD–Outlook 65
PartA-Introduction/Scope
The General Data Protection Regulation (GDPR) poses a challenge for the Registries, Registrars,
Resellers,ICANNandtheircontractors.
ByMay25,2018,allpartiesneedtobecompliant,whichmeansthatnotonlycontractsneedtobe
reviewed,butalsotechnicalsystemsneedtoberevisited.
Todate,variouslegalmemorandahavebeensharedandseveralpartieshaveworkedontheirown
compliance, but no industry-wide proposal has been published that allows for a discussion of the
respectiverolesandresponsibilitiesofthepartiesinvolvedaswellasareviewofdataflows.
This paper shall facilitate the process of finding a commonly adopted data model to allow for
compatibilityofthetechnical,organizationalandlegalmodelsthepartieswilluse.
Thepaper shall notbe construedas legal advice.All parties involvedneed toworkon theirGDPR
complianceindividually,whichgoesfarbeyondthetopicsdiscussedhere.
This paper only deals with the data elements ICANN currently requires the contracted parties to
process.
Also, the paper will only address the data flows in the light of gTLD domain name registration
services.Thepartiesmightofferadditionalservicesorwishtoprocessadditionaldataelementsfor
their own business purposes. The legal basis for such processing needs to be assessed by the
respectivepartyandmightleadtoadditionalorothertreatmentthandiscussedinthispaper.
Thedatamodeldoesnotreflectanyoutsourcingthepartiesmightengagein.UsingaRegistryService
Providerora“Registrarasaservice”modelrequiresparticularattention.
Data flows will be analyzed encompassing the parties typically involved in a domain name
registration and as required by ICANNorganization in its contracts. The below visualization shows
how these parties are related. Dotted lines represent data flows. ICANN´s Centralized Zone Data
Service (“CZDS”)andBulkRegistrationDataAccess (“BRDA”)havenotbeenassessed in thispaper.
7
However,thesewouldneedtobereviewedaswell.WeshouldnotethatCZDSisraisingconcernsas
it currently enables systematic harvesting of Whois databases and leads to huge volumes of
unsolicitedelectroniccommunicationtoregistrants.
Note this illustration does not include outsourcing such as RSPs or Registrar-as-a-service
modelsaswellasICANN’sCZDSandBRDArequirements.
I. PrincipleofDataMinimizationTheRAandtheRAArequiretheprocessingofnumerousdataelements,notallofwhichconstitute
personaldata.WhiletheGDPRonlyprotectspersonaldata,thepaperincludesalldataelementsto
allowforaholisticviewatthedataflowsandofferabasisforimplementation.
Whilethecurrentlyuseddatarecordsarementionedinthispapertoallowforacomparisonofthe
statusquowiththeproposeddataflows,theapproachhasnotbeentomodifythecurrentsystemby
wayof subtracting certainelements toachieve compliance,but rather theopposite.Basedon the
principleofdataminimization(Art.5(1)lit.c)GDPR),thethoughtprocesswastostartwithwhatis
requiredasaminimum toprovide the servicesand toadequately recognize the rightsof thedata
subjectswhilebearingusecasesandinterestsbroughtforwardbylawenforcement,IPinterestsand
othergroups,whicharenotpartofthecontractualrelationshipsforgTLDs.
8
II. OurapproachtodevelopadatamodelThedatamodelisbasedonananalysisofhowdatacanbeprocessedinalegallycompliantfashion.
Wheredifferentoptionsforprocessingexist,theoptionswiththeleastriskforthepartiesinvolved
shouldbeprioritized.
1. Whatisprocessing?Processingmeansanyoperationorsetofoperationswhichisperformedonpersonaldataoronsets
ofpersonaldata,whetherornotbyautomatedmeans, suchascollection, recording,organization,
structuring,storage,adaptationoralteration,retrieval,consultation,use,disclosurebytransmission,
dissemination or otherwise making available, alignment or combination, restriction, erasure or
destruction,seeArt.4no.(2)GDPR.
Ascanbeseenfromthisdefinition,oneneedstorevieweachandeveryprocessfromcollectionto
deletionforeachdataelementandestablishwhatlegalbasis,ifany,thereisforprocessing,i.e.the
processesneedtobeanalyzedatthemicroandmacrolevel.
Togiveafewexamples:Datathatcanbelegallycollectedbyapartyforacertainpurposemustnot
be transferred to another party without a legal basis for that transfer. Data that can legally be
collectedandusedinternallymustnotbepublishedwithoutalegalbasisforthat.
2. Whatislawfulprocessing?
TheGDPRoffers variousalternatives for lawfulprocessing.Thesecanbe found inArt.6 (1)GDPR,
whichreadsasfollows:
Processingshallbelawfulonlyifandtotheextentthatatleastoneofthefollowingapplies:
(a) thedatasubjecthasgivenconsenttotheprocessingofhisorherpersonaldataforoneormorespecificpurposes;
(b) processing is necessary for theperformanceof a contract towhich thedata subject ispartyorinordertotakestepsattherequestofthedatasubjectpriortoenteringintoacontract;
(c) processing isnecessaryforcompliancewitha legalobligationtowhichthecontroller issubject;
9
(d) processing is necessary in order to protect the vital interests of thedata subject or ofanothernaturalperson;
(e) processingisnecessaryfortheperformanceofataskcarriedoutinthepublicinterestorintheexerciseofofficialauthorityvestedinthecontroller;
(f) processing is necessary for the purposes of the legitimate interests pursued by thecontrollerorbyathirdparty,exceptwheresuchinterestsareoverriddenbytheinterestsor fundamental rights and freedoms of the data subject which require protection ofpersonaldata,inparticularwherethedatasubjectisachild.
3. RisksassociatedwithdataprocessingInthepresentcase,subparagraphs
(a) Consent(b) Performanceofacontractand(f) LegitimateInterest
ofArt.6(1)GDPRmightbeapplicable.Thelegalassessments1availablehaveprovidedmoredetails
onthis,sowewillnotrepeatthereasoninghere,butbaseourworkonthosethreealternatives.
Itshouldbenoted,thatArt.6(1)lit.b)GDPRcannotbeusedasalegitimizationforthecurrentsetup
arguingthatICANNrequiresRegistriesandRegistrarstocollectandretainalldataintheircontracts.
Thisargumentwouldbecircularreasoning.IthastobereviewedwhethertherequirementsICANN
presentsarecompliantwithGDPR´sbasicprinciplesofdataminimizationandpurposelimitation.
Ananalysisof the threealternatives shows that therearedifferent risks and risk levels associated
withthem.
a) Consent
Withrespecttoconsent,thereareseveralfactorstoconsider,seeArt.7GDPR:
• Thecontrollermustbeabletodemonstratethatthedatasubjecthasconsented.• Ifthedatasubject'sconsentisgiveninthecontextofawrittendeclarationwhichalso
concernsothermatters,therequestforconsentshallbepresentedinamannerwhichisclearlydistinguishablefromtheothermatters,inanintelligibleandeasilyaccessibleform,usingclearandplainlanguage.AnypartofsuchadeclarationwhichconstitutesaninfringementofthisRegulationshallnotbebinding(Art.7(2)GDPR).
• Consentcanbewithdrawnatanytimewithoutgivingareason.• Consentmustbegivenfreely.Thereisaprohibitionofcoupling.
1Hamilton:https://www.icann.org/en/system/files/files/gdpr-memorandum-part1-16oct17-en.pdf;TaylorWessing:https://www.icann.org/en/system/files/correspondence/sheckler-to-swinehart-atallah-29oct17-en.pdf;WSGR:https://gnso.icann.org/en/drafts/wsgr-icann-memorandum-25sep17-en.pdf
10
Therearerisksassociatedwithproof,potentiallycouplingconsentwithadomainnameregistration
andwithdrawal.
b) Legitimateinterest
FordataprocessingaccordingtoArt.6(1)fGDPR,thereistheriskofobjectionaccordingtoArt.21
(1)GDPR,whichreads:
Thedatasubjectshallhavetherighttoobject,ongroundsrelatingtohisorherparticularsituation,
atanytimetoprocessingofpersonaldataconcerninghimorherwhichisbasedonpoint(e)or(f)of
Article 6 (1) GDPR, including profiling based on those provisions. The controller shall no longer
processthepersonaldataunlessthecontrollerdemonstratescompellinglegitimategroundsforthe
processing which override the interests, rights and freedoms of the data subject or for the
establishment,exerciseordefenceoflegalclaims.
c) Performanceofacontract
Thereisneitherapossibilityofanobjectionnorcananyconsentbewithdrawn.
Insum,
- theleastriskisinvolvedwithdataprocessingrequiredtoperformacontract;- thesecondbestoptionisdataprocessingclaimingalegitimateinterest,shouldtherebeany,
asthisgivesthedatacontrollerarighttodefenditsposition;- thehighestriskisinvolvedwithconsentasthewithdrawalmustbeacceptedbythedata
controller.
NOTE:Whenreferenceismadetoperformanceofacontractinthispaper,thismeansperformance
ofthecontractwiththeregistrant,note.g.contractualrequirementsinthecontractswithICANN.
4. Compliancerequirements
ICANNhas published a statement onNov. 2nd explaining that ICANNContractual Compliancewill
defer takingactionagainstany registryor registrar fornoncompliancewithcontractualobligations
relatedtothehandlingofregistrationdata,seehttps://www.icann.org/resources/pages/contractual-
compliance-statement-2017-11-02-en.
ICANNalsoindicatedthatguidanceontheprocessandeligibilitycriteriawillbeprovidedshortly.
Absentanyguidanceatthetimeofdraftingofthispaper,weassumethat
11
- ICANNContractualCompliancewillnotonlydefertakingactionbasedonnoncompliancerelatedtoregistrationdata,butwithrespecttoanypersonaldatasubjecttoGDPR.ThispaperspeakstoallpersonaldataandsuchapproachshouldnotcauseissueswithICANNContractualCompliance.
- ICANNwillsupporttheapproachtakenforthispapernottolimitthelegalassessmentofdataprocessingtoonlyonelegalbasis,butinsteadsupportamodeltoallowforbestpossibleriskmitigationandcompliance.
5. AlayeredmodelBasedontheabovefindings,thedatamodeldescribedinthispaperwillbebasedonthreedatarisk
levels (DRL).Minimizing the risk forallparties involved isnecessarynotonly toavoidsanctionsby
authorities, but also toensure thatdomainname registrations canbeupheldand to limit the risk
thatdataelementsmustberemovedfromsystemsoperatedbydifferentparties.Thelevelsare:
DRL1–Lowrisk–Performanceofacontract
DRL2–Mediumrisk–Legitimateinterest
DRL3–Highrisk-Consent
Asafirststep,itneedstobeestablishedwhatdataisnecessaryforregistriestoregisterandresolve
domainnames(“RegistryMinimumDatarecord”),aswellasaminimumsetofdatathatisnecessary
forregistrarstocompletethedomainnameregistrationprocess(“RegistrarMinimumDatarecord”).
ThatdatafallsintoDRL1.
Please note these data recordsmay vary based on the requirements particularly of the registries.
Some registries have nexus or other eligibility requirements, while others don’t, to give just one
example.However,suchdatawouldstillfallintoDRL1asitisrequiredtoperformthecontract.
MoreprocessingfallsintotheDRL1categoryasdetailedinthispaper,suchasthetransferofdatato
anEscrowAgentforbackuppurposes.
As a second step, we will analyze what processing can be based on a legitimate interest. This is
particularlyrelevanttothequestionofdisclosing/publishingdataviaWhoisorotherwise.
12
Sinceprocessingbasedonconsentbearsahighriskfortheparties involvedandmightnotevenbe
possible for certain types of processing, the model described in this paper will not make any
suggestions for consent-based processing. However, it is possible that parties involved introduce
suchprocessing,butconsent-basedprocessingshouldnotbemandatorilyrequiredbyICANNdueto
theassociatedrisks.
Inthisdocument,youwillfindadescriptionofthejourneyofthevariousdataelements.
The data involved is a subset of the data elements currently required to be processed by ICANN
contractsandpolicies.
Youwill find a proposal for DRL1, DRL2 andDRL3 data aswell as information on the roles of the
parties,e.g.whoisdataprocessorandwhoisdatacontroller.Thisinformationisrequiredtoenable
the parties involved to inform the data subjects accordingly and thereby fulfill information and
transparencyrequirements.
Wewillexplainwhywethinkthesolutionofferedisdefendable.However,wedonotclaimthatthe
solutionofferedistheonlysolutionimaginable.
Thesolutionofferedwillbeofferedforcommentandconsultation.Itcouldbeusedonanas-isbasis
for the interimphaseuntil such timewhen thepolicydevelopmentprocess to reflect theGDPR is
completed.Ideally,itwouldbeusedasthebasisforalong-termsolutionforacompliantgTLDeco-
system.
6. Internationaltransfers
Pleasenote that this paper does not elaborate on international data transfers and the safeguards
thatmustbe inplace for those tobe legal.Usinge.g.EUmodelclausesorPrivacyShielddoesnot
maketheprocessingofdatacompliantingeneralandtheprocessingdescribedinthispaperdoesnot
maketherequirementforsafeguardstocoverinternationaltransfersredundant.
Inotherwords:WhereverdataistransferredoutsidetheEU,thatneedstobelookedatbothwhenit
comes to data transfers between registrants, resellers, registrars, registries, escrow agents, the
13
EBEROandICANNaswellwhenitcomestodisclosurerequestswheretherequestorisbasedoutside
theEU.
14
Part B – Processing of data for domain registrations andmaintainingdomainregistrations
I. Registrationandmanagementofthedomainname
Thefirststepillustratesthedatarequiredbythevariousparticipants(seeillustrationbelow)
withinthescopeofregistrationandmaintainingadomaintocomplywiththeircontractual
obligations.
1. Currentdatarecords
In its contracts and policies, ICANN specifies the data to be collected and provided by
participants.Belowweaccordinglyshowtherelevantdatainthisrespect.2
Notethatnodifferentiationismadehereastothespecificdatatobecollectedandprovided
byeachparticipant.
Alldataelementscurrentlyrequired
DomainName
RegistryDomainID
RegistrarWhoisServer
RegistrarURL
UpdatedDate
CreationDate
RegistryExpiryDate
RegistrarRegistrationExpirationDate
Registrar
RegistrarIANAID
RegistrarAbuseContactEmail
RegistrarAbuseContactPhone
Reseller
2https://www.icann.org/en/system/files/files/draft-gdpr-dataflow-template-registration-data-elements-29jun17-en.pdf
15
DomainStatus
RegistryRegistrantIDRegistrantFields
• Name • Organization(opt.) • Street • City • State/province • Postalcode • Country • Phone • Phoneext(opt.) • Fax(opt.) • Faxext(opt.) • Email 2ndE-Mailaddress
AdminIDAdminFields
• Name • Organization(opt.) • Street • City • State/province • Postalcode • Country • Phone • Phoneext(opt.) • Fax(opt.) • Faxext(opt.) • Email
TechIDTechFields
• Name • Organization(opt.) • Street • City • State/province • Postalcode • Country • Phone • Phoneext(opt.)
16
• Fax(opt.) • Faxext(opt.) • Email
BillingIDBillingFields(notapplicabletoallregistries)
• Name • Organization(opt.) • Street • City • State/province • Postalcode • Country • Phone • Phoneext(opt.) • Fax(opt.) • Faxext(opt.) • Email
NameServer
DNSSEC
NameServerIPAddress
LastUpdateofWhoisDatabaseOTHER DATA Transfer Contact Drivers License Transfer Contact Passport Transfer Contact Military ID Transfer Contact State/Government Issued ID Transfer Contact Birth Certificate Registrar Primary Contact Name Registrar Primary Contact Address Registrar Primary Contact Phone Number Registrar Primary Contact Fax Number Registrar Primary Contact Email Address Name and Contact Information of Shareholders with 5% ownership interest in Registrar Full name, contact information, and position of all directors of the Registrar Full name, contact information, and position of all officers of the Registrar Ultimate parent entity of the Registrar, if applicable List of Registrars’ Resellers Registrant IP Address
17
Maintainer URL The ENS_AuthId identifying the authorization of the registration Last Transferred Date Name server status Any other registry data that registrar submitted to registry operator Types of domain name services purchased for use in connection with the registration “Card on file,” current period third party transaction number, or other recurring payment data Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor Log files, billing records and, … other records containing communications source and destination information, including, depending on the method of transmission and without limitation: (1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle, or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration
Log files and, … other records associated with the Registration containing dates, times, and time zones of communications and sessions, including initial registration Privacy/Proxy Customer contact information Those objects necessary in order to offer all of the approved Registry Services
To facilitateunderstanding, theabovedataelementscanbecategorizedasshown in the following
illustration.
18
It is our recommendation not to abandon the thick registry data model. Also, we will not
recommendanychangestobemadetotheindividualdataelements/fields.However,thebelow
analysiswill show,which of the data elementsmentioned above can legitimately collected and
howtheycanbeprocessed.Wheredataelementscannotbeprocessed,therespectivedatafields
willbepopulatedwithsyntacticallycorrectplaceholderdatafortechnicalreasons.
2. ICANNrequirementsAccordingtothedatamodelproposedwiththisdocument,ICANNshallandcanspecifythedatato
becollectedwithobligatoryeffectfortheparticipants,becauseevenifthedataincategoryDRL1is
generallynecessaryfortherespectiveparticipantstoprovidetheirservice,itisalsonecessaryforthe
stabilityandfunctionalityoftheoveralldomainsystemthattheparticipantsareinanycaseobligated
byICANNtocollectandprovidethisdata.Thus,theprocessingofDRL1datashallbemandatoryand
enforcedbyICANN.
Withregardtotheresponsibilityoftherelevantparticipantsunderdataprotectionlaw,referenceis
madetoClauseIINo.3ofthisdocument.
19
II. DRL1 registrar and registry data without additional
eligibility/nexuscriteria
All data that the various participants must mandatorily collect and process for the purpose of
contract fulfillment are contained in DRL1 (see Illustration below). A distinction must be made
betweentheregistrarandtheregistry,whichrequiredifferentdataforthefulfillmentoftheirtasks.
Itishereassumedthattheregistrydoesnothaveanyfurtherspecificrequirementsforaregistration.
Thedataelementsintheredboxesarenotrequiredtobecollected.Thedataelementsinthegreen
boxesshallbecollected.Furthercommentonthedataelementsintheyellowboxwillbeprovided
below.
Authorization
Art. 6 I b) GDPR allows the processing of personal data for the fulfillment or performance of a
contractwhosepartyisthecontractualperson.Inthisrespect,thedatamandatorilyrequiredforthe
fulfillmentoftheregistrationorderarelegitimatelyprocessedthroughArt.6Ib)GDPR.
20
1. Registrar
a) Necessarydatarecord–registrar
Definition“necessary“:
Processing is necessary for contract fulfillment if the contract could not be fulfilled without
processingthedatatotheassertedextent.
The registrar is the contractual partner of the registrant with regard to the registration of the
domain.Withinthescopeoftheregistrant’sorder,theregistrarwillstriveforregistrationwiththe
relevantregistryandmaintainsuchfortheregistrantaftersuccessfulregistration.
Thefollowingdataelementsareobligatoryforexecutionoftheorderbytheregistrar:
aa)RegistrationDataRegistrar
DomainName
RegistrarWhoisServer
RegistrarURL
UpdatedDate
CreationDate
RegistryExpiryDate
RegistrarRegistrationExpirationDate
Registrar
RegistrarIANAID
RegistrarAbuseContactEmail,mustberolecontact
RegistrarAbuseContactPhone,mustberolecontact
DomainStatusRegistrantFields
• Name • Organization(opt.) • Street • City • State/province • Postalcode • Country • Phone • Phoneext(opt.)
Kommentiert [A1]: Headingwasupdated
Kommentiert [A2]: Headingwasremoved
21
• Fax(opt.) • Faxext(opt.) • Email
Registrants may be natural or legal persons. Therefore, the question arises whether enterprise
data must be treated differently than data from private persons as registrants. The different
treatment however bears significant risks because enterprise namesmay also contain personal
referencesanda self-identificationof the registrant in this respectwouldnot result ina reliable
distributionofdatainventory.Inthisrespect,adifferentiationbetweennaturalandlegalpersons
shouldnotbemade.
However,inputfromDPAsshouldbesoughtwhetheradistinctioncouldbemadebasedonaself-
identificationbytheregistrant.Shouldthatbeanacceptablesafeguard,differenttreatmentcould
beconsidered.
bb)TechnicalData
Theregistrarcollectsthefollowingtechnicaldatafromtheregistranttopasssuchontotheregistry
so that the registry can setupdomain registrationon the technical side in thecorresponding top-
leveldomainnamespace.
NameServer
DNSSEC
NameServerIPAddress
LastUpdateofWhoisDatabase
cc)AccountingData
Inadditiontoregistrationdata,theregistrarwillalsocollectinvoicedataofthecontractualpartner,
which is not mandatorily identical to the registrant data. The account data of the registrant or
anotherlistedobligeeunderthecontractmayalsobecollectedandprocessed.Thisisnecessaryfor
thecollectionofregistrationandprocessingfeesunderthecontract.
Furthermore, the registrarwill also retain available incomingpayments aswell as correspondence
witharegistrantorcontractualpartnerinacustomeraccountorothercustomer-specificdatabase.
22
Thisdataisnecessaryforproperperformanceofthecontract.Asageneralrulethispertainstothe
followingdata:
• Bankdata
• Customerdata(insofarasdifferentfromregistrant’sdata)
Billingdata
ICANNobligation
AspecificationbyICANNonthecollectionandprocessingofthisdataisnotappropriatebecausethis
dataisnotnecessaryformaintenanceandstabilityoftheDNS.Onlytheregistrarrequiresthestated
dataforitsperformanceofthecontractvis-a-visacontractualpartner.Inthisrespect,acompulsory
specification to store this data by ICANN is not necessary to maintain the DNS. To this extent,
collectionandprocessingofthedatafieldsfollowingfromthedataretentionspecificationshouldnot
be compulsory by ICANN. Rather, applicable statutory regulations exist to the relevant registrar
regarding the obligation to collect and retain data, which should be applied. This data may be
requested from customers, so that nodisadvantages should exist, e.g. for prosecution authorities,
with legitimate collection and storage. Processing at the behest of ICANN might result in a joint
controllersituation(see3bbb(iv)of ICANNwiththeconsequencethat ICANNwouldbear liability
risksforthesedataelements,which,however,doesnotappeartobeinitsbestinterest.
Specifically,thispertainstothefollowingdataelements:
Any other registry data that registrar submitted to registry operator Types of domain name services purchased for use in connection with the registration “Card on file,” current period third party transaction number, or other recurring payment data Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor Log files, billing records and, … other records containing communications source and destination information, including, depending on the method of transmission and without limitation: (1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle, or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration
23
Log files and, … other records associated with the Registration containing dates, times, and time zones of communications and sessions, including initial registration
BasicSetup:DataRiskLevel1>Registrar
Dataelementsshouldnotbecollectedandprocessed/retainedforICANN
CertaindataelementsareprocessedbytheRegistrarfortheir?Purposeandneedtoberetainedaccordingtoapplicablelaws.NoneedforanICANNrequirement.GoodforICANN;noriskinvolved
Thedatainthedataretentionschedulemightbecollectedandprocessedbyregistrarsaccordingto
applicablelegalrequirements,buttheyshouldnotbemandatedbyICANN.
dd)Admin,Tech,andBillingContacts
Theprovisionof admin, tech,orbilling contactdata s isnotnecessary in termsofArt. 6 (1) lit. b)
GDPRbecausetheyarenotnecessarytoperformregistrationforeithertheregistrarortheregistry.
Thedatafieldscurrentlyrequiredinthisrespectcanbedeletedwithoutsubstitution.
ee)FurtherData
Registrarprimarycontact
In light of further data retained by the registrarwith regard to domain registration, the “registrar
primary contact”data record recordedby the registrar itself still is relevantunderdataprotection
law. The registrar’s own employee data disclosed here by the registrar itself for contacting is
necessary for fulfillment of the contract to offer the registrant opportunity for contactwithin the
scopeofthecontract.
24
b) Reasons
aa)Contractprocessing
Theregistrarmustbeabletoallocateaspecificdomaintoaspecificcustomertomanageandprocess
its internal contract handling. In this respect it is necessary that the registrar can allocate the
domainsregisteredthroughitsservicetospecificcustomerstoallocateandimplementinquiriesand
requests within the scope of domain management pursuant to the actual owner or authorized
person.
bb)Contacting/Transferissues
The registrar must furthermore be able to contact its customers within the scope of current
contracts.With respect todomain registrations,aquickandeasyaccess to registrants isherealso
necessaryincaseofproblemsorotheranomalieswithregardtothedomainname.3
Thecurrentprocedurefordomainnametransfersviaemailcommunicationcannotbecontinueddue
toGDPR requirements.Atpresent,e-mails canbesent to theAdmin-C toget transfers confirmed.
AbsentAdmin-Cdatabeingcollected,thetransferprocessneedstoberevised.Additionally,ascan
beseeninPartCofthisdocument,theregistrant’se-mailaddresswillnotbepublishedanymore.
Therefore,wesuggesttoestablishanewsystembasedonsecureauth-codeswiththepossibilityto
revoke transferswithin a reasonable timeframe. For such, the disclosure of the registrant´s email
address in a public Whois is no longer required. This way, the principle of data minimization is
fulfilled.Alternatively,transferscanstillbecarriedoutwithouthavingane-mailaddresspublishedby
meansofcommunicationbetweentheregistrars.SincetheInterRegistrarTransferPolicyallowsfor
contactingeithertheregistrantortheadmin-ce-mailaddress,itwouldneedtobeclarifiedthatonly
theregistrante-mailaddressmustbeusedfortransfers.
Weshouldnotethatregistrars indiscussionsaboutnewwaystofacilitatetransfersatpresentthat
couldcontributetoasolution.
3Overallinthisrespectseehttps://www.icann.org/resources/pages/gtld-registration-dataflow-matrix-2017-07-24-en
25
cc)Abuse
Thismayalsoincludecasesinwhichthedomainisabusedexternallybythirdpartiesaswellascases
inwhichitissuspectedthattheregistrantitselfperformsaninfringingact.Theregistrarmustfurther
also be able to fulfill legitimate claims of third partieswith regard to the domain or the relevant
registrant.Inthisrespect,thereisfrequentlyaneedtoquicklyestablishcontactthecustomer.
dd)Ownershipposition
The registrar has an interest to quickly and directly contact the registrant in case of disputes
concerning factualand legitimateownershipof theregistrantwithregardtothedomainand/or to
haveownershipconfirmedbythelistedowner.
ee)Transfers
Evenintheeventofatransfertoanotherregistrarandinquiriesorrequestsreceivedinthisrespect,
itmay be in the registrar’s (and registrant’s) interest if the registrar in case of doubt can quickly
contacttheregistrant.
ff)Result
Forthispartofdomainmanagement,itiscorrespondinglynecessaryfortheregistrartocollectand
storetheregistrant’sfullcontactdata.
Unfeasibledomainregistration
Since theregistrarhasnoguaranteethata registrationcan in factbeperformedby theregistry, it
may occur that the registrar has already collected the registrant’s data but that a domain is
ultimatelynotregistered.
In this case, data collectionmay be justified even if a registration can ultimately not be executed
because the justification pursuant to Art. 6 I b) GDPR also captures precontractual measures.
Furthermore, the registrar’s effort to register represents the content of the order vis-à-vis the
registrant,sothatcontractfulfillmentmeasuresexistwithregardtofulfillmentofthiscontract,but
notpre-contractualmeasures.
26
2. Registry
a) Necessarydatarecord–registry
ThroughtherelevantRRA,theregistry istheregistrar’scontractualpartnerandresponsibleforthe
technicalimplementationofdomainregistrationsandtheirmaintenance.Intheprocess,theregistry
particularly reviews the availability of a domain name, registration of a domain name, and
subsequentlythetechnicalavailabilityofthedomainnamethroughtheDNS.
Thefollowingdataiscompulsoryfortheregistrytoperformregistrationandtomaintainthesame,
andmustbecollectedbytheregistrarandtransferredtotheregistry:
RegistrationData-Registry
DomainName
RegistryDomainID
RegistrarWhoisServer
RegistrarURL
Kommentiert [A3]: Headingwaschanged
27
UpdatedDate
CreationDate
RegistryExpiryDate
Registrar
RegistrarIANAID
RegistrarAbuseContactEmail,mustberolecontact
RegistrarAbuseContactPhone,mustberolecontact
DomainStatus
From data protection aspects, only the domain name is relevant for the registry as potentially
personaldata.
However, there has been a policy development process including all ICANN stakeholders
confirming by way of a consensus policy that is binding for all contracted parties, that a thick
Whoismodel shouldbemaintainedbyall registries.Reasonshavebeenarchivaland restoration
purposesaswellasimprovingthedataquality.WeareseekinginputfromtheDPAswhethersuch
policy can be used as a justification for the transfer of registrant data from the registrar to the
registryandforsuchrequirementtobeenforceablebyICANN.Thatdoesnotmeanthatsuchdata
shallbeavailableviaapublicWhoisservice.
Thesameappliestotechnicaldata,whichisrequiredfortheregistrytoperformregistrationandto
maintaintheconnection:
NameServer
DNSSEC
NameServerIPAddress
LastUpdateofWhoisDatabase
Theremainingdata,inparticularthedatapertainingtotheregistrar,doesnotconstitutedatathatis
identifiableorthatpertainstoanidentifiednaturalperson,sothatthisdatacurrentlyisnotrelevant
underdataprotectionlaw.
28
aa)Qualificationofthedomainnameaspersonaldata
Adomainnamemaybepersonaldata intermsoftheGDPR.Thedifferentiationastowhetherthe
relevantdomainrepresentspersonaldataornotcausesmajorproblemsinpractice,thereforeweare
consideringalldomainnamestobepersonaldatawithinthescopeofthisopinion.
PursuanttoArt.4no.(1)GDPR,“personaldata”meansany informationrelatingtoanidentifiedor
identifiable natural person (“data subject”); an identifiable natural person is one who can be
identified, directly or indirectly, in particular by reference to an identifier such as a name, an
identification number, location data, an online identifier or to one or more factors specific to the
physical,physiological,genetic,mental,economic,culturalorsocialidentityofthatnaturalperson.
Adomainnameisdatathatisallocatedtoaspecificpersonorenterprise.Assoonastheownerofa
domainisanaturalperson,thedomainnamethereforeconstitutesdatapertainingtoanidentifiable
naturalperson.Thefactthattheidentificationoftheregistrantunderthemodelshownhereisnot
easilydirectlypossiblebytheregistryitselfhasnoeffectonthequalificationaspersonaldata.
29
Inthisrespect,theEuropeanCourtofJustice(ECJ)concerningasimilarcasesituation4–thestorage
ofdynamicIPaddressesofvisitorsatwebsitesofofficialauthorities-hasruledthatwithregardto
thequalificationaspersonaldataitisirrelevantthatthisdatacannotbeallocatedtoanaturalperson
bythecollectingorstoringentityitself.PursuanttothejudgmentoftheECJ,theidentifiabilityofthe
personbehindthedataisalreadysufficient.Withregardtothevariantofanofficialauthoritystoring
thedynamicIPaddress,referencewasmadetothedisclosureoftheconnectiontoanaturalperson
inparticularthroughtheinformationprocessesvis-à-vistherelevanttelecommunicationprovider.
Followingthisreasoning,adomainnameisalsodatathatinthepresentmodelcanbedisclosedby
theregistrar.
By limiting theprotectionof theGDPR tonaturalpersons (seepreviousdefinitionofArt.4no. (1)
GDPR),onlydomainnameswithnaturalpersonsasregistrantswouldbesubjecttotheprotectionof
the GDPR. However, this gives rise to potential allocation problems on several levels. Firstly, the
registrydoesnotknowwhethertheregistrantofadomainnameisanaturaloralegalperson.This
disclosureinthepresentmodelisspecificallypossibleonlybytheregistrar.
Evenwithaclearallocationofthedomainnametoanaturalorlegalperson,thedomainnameitself
maycontainnamecomponentsofanaturalpersonandthuspersonalreferences.Furthermore,the
protective scopeof theGDPRmaybeopenalsowith regard to legalpersons, if and insofaras the
enterprisenameofa legalperson itselfmaycontainnamecomponentsenablinganallocationtoa
naturalperson.
bb)Result
Basedontheseuncertainties,alldomainnamesmustbetreatedasiftheyconstitutedpersonaldata
in terms of GDPR. This, on the one hand, specifically circumvents potential delimitation problems
whileontheotherhandensuringsufficientdataprotectionundertheGDPRforeachdomainname.
ThedomainnamesonDNSserversareequallyaffectedbythis.
4ECJ,judgmentof19October2016,C-582/14
30
b)Reasons
The authorization to process this data follows from Art. 6 (1) lit. b) GDPR, because they are
compulsoryforcontractfulfillment-registrationandallocationofthedomainnametoaspecificIP
address.
The listeddata iscompulsory for theregistry to registerandconnect thedomain.Registrationand
connectionofthedomainisnotpossiblewithoutreceivingthedomainname.Consequently,thisalso
appliestomaintainingtheallocationofthedomainaswellasprocessingthedomainnameonDNS
servers,theoperationofwhichisalsotechnicallycompulsoryforcontractfulfillment.
3. DatacontrollerWithinthescopeofthesuggesteddatamodel,thequestionarisesastowhotheresponsibleentityis
forprocessingDRL1registrationdata,inparticularbecauseonlyveryfewdataareforwardedbythe
registrartotheregistryinordertobestimplementtheprincipleofdataminimization.Indetail,the
question arises as towhether joint or separate control exists on the side of the registrar and the
registryorwhetheraprocessorsituationexists.
a) DefinitionsArt.4no.(7)andno.(2)GDPRController is the person that alone or jointly with others determines the purpose and means of
processing.Processing,inturnis“anyoperationorsetofoperationswhichisperformedonpersonal
dataoronsetsofpersonaldata,whetherornotbyautomatedmeans,suchascollection,recording,
organization,structuring,storage,adaptationoralteration,retrieval,consultation,use,disclosureby
transmission, dissemination or otherwise making available, alignment or combination, restriction,
erasureordestruction“.
b) Jointresponsibility(Art.26GDPRinconjunctionwithArt.4no.(7)GDPR)
31
JointControllers:DataRiskLevel1
Controller
Theprerequisiteforajointresponsibilityofregistry,registrar,andICANNisthatalljointlydetermine
thepurposesandmeansforprocessing.
aa)Hamiltonopinion
TheHamiltoncommissionedbyICANNstatesthatduetothecomplexityofprocessingstructuresitis
recommended to assume joint responsibility between ICANN, registrar, and registry (Memoradum
gTLDRegistrationDirectoryServiceandtheGDPR,Part1,Section3.7.3),alsobecausethisresultsin
themostextensiveliability,whichalsosufficientlysatisfiestheinterestsofsupervisoryauthorities.
bb)Comment
Pursuant to Art. 4 no. (7) GDPR “controller” means the natural or legal person, public authority,
agencyorotherbodywhich,aloneorjointlywithothers,determinesthepurposesandmeansofthe
processingofpersonaldata;wherethepurposesandmeansofsuchprocessingaredeterminedby
UnionorMemberStatelaw,thecontrollerorthespecificcriteriaforitsnominationmaybeprovided
forbyUnionorMemberStatelaw.
Art. 26 GDPR specifies the joint responsibility in the manner that those jointly determining the
purposesandmeansofprocessingshallberesponsible (“JointController”).Decision-makingpower
concerningpurposeandmeansofprocessingisdecisivefordeterminingresponsibility.
32
(i)Differentiationofprocessorvs.controller
Incontrasttojointcontrollers,processorsdonothavefreedomtomakedecisionswithregardtothe
purposesandmeansofprocessingbutactforthecontractorwithadutytocomplywithinstructions.
Insofarastheagentshaveoptionstoselectordesignthepurposeormeansofprocessing,theyare
considered to be controllers jointly with the contractor and correspondingly have additional
obligations.5
Thepurposeof processing is an “expected result that is intendedor guides planned actions”. The
meansofprocessingisthe“typeandmannerinwhicharesultorobjectiveisachieved”6.
Processorsmustbedifferentiatedfromjointcontrollersbasedonthefollowingcriteria:
• Apersonthathasnolegalorfactualinfluenceonthedecisionconcerningthepurposesforandmannerinwhichpersonaldataisprocessedcannotbeacontroller.
• Apersonthataloneorjointlywithothersdecidesonthepurposesofprocessingisalwaysacontroller.
• Thecontrollermayalsodelegatethedecisionconcerningthemeansofprocessingtotheprocessoraslongascontent-relateddecisions,e.g.concerningthelegitimacyofprocessing,arereservedforthecontroller.
• Processorsareindependentlegalpersonsthataredifferentfromthecontrollerandwhichprocessdataonbehalfofthecontroller(s)withoutdecidingonthepurposesofprocessing.7
(ii)PurposeofArt.26GDPR
The regulation is to primarily serve the protection of the rights and freedoms of data subjects.8
Specifically with regard to complex constellations, a clearer allocation of responsibilities is to be
guaranteed for data subjects. In more complex role allocations, e.g. in the area of domain
registrationwithseveraldistributionlevels,thedatasubject’srightofaccessandotherrightsareto
beguaranteedacrosslevels.9
“Thedefinitionoftheterm“processing”listedinArticle2lit.boftheguidelinedoesnotexcludethe
optionthatdiverseactorsparticipateindiverseoperationsorsetsofoperationsinconnectionwith
personal data. These operations can be executed simultaneously or in diverse stages. In such a
complexenvironmentitisevenmoreimportantthatrolesandresponsibilitiescanbeeasilyallocated
5KlabundeinEhmann/Selmayr„Datenschutz-Grundverordnung“Art.4marg.no.296Art.29DataProtectionWorkingParty,Statement1/2010of16February2010,p.16,availableathttp://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_de.pdf7Art.29DataProtectionWorkingParty,Statement1/2010of16February2010,p.18,39,40,availableathttp://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_de.pdf8BertmanninEhmann/Selmayr„Datenschutz-Grundverordnung“Art.26,marg.no.19Art.29DataProtectionWorkingParty,Statement1/2010of16February2010,p.27,availableathttp://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_de.pdf
33
to ensure that the complexity of joint control does not result in an impractical division of
responsibilitythatwouldaffecttheeffectivenessofdataprotectionlaw.”10
Recital79GDPRfurthermoreclarifiesthattheregulationistosimplifymonitoringbythesupervisory
authorities.
The factual control of the data process as well as control over external effects vis-à-vis the data
subjectisdecisivewhenreviewingresponsibility.
Only the registrar appears vis-à-vis the registrant as it coordinates the complete handling of the
registrationandmaintenanceofit.Theregistryhandlestechnicalimplementationoftheregistration
andreviewsspecialrequirementsconcerningregistration(eligibilitycriteria),insofarassuchexist.
Equaldistributionisnotnecessarywhenallocatingresponsibility.
(iii)Setofoperations
Further, processing should not be artificially divided into smaller processing steps but can be
uniformly considered as a set of operations. In this respect, data collection, passing on to the
registry,reviewandimplementationandongoingmanagementoftheregistrationcanbeconsidered
asonesetofoperations“domainregistration”becauseitpursuestheoverallpurposeofregistering
thedomainforanewregistrant.
This also applies if diverse agencies pursue different purposeswithin the scope of the processing
chainof smallerprocessingsteps indetailonamicro level.Onamacro level, thesamepurpose is
pursued overall,with all small steps in the chain so that a uniform set of operations applies here
specifically(Art.29GroupWP169,p.25).
Theoperationofcollectingandprocessingthedatacollectedbytheregistrarfromitscustomers in
order to create an invoice, to maintain a customer account, and to manage the contractual
relationshipwithitscustomersmustbedifferentiatedhere.Thisdatafulfilsanotherpurposethatis
notcodeterminedbytheregistry.
10Art.29DataProtectionWorkingParty,Statement1/2010of16February2010,p.22,availableathttp://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_de.pdf
34
(iv)Assessment
Registry, registrar, and ICANN must be assessed as joint controllers for the set of operations of
domainregistration,Art.4no. (7)GDPR.Duetothefactualand legalseparationbetweenregistrar
andregistry,adomainregistrationcanmandatorilybeperformedonlybybothentitiesjointly.
In this respect itmust be assumed that registrar and registry jointly determine the purposes and
meansof processing that are compulsory for domain registrationoverall. In this respect, both are
responsibleforthissetofoperationspursuanttoArt.4no.(7)and26GDPR.
This also corresponds to the legislative intent to have clear and simple regulations concerning
responsibility in caseofmultiple participants and complexprocessing structures, and toprevent a
splittingofresponsibilitiestoprotectthedatasubjectsinsofaraspossible.
PursuanttoArticle1Section1.1oftheICANNbylaws,ICANNisresponsible
“toensurethestableandsecureoperationoftheInternet'suniqueidentifiersystemsasdescribedin
thisSection1.1(a)(the"Mission").Specifically,ICANN:
(i)CoordinatestheallocationandassignmentofnamesintherootzoneoftheDomainNameSystem
("DNS")andcoordinatesthedevelopmentandimplementationofpoliciesconcerningtheregistration
ofsecond-leveldomainnamesingenerictop-leveldomains("gTLDs").Inthisrole,ICANN'sscopeisto
coordinatethedevelopmentandimplementationofpolicies:
• Forwhichuniformorcoordinatedresolutionisreasonablynecessarytofacilitatetheopenness,interoperability,resilience,securityand/orstabilityoftheDNSincluding,withrespecttogTLDregistrarsandregistries,policiesintheareasdescribedinAnnexG-1andAnnexG-2;and”
Asalreadystated,ICANNfulfilsthisresponsibilityamongotherthingsbycontractuallyspecifyingvis-
à-visthevariousparticipantsthedatawhichmustmandatorilybecollectedandretained.Withthese
legitimateprovisions,ICANNspecifiesapurposefortheprocessingoperationoverallandthus
becomesjointcontrollerinadditiontoregistryandregistrar.
35
(v)Legalconsequence
Asalegalconsequence,Art.26GDPRreferencesthatthecontrollersreachaclearunderstandingin
particular with regard to their performance of their duties under the GDPR as well as their joint
controlandmustdiscloseit.
(1) Liability
The question arises as to how registry and registrar under joint control are liable for possible
breachesintheprocessingoperation.
(2) Datasubject’sclaims
Pursuanttojointresponsibility,thedatasubjectpursuanttoArt.26(3)GDPRmayasageneralrule
fullyassertitsclaimsvis-à-visallcontrollers,regardlessofthecontractualallocation.
Evenwithacleardistributionof theresponsibilitybetweenthecontrollers,bothare liablevis-à-vis
externalpartiesfortheoverallprocessingoperation.
In this respect,Art. 82 (4)GDPRmandates joint and several liability for thedata subject’s right to
compensationandsupplementstheliabilityregulationsofArt.26(3)GDPR.Thefactualresponsibility
maybe adjustedonly inter partes. Therefore, having clear allocationsbetween theparties is even
moreimportantinterpartes.
(3) Fines
However,suchjointandseveralliabilitydoesnotapplytofinesunderArt.83(4)lit.a)GDPR.Inthis
respect,registryandregistrarareliablepursuanttotheirroleallocationforbreachesintheirareaor
against duties under the GDPR, which were incumbent upon them within the scope of the
contractualbasis.
(4) Agreement
Jointcontrollersmust furthermorespecify, ina transparent form,whofulfillswhichdutiesvis-à-vis
thedatasubjects,aswellaswhothecontactpointfordatasubject’srightsis,Art.26(1)p.2GDPR.
However,thedatasubject isauthorizedtoaddressanyoftheparticipatingresponsibleagenciesto
assertitsrights,regardlessofthespecificationconcerningcompetence,Art.26(3)GDPR.
TheagreementistoregulatethespecificcontrollersthataretofulfillthedutiesprescribedbyGDPR.
PursuanttoRecital79GDPR,itistobespecificallyregulatedinatransparentform
• howtherelationsandfunctionsofthecontrollersamongeachotheraredesigned• howrolesaredistributedbetweencontrollerstofulfilldatasubjectrightsofregistrants,
36
• againstwhichcontrollerssupervisoryauthoritiesexecutesupervisoryandmonitoringmeasures.
Allcontrollersmustfulfill informationobligations independentlyfromeachother.However,Art.26
GDPRsuggeststhatmultiplecontrollersfulfillinformationobligationscentrally.
(5) Jointcontactpoint
GDPRsuggeststhatajointcontactpointissetupfordatasubjects;however,thisisnotcompulsory.
It is suggested that this contact point is located at the registrar, because the registrar maintains
contacttotheregistrant.
(6) Procedurerecord
Further, pursuant to Art. 30GDPR, each controllermust separately list his joint controllers in the
recordofprocessingactivities.
cc)Responsibilityforotherdata
Customer data collected by the registrar merely for its own purposes is solely within the
responsibilityof theregistrar. In this respect,no jointdecision ismadeconcerningthepurposesof
processing.Here,onlytheregistrardeterminesthepurposeofprocessing.
CantheRegistraradddataelements?
NoinvolvementofRegistry,ICANN,orEscrowAgents
Attheirownrisk
37
III. DRL1registrarandregistrywitheligibility/nexusrequirements
1. Obligation
Specific requirements that are necessary for registration under the relevant TLD (e.g. .law, .nrw,
.berlin, etc.) exist. In this respect, there are TLDs with eligibility requirements (e.g. .law,
.versicherung, .autos, .organic and .bank) where verification of the admission as an attorney or
similarisnecessaryforregistrationauthorizationundertheTLD,e.g.for.law/.abogado.Additionally,
there are TLDs with nexus requirements (e.g. .berlin and .paris), where a geographical reference
mustbegivenforregistrationauthorizationundertherelevantTLD.Today,therearemorethan200
gTLDsthataremarkedas“restricted”.Inthisrespect,additionaldataisnecessaryfortheregistriesin
order to review the registration authorization under these TLDs or have the validation done by a
validationagentactingontheirbehalf.
Evenmoredataelementscanbeaddedbytheregistry,whicharenotbelongingtoDRL1.However,
allregistryrequirementsgoingbeyondtheminimumdatasetneedtobeexplicitlyspelledoutinthe
RRA. Where no such requirement is in the RRA, the registrar will not collect or transfer to the
registry.
2. Purpose
Thepurposeoftheseadditionalrequirementsfortheregistrationauthorizationservestoprotectthe
requirements of the relevant TLD system. For example, only admitted attorneys and professional
38
legal associations (law firms, law schools, bar associations, and courts) are permitted and located
withregardtoeligibilityrequirementsundertheTLD“.law“and“.abogado“.Thiscreatesanexclusive
online space for Internetusers thatpromotes trust in theprofessional legal associationandoffers
Internet users the security to find information from admitted attorneys and professional legal
associations.
TLDswithnexusrequirementscreateanonlinespaceforInternetusersinwhichtheycantrustthat
therelevantoffershaveageographicalreferencetotherelevantTLD.
The purpose of the respective additional necessary data consists specifically in maintaining the
exclusivity of these relevant online spaces and to offer sustainable added value to providers and
usersoftheseoffersbymaintainingquality.
Here, the relevant verification requirements aredependenton the respectiveTLDand the specific
requirements to the verification. Due to the multitude of TLDs and their requirements it is not
possibletoillustrateallTLDsandtheiradditionalrequirementstoregistrationauthorizationineach
individual case here, thuswe can only offer an abstract and generalized illustration for additional
requesteddata.
3. ResponsibilityTheresponsibilityfortheadditionalrequesteddataforverificationoftheregistrationauthorization
lies with the registry because the registry specifies the requirements concerning the relevant
verification.Thisalsoappliestooutsourcingofthereviewofrequirementsspecifiedbytheregistryto
avalidationagent.Becauseeven if thereview,whenusingavalidationagent, isnotperformedby
theregistryitself,itinanycaseisperformedonbehalfandattheinstructionoftheregistryvis-à-vis
thevalidationagent.Thevalidationagentinthisrespectistheprocessoroftheregistryintermsof
performingthereviewoftheverificationoftheregistrationauthorization.
When collecting and transmitting the additional requested data, the registrar also acts exclusively
upon instructionof the registry, so that the registrar isprocessorof the registry for thisadditional
dataaswell.Theregistrardoesnothaveowninterestsintheseadditionaldataoranydiscretionof
itsownconcerningthepurposeormeansofcollectionandtransmissionoftheadditionalrequested
data.
39
4. AuthorizationThe registries are authorized to demand all data required to review the registration authorization
pursuanttoArt.6(1)lit.b)GDPR.
Theadditionalrequesteddata isalso justifiablynecessarydata. Incomparisontothedatarequired
by ICANNforall registries, theadditionaldatarequiredherebytheregistries is justifiablyrequired
data because the respective additional required data for the relevant TLDs with eligibility/nexus
requirementsarerequiredspecificallytoperformtheregistrationauthorizationundertheseTLDs.In
the process, these additional requirements specifically fulfill the purpose of creating an exclusive
online space inwhich providers aswell as users can profit particularly from the exclusivity of this
onlinespaceandtheresultingtrustintherelevantoffers.Therequirementsforadditionaldataare
thereforefullyjustified.
Under theprincipleofdataminimization pursuant toArt. 5 (1) lit. c)GDPR, contractperformance
also requiresa transmissionof theadditionaldata requestedby the registry to the same,because
thisconstitutesacompulsoryprerequisitetoreviewtheregistrationauthorization.Outsourcingthe
reviewoftheregistrationauthorizationtotheregistrarinamannerthattheregistrarindependently
determines the means and purposes of the collection of the additional requirements for the
registrationauthorizationaswellasanindependentreviewoftheadditionalrequirementsatitsown
responsibilityunderdataprotectionlawisnotfeasible,becauseinthisrespectitisincumbentupon
the relevant registry to itself ensure the existence of the requirements placed by itself to the
registrationauthorization.
Furthermore,inthisrespectitisalsonecessarythattheregistryincaseofnotificationofapossible
caseoffraudisabletoreviewtherelevantauthorizationcriteriabasedonthesubmitteddocuments.
IV. DataEscrow
1. ObligationBased on Clause 3.6 of the RAA 2013, the registrar (for gTLDs) is obligated to pass on the data
retained with regard to the registered domain to a neutral third-party (“escrow agent”). All data
stored at the relevant registrar shall be continuously passedon. BasedonClause 2.3 of theRA in
40
conjunctionwith the “specification 2” of theRA, the registry is obligated topass its own retained
dataontoanescrowagent.
2. Purpose/necessityICANN is responsible for security, stability, and resiliency of the DNS. Tomeet this responsibility,
ICANNamongotherthingsimposedthestatedobligationsthroughtheregistry/registrardataescrow
program.This is tospecificallycreateaprotectionforregistrarsagainst lossorunavailabilityofthe
domainregistrationdata.
3. RegistrarDataispassedontosafeguardthedomainsystemintheeventthataregistrarfailsduetoanerror,
problem, or possible discontinuation of business. A loss of domain registrations or allocation
problemsinlightofaspecificdomainforacertainperiodistobeprevented(cf.RegisterFly),because
theclearallocationisalsocompulsoryandworthyofprotectionforeconomicreasons.
Thesameappliestotheregistrydataavailableattheregistry.
4. AffecteddataTofulfilthepurposeofsafeguardingitisofcoursenecessarythatallregistrationdataretainedbythe
registrarwith regard to the registereddomains is transmitted to thedesignated thirdparty. In the
presentmodel,thedatacollectedandstoredinDRL1isspecificallyreducedtotheabsoluteminimum
necessaryquantity. In this respect, logically, the transmissionof all thisdata is also compulsory to
achieve the purpose of safeguarding in the event of a loss. This applies equivalently to the data
retainedbytheregistry.
Inthiscontext,however,itisnotnecessarytotransmitcustomeraccountdataretainedbyaspecific
registrarforitscustomersforhandlingthecontractualrelationshiptotheescrowagent.Intheevent
thataregistrarfailsandtheretaineddatafromtheescrowagentmustbetransmittedtoICANNor
anotherregistrar.
5. ResponsibilityAsdescribed,ICANNbearsresponsibilityforthesecurity,stability,andresiliencyoftheDNS.Inthis
respect, ICANNdeterminesthepurposeoftheprocessingoperation“dataescrow”.Theregistrarin
thisrespectimplementstherequirementsofICANNandmerelyhastheinterestoffulfillingitsown
contract vis-à-vis ICANN concerning data transmission to the escrow agent, but has no real own
41
interestwith regard to security and stability of the domain system in the event of its failure. This
appliesequallytotheregistry.
With regards to registrar as well as for registry escrows, escrow agents as data controllers are
thereforeprocessorsforICANN.
ItshouldbenotedthatICANNmustonlypassondatareceivedfromtheEscrowAgenttoagaining
registrarortheEBEROafterhavingverifiedthatthegainingentityisGDPRcompliant.
ProcessorController
6. AuthorizationDataforwardingtotheescrowagentrequireslegallegitimacy.Thespecificrequirementsaredeemed
tobelegitimatebecausetherequirementsofICANNvis-à-vistheregistrarandregistryarenecessary
tosafeguardthedomainsystem.Inthisrespect,dataforwardingbytheregistrarandtheregistryto
theescrowagentsisnecessaryforfulfillmentofthecontractandjustifiedthroughArt.6(1)b)GDPR.
V. EBERO
1. Obligation
42
Asalreadystated,ICANNisresponsibleforsecurity,stability,andresiliencyoftheDNS.ICANNwishes
tomeet this responsibilitywith EBEROs. In caseof emergencyeventsof a registry failure, EBEROs
providethebackendservicesfortheoperationofaTLDoriginallyprovidedbytheregistry.
In emergency events, the data archived by the registry at the escrow agent is transmitted to the
sameuponinstructionbyICANNandfromittotheEBERO.
As soon as and insofar as any emergency event occurs that affects data of data subjects that is
retainedattheescrowserviceandfallsundertheGDPR,aGDPR-conformEBEROisnecessary.
2. Affecteddata
Pursuanttothedatamodelpresentedherebyus,theescrowagentretainsonlythedatadeposited
bytheregistryitself(seeabovePartBII.2.).Tofulfillthepurposeofguaranteeingtheoperationof
theregistry, it isofcoursenecessary thatalldata thenretainedat theescrowagent is transferred
through ICANNtothedesignatedEBERO. In thesuggestedmodel, thedatacollectedandstored in
DRL1isreducedtotheabsoluteminimumnecessaryquantity.Insofar,thetransferofallthisdatais
logicallyalsocompulsorytomaintainthepurposeofsafeguardingintheeventofafailure/fault.
3. Responsibility
TheresponsibilitywithregardtoalldatatransferredtothedesignatedEBEROlieswith ICANN.The
EBERO in this respectwill also become active at the instruction of ICANN and does not have any
discretionofitsown,sothattheEBEROisactiveasaprocessorofICANN.
43
ProcessorController
VI. ResellersituationInsofarasthedomainregistrationorderisreceivedbytheregistrarthroughareseller(oramultitude
ofresellers),variousdataprocessingoperationswithvariousresponsibilitiesexist.
1. Responsibility
Theresellercollects thesamedataat theregistrant that theregistrarwouldalsocollectdirectly 11
andthusinparttakestheplaceoftheregistrar.However,theresellershallnotandcannotreplace
the registrar because only the registrar is accredited and also contractually affiliated with the
relevantregistries.
Accordingly, theresellerenters intotherelationshipwiththecustomer insteadof theregistrarbut
cannotreplaceitwithregardtodomainregistration.Therefore,itmustbequalifiedasaprocessorof
theregistrar.
11SeeabovePartBII.1.
44
ProcessorController
a) AccountData
Inthisregard,thecontractualpartner’saccountdata iscollectedbytheresellerat itsowninterest
and for the purposes of performing its contractual relationship with the contractual partner.
Accordingly,theresellerhereisthesolecontrollerfordataprocessing.
b) Registrationdata
Theresellercollectsregistrationdatafromtheregistrantforthepurposeofdomainregistration. In
theprocess,theresellercollectsexclusivelythedatanecessaryforregistration.Therelevantregistry
and the registrar determine this data and therefore they chiefly decide on the purposes of data
processing.
Accordingly,theregistry,theregistrar,andICANNarejointcontrollersevenincaseswhereresellers
areinvolved.
Jointresponsibilitywiththeresellerwouldherenotbeinthebestinterestbecausetheresellerdoes
not codetermine the purpose of processing but only executes that which the other participants
requireinthisrespect.
Theresellercollectsthisdatainsteadoftheregistrarandthusonitsbehalf;intheprocessitactsonly
upon the registrar’s instruction and transmits the collected data for registration, which can be
performedonlybytheregistrar,toit.Inthisrespect,theresellerisaprocessorfortheregistrar.
45
2. ResellerchainsIntheeventofmultipleresellersinsequence,theresellerindirectcontactwiththeregistrantisthe
processor and the registrar is the contractor as described above. The additional resellers utilized
betweenthetwothereforearesubcontractorsof therespective reseller,becauseallparties in the
chain are active merely pursuant to the original instruction of the registrar with regard to the
registrationdata.
VII. DRL2–Transferofregistrantdatatotheregistry
IntheDRL2category,indeviationfromthepresentmodelforDRL1,amoreextensivetransmission
ofdatafromtheregistrartotheregistrytakesplace.Inthismodel,theregistrymightwishtoreceive
alltheregistrantfields:
RegistrantFields• Name • Organization(opt.) • Street • City • State/province • Postalcode • Country • Phone • Phoneext(opt.) • Fax(opt.) • Faxext(opt.) • Email
Theremightbeotherdatathattheregistrymightclaimtobeabletoprocessbasedonalegitimate
interest. Here, we have used the example of security checks to establish patterns of abusive /
criminalbehavior.
46
1. AuthorizationThedatalistedhereisnotdatathathasobligatorynecessityforcontractfulfillmentunderthemodel
suggested here. A justification of this processing under Art. 6 (1) b) GDPR as data necessary for
contractfulfillmentisthereforenottakenintoconsideration.
ThisdataisthusprocessedbasedonArt.6(1)lit.f)GDPR.
PursuanttoArt.6(1)lit.f)GDPRprocessingisnecessaryforthepurposesofthelegitimateinterests
pursued by the controller or by a third party, except where such interests are overridden by the
interestsorfundamentalrightsandfreedomsofthedatasubjectwhichrequireprotectionofpersonal
data,inparticularwherethedatasubjectisachild.
The permissibility of processing therefore depends on the legitimate interests of the controller,
whichmustdominatewithinthescopeofabalancingthedatasubject’sprotectedinterests.
Various purposes are considered by the registries, inwhich a balancing decision of the legitimate
interestsprevailsovertheprotectedinterestsofnon-processing.
a) MitigatingAbuse
Alegitimateinterestoftheregistrytoalsoreceivetheregistrant’sdatalistedabovemayfollowfrom
thefactthatcertainpatternsattheregistereddomainsmustbereceivedforasuccessfulmitigation
of abuse within the scope of the registration of domains. In this respect it may specifically be
necessary that the registry for this purpose receivesdataof all registrants fromvarious registrars.
Otherwise, an effective abuse control could not take place because the individual registrars could
only review their own registrants’ data for possible abuse. Extensive monitoring and sustainable
recognition of patternswould be impossible. Pursuant to Recital 47 p. 6 GDPR, the processing of
personal data to the extent that is compulsory for the prevention of fraud constitutes a justified
interestoftherelevantcontroller.
b) Centralmanagement
The centralmanagement in termof an equivalent to a commercial register, land register, or birth
registeraswellasthepatentandtrademarkregistermayalsobeseenasanotherlegitimateinterest.
47
Insofar as the registrydesires the centralmanagementof thedataof all registrants, this couldbe
definedasacentralmanagementlocationandmanagementofacentralregister.
The registry as responsible entity for the namespace operated by it can also assert a legitimate
interest in the ability of allocating and identifying the relevant registrants for which it provides
servicesundertheresponsibilityforthenamespace.Intheprocess,centralmanagementalwaysalso
brings with it certain advantages, e.g. maintaining data accuracy in one location. Technical and
organizationalmeasures tomaintain confidentiality and integrity of this datamay in this case be
takenbytheregistryitselfatitsownresponsibility.
Thisalsodoesnotcontradict thedataminimizationprincipal standardized inArt.5 (1) lit. c)GDPR
becauseinthisrespecttheregistryisalsojustifiedtoretainthisdatabasedonthepurposeofcentral
managementandprocessingofdatabytheregistryaswell.Basedonitsowninterestforcentraldata
management,theregistryalsohasalegitimatepurposefordataprocessingthatexceedsthepurpose
underDRL1.
2. ResponsibilityTheresponsibilityforcollectionandtransferofthisdatafromtheregistrartotheregistryliesinthis
casewiththeregistry.
Inthisrespect,theregistrarisactiveinthecollectionofthepreviouslylisteddatarecordswithadual
purpose,becauseitreceivesthedataforitselfanditsowncontractfulfillmentontheonehand,but
on the other hand also collects this data at the instruction of the registry. The registrar therefore
collectsthedataatitsownresponsibilityandsimultaneouslyasaprocessorfortheregistry.
The informationobligationunderArt. 14GDPR in this respect in particular applies to the registry,
becausethecollectionoftheregistrants’dataisnotdirectlycollectedbytheregistrybutthedatais
collectedbytheregistrarandtransferredtotheregistry.
3. RiskIntheprocessingofpersonaldatabasedonabalancingdecisionunderArt.6(1)lit.f)GDPR,thedata
subject is entitled to a right to object pursuant to Art. 21 GDPR. Art. 21 GDPR requires “grounds
relatingtohisorherparticularsituation”fromthedatasubjecttoexerciseitsrighttoobject.
48
The requirements that are to be placed to the special situation are currently not foreseeable.
However, it nowalready follows from the formulation “particular situation” that in comparison to
otherconstellations,significantlyhigherrequirementswillbeplacedundertheGDPR.
When asserting such a particular situation, the responsible entity then generally must stop
processing the personal data unless it can verify compulsory grounds worthy of protection for
processing, which outweigh the interests, rights, and freedoms of the data subject or serve to
processtheassertion,exercise,ordefenseoflegalclaims.
4. ConclusionThecollectionofdataby theregistrarand forwardingto theregistrypursuant toDRL2takesplace
exclusivelyandtotheextentasprovidedbytheregistry,subjecttothejustifiedinterestintheRRA.
Thisistogivetheregistrartheopportunityofreviewingtheplausibilityofajustifiedinterest.
If theregistrydoesnotspecifyparticularrequirements inthisrespect, theregistrarmuststopdata
processing. Iftheregistrar isoftheopinionthattheinformationconcerningjustifiedinterest isnot
sustainable,registryandregistrarmustclarifythisbywayofnegotiation.Ifajustifiedinterestexists
onthesideoftheregistry,data isprocessedbytheregistrar infulfillmentofthecontractwiththe
registry,i.e.theRRA.
Under no circumstances should the processing of data be specified or enforced pursuant to this
regulationbyICANN.
VIII. DRL3–Datacollectedbasedonconsent
Evenwithregardtodataminimizationandthedatamodeldescribedabove,theremaybeaspecific
interestforregistriestoobtain(anddisclose)personaldatainexcesstothedescribeddatasets,e.g.
someregistrantsmaywishtopublishtheirdatainapublicWhoisdirectorytoincreasetrustintheir
services.Suchspecial interestsbyregistries(orotherparticipants)canonlybelegitimizedbasedon
consentbythedatasubjectsasalloftheprovisionsmentionedabovedonotapply.
SuchdataprocessesarealwayspossibleincaseavalidconsentasrequiredbyGDPRiscollectedfrom
thedatasubject.
49
PartC–DisclosureofData
Mostregistriesoperateaso-calledThickWhois.While,fromatechnicalpointofview,thismodelis
to be maintained, fewer data fields are populated and, unless the registry defines special
requirements,thedataoftheregistrantisalsonotpassedontotheregistry.Therefore,thequestion
is to what recipient requests for information are to be addressed and how such requests can be
answered. As already discussed, all procedures relating to the processing of personal data must
complywith theprincipleofdataminimization.Thus,a registrywouldonlybeable toprovide less
datainthecontextofaWhoisserviceofsomekindthanaregistrar.
In order to allow for the consistent provision of information, information from different sources
shouldbecompiledbymeansofRDAP(delegatedWhois).Furthermore,itneedstobeclarifiedthat,
evenat thispoint, registriesandregistrarsmighthavemore information thantheyprovidevia the
Whoisservice.However,disclosureaccordingtothispaper,wouldonlygoasfarasrevealingthe
registrantdatafieldsascurrentlyshowninthepublicWhois.Thatmeansthatdataofaprivacyor
proxyservicewillbeshownwheretheregistrantusessuchservices.Disclosurebyprivacyorproxy
serviceswouldbebasedontheprinciplesappliedtodayandremainunaffected.
Inaccordancewiththisprinciple,itisexaminedwhichinformationmayberetrievedpubliclyorinthe
contextof inquirers informing themselves andwhich informationmustbe subjected toa separate
assessmentbeforebeingreleased.Furthermore,wewould liketopointoutthatthetermWhois is
usedbothfortheWhoisprotocolandtheWhoisdata.Inthecontextofthispaper,weusetheterm
merelywithregardtothedata,since,asatechnicalvehicle,RDAPispreferablefortheprovisionof
thedataovertheWhoisprotocol.
I.NoJustificationforaPublicWHOISundGDPRAlreadyunderthecurrentEuropeanlegaldataprotectionframework,therearedoubtsastowhether
ornotthepublicationofpersonaldataofdomainownersviaapubliclyaccessibleWHOISdatabaseis
admissible.However,oncetheGDPRcomesintoeffectinMay2018,itwillhavetobeassumedthat
theWHOISdatabaseswillnotbeabletocontinuetoexistintheircurrentform.12
12 cf. Nygren/Stenbeck, gTLD Registration Directory Services and the GDPR - Part 1, p.10 ff.;Voigt/Pieper,ImpactoftheGDPRregardingWHOISsystem,p.3etseqq.
50
1. LegallyIneffectiveConsentSection 3.7.7.5, the RAA 2013 requires that the registrant must consent to the data processing.
However,therearesignificantdoubtsastowhethersuchconsentwillstillbeabletobeconsidered
legallyvalid.
AccordingtoArt.4no.11GDPR,consentofthedatasubjectmeans
“any freely given, specific, informed and unambiguous indication of the data subject’s
wishes by which he or she, by a statement or by a clear affirmative action, signifies
agreementtotheprocessingofpersonaldatarelatingtohimorher”.
Inaddition,Art.7(4)GDPRfurtherstatesthat,
"whenassessingwhetherconsent is freelygiven,utmostaccountshallbetakenofwhether,
interalia,theperformanceofacontract, includingtheprovisionofaservice, isconditional
onconsenttotheprocessingofpersonaldatathatisnotnecessaryfortheperformanceof
thatcontract."
This provision prevents that data controllers withhold or offer a degraded version of service for
subjects who refuse or (later) withdraw consent. Consent based on the contractual obligation
(Section3.7.7.5,theRAA2013)willthereforenotbevalid.
2. NoJustificationunderStatutoryLawLikewise,noneofthestatutorycircumstancesoftheGDPRisabletojustifytheWhoisdirectoryinits
currentform,inwhichalldataismadeavailableonlinetothegeneralpublic.
The publication of data in a freely accessible directory is not necessary for the performance of
contractualrelationbetweentheregistrantandtheregistrar/registrysothatajustificationunderArt.
6(1)lit.b)GDPRisnotpossible.
Furthermore,contrarytowhatisthecaseforpublictrademarkandcommercialregisters,thereisno
specific legal basis legitimizing or even requiring the operation of a public domain directory. The
51
organizationofinternetcommunicationsand,therefore,alsoofdomainregistrationhasalwaysbeen
performed on the basis of private legal relationships. This is why a public regulatory framework,
whichwoulde.g.alsorequireforapublicdirectory,doesnotexist.Consequently,itcannotbeargued
thatapublicWhoiscanbejustifiedunderArt.6(1)lit.e)GDPR.Thedefinitionofpublicinterestsis
alsosubjecttolegislativeaction,whichhasnottakenplaceinrelationtoapubliclyaccessibleWhois
data.
Ultimately,thecurrentpublicWHOISdirectorywillalsonotbeabletobejustifiedonthebasisofArt.
6 (1) lit. f) GDPR. The circumstances described therein require a weighing of the interests in the
respectivedataprocessingontheonehandandtheinterestsofdatasubjectontheotherhandona
case-by-casebasis.Itistruethatthereisavarietyofreasonswhycertainauthorities,individualsor
groups of individuals have profound interest in accessing Whois data and therefore leading to a
justificationofdisclosure (e.g. for identificationof apersonwhohas registereda certaindomain)
underGDPR.13However,theseindividualinterestsdonotjustifythepublicationofpersonaldataina
publicly accessibleWHOISdirectory, since thepublication is not necessary for other purposes and
towardspersonsotherthantheholderofalegitimateinterest.
Forthesereasons,aclosedWHOISsystemwhichcanbeaccessedinindividualcasesonly(namelyifa
justificationunderdataprotectionlawexists)and/orfromwhichinformationisprovidedinindividual
caseswillberequiredonceGDPRentersintoeffect.Compliancewiththeprovisionsoftheregulation
isparticularly importantforanyproviderofaWhoisdatabase,asviolationscanresult insignificant
fines.
II.LegalGroundsforDisclosureofRegistrationDatato3rdPartiesTheEWGfinalreporthasestablishedalistofWhoisusersandtheirrespectiveinterestsinaccessing
Whoisdata14.ThegTLDRegistrationDataflowMatrixandInformationdocumentalsolistsusersand
usecases15,allofwhichhavebeenreviewedbythedraftingteamofthispaper.However,asoutlined
above,requestsforinformationfromallthoseusergroupsrequirealegalgroundfortheproviderof
aWhoisdatabase fordisclosure.Firstofall, thecriteria for individual requestsaretobeexamined13 cf. in this regard ICANN: EWG final report on gTLD Directory Services, available at:https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf; ICANN: Draft dTLD RegistrationDataflow Matrix and Information, available at: https://www.icann.org/en/system/files/files/gdpr-dataflow-matrix-whois-11sep17-en.pdf.14ICANN:EWGfinalreportongTLDDirectoryServices,p.21.15ICANN:DraftdTLDRegistrationDataflowMatrixandInformation.
52
(1.). Ina second step,aprocedure forhandling information requests inpractice is tobeproposed
(2.).Finally,weprovideaproposalforaTrustedDataClearingHouseforthedomainindustry(3.).
1. LegalGroundsandCriteriaforDisclosureTherearedifferentgroupsof3rdpartieswhichmayhaveaninterestinthedisclosureofregistration
data.DisclosurethroughdatatransferisatypeofdataprocessingwithinthescopeofArt.4no.(2)
GDPR.Art.6GDPRexhaustivelynamestheprerequisitesunderwhichtheprocessingofpersonaldata
shallbelawful.IntherelevantcontexthereArt.6(1)lit.b),c)andf)GDPRarecrucial.Inthisregard,
it makes sense to distinguish between 3rd parties from the public and the private sector,
respectively,asdifferentlegalgroundshavetobeconsidered.
a) Art.6(1)lit.b)GDPR-PerformanceofaContract–(PrivateSectorOnly)
AccordingtoArticle6(1)lit.b)GDPRdisclosurecanbejustifiedwhere
"processingisnecessaryfortheperformanceofacontracttowhichthedatasubjectisparty
orinordertotakestepsattherequestofthedatasubjectpriorenteringintoacontract."
The contractual basis of domain registration also contains, inter alia, provisions that subject
registrants tocertainconflict resolutionregimes.Totheextentnecessary for theseprograms,data
processing including disclosure of personal data is therefore admissible. This especially concerns
these following two programs that are included in the contractual relationship between the
registrantandtheregistrar/registry:
• UniformDomainNameDisputeResolutionServiceforGenericTop-LevelDomains(UDRP)
• UniformRapidSuspensionSystem(URS)
Totheextentthatthedisclosureofpersonaldataisrequiredwithintheseprocedures, inparticular
for the preparation of claims or inquiries by anyone who credibly demonstrates to have a legal
positionsubjecttotheseprograms,WhoisdatamaybedisclosedonthebasisofArt.6(1)b)GDPR.16
16Pleasenotethatthislegalassessmentdoesnotconcernthequestionofwhethersuchanagreementcanbelegallyvalidlyagreedbetweentheparties,butrelatessolelytoquestionsofEuropeandataprotectionlaw.
53
b) Art.6(1)lit.c)GDPR(PublicSectorOnly)
ItisjustifiedunderArt.6(1)c)GDPRtotheextentnecessaryforcompliancewithalegalobligationto
which the controller is subject. Art. 6 (1) c) GDPR itself does not constitute a legal basis for data
processing, but instead requires a corresponding legal basis in the laws of the EUor theMember
States.17 From this, it canbe inferred that legal provisionsof third-party countrieswhichhavenot
beenadoptedby theEUor the relevantMemberState, forexampleby transforming international
treatiesintonationallaw,cannottriggeranylegalobligationwithinthescopeofArt.6(1)c)GDPR.
Therefore,ajustificationofdisclosurerequestsofpublicauthoritiesofnon-EUstatesonthebasisof
Art.6(1)c)GDPRcannotbejustified.Duetotheglobaldomainnamesystemandthefactthatnon-
European law enforcement authorities also have interests in registration data, which, at least
theoretically,mightalsocontaindataofEUcitizens,thisconstitutesatremendouschallengetothe
properdesignofaconsistentdisclosureprocess.
"Legal obligations" in the meaning of Art. 6 (1) lit. c) GDPR do not necessarily require acts of
parliament.18Therefore,differentkindsofsubstantivelawprovisionscanbeconsideredaslegalbasis
for disclosure (e.g. regulations and statutes on the basis of which public authorities such as law
enforcementauthoritiesorfinancialauthoritiesaregivencompetencesorinvestigationrights).Asa
generalrule,thesestatutoryprovisionsmustnotfallshortofthedataprotectionlevelguaranteedby
theGDPR;withtheexceptionofcaseswheretheGDPRitselfprovidesforlimitationsoftherelevant
rights to private life and data protection arising fromArt. 7 and 8 of the Charter of Fundamental
Rightsof theEuropeanUnion. Suchanoption forpossible limitations is providedbyArt. 23GDPR
whichmentions,interalia,nationalandpublicsecurityortheprevention,investigation,detectionor
prosecutionofcriminaloffencesandtheexecutionofcriminalpenaltiesaswellastheprotectionof
otherimportantobjectivessuchastaxationmattersorsocialsecurity.Provisionsregardingthedata
processing by authorities for the purpose of preventing, investigating, detecting or prosecuting
criminal offences aswell as for the execution of criminal penalties are regulated in Directive (EU)
2016/68019.Finally,Art.6(3)GDPRprovidesacatalogueofspecificationswithregardtothecontent
17Recitals40and45.18TherequirementsforthelegalbasisarespecifiedinRecital41;withregardtotheprinciplesofArt.5(1)aGDPR(lawfulness,fairnessandtransparency),theexplanationsinRecital39aretobetakenintoconsideration.19Directive(EU)2016/680oftheEuropeanParliamentandtheCouncilof27April2016ontheprotectionofnaturalpersonswithregardtotheprocessingofpersonaldatabycompetentauthorities forthepurposesofthe prevention, investigation, detection or prosecution of criminal offences or the execution of criminalpenalties,andonthefreemovementofsuchdata,andrepealingCouncilFrameworkDecision2008/977/JHA.ThisdirectivewaspassedtogetherwiththeGDPR,however, it isnotapplicabletoactivitiessubjecttoUnion
54
oftherequiredlegalbasis.Thisexemplarylistcanbeconsultedasaguidelinefortheassessmentof
whetherornotaprovisionsatisfiestherequirementsfora“legalobligation”withinthescopeofArt.
6(1)lit.c)GDPR.
Accordingly,theprovisionshouldspecify
● whichgeneralconditionsgovernthelawfulnessofprocessingbythecontroller,● whichtypesofdataaresubjecttoprocessing,● whichdatasubjectsareconcerned,● towhichentitiesandforwhatpurposesthepersonaldatamaybedisclosed,● whichpurposelimitationthedataissubjectto,● howlongdatamaybestoredand● whichprocessingoperationsandproceduresmaybeused.
Whether and to what extent processing is necessary depends on the purpose for which data is
processed.Therefore,thelegalobligationmustpreciselyspecifythepurpose.20
Itis,ofcourse,notadatacontroller´sobligationtorevieweverypossiblelegalbasisforcompliance
with these requirements.However, theoutlined standardsprovidevaluable indicationsas towhat
standardsinformationrequestsformgovernmentagencieshavetomeet.
For the operationalization of requests from public authorities, we recommend to check for the
followingformalcriteria:
● Therequestingorganizationorauthoritywouldhavetoelectronicallysubmittherequestonaletterheadofitsorganizationshowingwheretherequestforinformationcomesfrom.
● The requestmust showwhich authorized representative has signed the request and howsaidrepresentativecanbecontactedbytelephoneoremail.
● Therequestmustbesigned.● Legalbasesundernationallawmustbespecifiedfromwhichtherighttoviewthedatacan
beinferred.● Itmustbeaffirmedthatthedatawillonlybeviewedandusedinthecontextofthestatutory
competences of the respective organization or public authority, in the case of lawenforcementauthorities,forexample,exclusivelyforpurposesofcriminalprosecution.
law(Art.2(3)bGDPR).SincepublicsecurityisnotgovernedbyUnionlaw,therightsofdatasubjectsmayonlybelimitedbyEUprovisionsoutsidethescopeofpublicsecurity.20Cf.Recital41;alsoconsiderRecital45,pursuanttowhichalawcanalsobethebasisforseveralprocessingoperations.
55
c) Art.6(1)lit.f)GDPR–LegitimateInterests(PrivateSectorOnly)
Insomecases,thedisclosureofWhoisdatamayalsobejustifiedundertheGDPRdueto“legitimate
interests”.AccordingtoArt.6(1)f)GDPR,disclosureofdatacanbejustifiedwhere
"processing is necessary for the purposes of the legitimate interests pursued by the
controllerorbyathirdparty,exceptwheresuchinterestsareoverriddenbytheinterestsor
fundamental rightsand freedomsof thedatasubjectwhich requireprotectionofpersonal
data,inparticularwherethedatasubjectisachild"
Withregardtotheinformationrequestsfromforeignauthorities,therearenodifferencescompared
to the situationunderArt.6 (1) lit. c)GDPR.Disclosureof information to third countryauthorities
cannotbe justified.Recital47demonstrates thatdataprocessingof thepublic sectormustnotbe
basedonlegitimateinterestsbutonalegalbasisunderArt.6(1)lit.c)GDPR:
"Giventhatitisforthelegislatortoprovidebylawforthelegalbasisforpublicauthorities
to process personal data, that legal basis should not apply to the processing by public
authoritiesintheperformanceoftheirtasks."
Nothingdifferentcanapplytoforeignauthorities.Otherwiselowerdataprotectionstandardswould
applyto3rdcountryauthoritiesthantoauthoritiesoftheEUorEUmemberstates.
aa)"LegitimateInterests"
Hardlyanyindicatorscurrentlyexistastohowtheundefinedlegaltermof“legitimateinterest”will
be interpretedbydataprotectionauthoritiesand courts after coming into forceof theGDPR.The
regulationitselfdoesnotcontainadefinitionofthistermandprovidesonlyveryfewindicationson
which interestsmaybedeemedtobe“legitimate”.However, several referencesspeak for the fact
that a broad interpretation of the term can be assumed. Restrictions, proposed in the legislative
process,havenotbeenreflectedinthefinaldraft21.Recital47p.2furthermorementionscustomer
relationsandtheservicerelationshipasexamplesforlegitimateinterests(“e.g.ifthedatasubjectis
acustomerofthecontrollerorinitsservice”)andthusleavesabroadmarginforinterpretation.The
characterofArt.6 (1) lit. f)GDPRasa"catchallelement"alsospeaksforabroadunderstandingof
21cf.Voigt/Pieper:ImpactoftheGDPRregardingWHOISsystems",p.11etseq.
56
theterm.Againstthisbackground,allinterestsincludingfactual,economic,andimmaterialinterests
canbedeemedtobe“legitimate”.
Themain purpose of any data processing operation in connectionwith domain registration is the
provision of the services associated with domain registration within the scope of the contractual
relation. However, the activity of the enterprise participating in domain registration cannot be
reducedtothissingularpurpose.Rather,theregistrationofdomainsisaservice,which-jointlywith
the services of other companies - guarantees the overall functionality of the Internet (namely
conveyingcontentavailableintheWorldWideWeb).Thespecialrolesofregistrarandregistrywithin
this technical ecosystem is also reflectede.g. in the fact that they are subject to certain duties as
operatorsofcriticalinfrastructures.22TheactivityofRegistryandRegistrar-inthislight-alsoserves
otherpurposesbeyondthemeredomainregistrationtocustomers,inparticularalsowithregardto
thefunctionalityofthetechnicalinfrastructureassuch.Registrarandregistrythereforetoacertain
extent also have a regulatory function, which for example may include participation in the
prosecution of violations committed under usage of this ecosystem. Against this background we
would consider processing of data for the purpose of maintaining security measures or technical
analysis (alsooperatedby thirdparty providers) as likely (dependingon the individual case) being
justifiedunderArt.6(1)lit.f)GDPR.
bb)BalancingofInterests
However, 3rdparty interests indataprocessingmustbebalancedagainst the interestsof thedata
subject.Thepersonalrightsofthedatasubjectaswellastheeffectsforthedatasubjectarisingfrom
thisprocessingoftherelevantdataisthestartingpointofthebalancingofinterestwithinthescope
ofArt.6 (1) lit. f)GDPR,which iscontrastedby the interestsof the thirdparty in thespecificdata
processing.Toputitinanutshell:Themoresubstantialtheinterestofthethirdparty,themorelikely
disclosurecanbejustified.
AnimportantindicatorforhowtobalanceinterestsfollowsfromRecital47p.1,3.Accordingtoit,a
balancing of interests must also review whether a data subject at the time of collection of the
personaldataandinlightofthecircumstancesunderwhichitwascollectedcanreasonablyforesee
thataprocessing for thispurposewill possibly takeplace. This generally limits thepossibilities for
22cf.e.g.inGermanlawSec.5oftheCrisisDirectiveoftheGermanFederalOfficeofSecurityinInformationTechnology,BSI-KritisV,implementingDirective2008/114/EC
57
justification of data processing activities based on Art. 6 (1) lit. f GDPR. Although it will not be
possible toclarify theexpectations thatwere tied todataprocessing in thespecific individualcase
(sothatanobjectifyingconsiderationoftheseexpectationsmusttakeplace)itfollowsfromthisthat
processing cannot be justified if it takes place for purposes that were not foreseeable by the
registrant upon registration of the domain. Although the existing Whois system is based on the
registrant'scontractualconsent, itcanbearguedinthiscontextthatregistrantsknowaboutpublic
disclosure (at least of parts of) registrant data and therefore must assume that personal data
providedwhenregisteringthedomainwillbemadepubliclyaccessible.
TheGeneralDataProtectionRegulationitselfprovidesfurtherindicationsastowhichinterestscan,
inprinciple,bedeemedtobejustified.Art.21(1)GDPRexpresslystatestheestablishment,exercise,
ordefenseoflegalclaimsasjustificationfordataprocessingdespiteanobjectionofthedatasubject.
InthecontextofArticle21(1)GDPR,however, it is referredtodataprocessing inthecontextofa
datacontroller´sownclaimsandresponsibilities.However,fromthisstandarditcanalsobeinferred
that European data protection law considers data processing in the context of legal claims as
interestsworthyofprotection.Thismustalsoaffect thebalancingof interestswithin the scopeof
Art.6(1)lit.f)GDPR.
cc)NecessityofDataProcessing
Asageneralrule,disclosureofregistrantdatato3rdpartiescanonlybejustifiedtotheextentthatit
isnecessaryforthefulfillmentoftherespectivelegitimateinterest.Thisprincipleof"necessity"limits
theextentofdatadisclosuretotheminimalmeanswithwhichthepurposeofdataprocessingcanbe
reached.AnydataprocessingexceedingthisextentcannotbejustifiedunderArt.6(1) lit. f)GDPR.
Forthisreasonalone,arestrictionofthedisclosureoftheWHOISdatatothedatacontainedinDRL1
isnecessary.However, thedataprovided inthissetofdata isat thesametimerequiredasabare
minimumtoensurethefulfilledofthelegitimateinterests.23
dd)RighttoObject,Art.21GDPR
UnderArt. 21GDPR, everydata subject is entitled toobject at any timeagainst theprocessingof
personaldatabasedonArt.6 (1) lit. f)GDPRongrounds relating tohisorherparticular situation.
However,thespecific legalmeaningof“particularsituation”remainsopen.Therecitalsalsodonot
contain any further indications.However, itmust be assumed that only atypical constellations fall
23FordetailsonDLR1PartBII.above.
58
underthisclause.Fordatacontrollershowever,theregulationmeansthatitmusttakemeasuresto
ensure a response to the objection of a data subject in the individual case and that this data is
disclosed only if (i) compelling legitimate grounds for the processingwhich override the interests,
rights and freedoms of the data subject or (ii) for the establishment, exercise or defense of legal
claims (of the controller). However, the atypical constellations that authorize an objection in the
individualcaseandthecompulsorygroundsworthyofprotection that in the individualcase justify
thedisclosureofdataissubjecttoacase-to-casereview.
ee)Legitimate3rdPartyInterestsforDisclosureofWhoisData
Against the background of the outlined legal standards, it can be assumed that the balancing of
interestswilltypicallyjustifydisclosureofWhoisdatainthefollowingcontexts:24
3rdpartygroup 3rdpartyinterest CriteriaforDisclosure Datatobedisclosed(IPR)Attorneys Legal action against
(IP)lawinfringements• proof of admission to
thebar• credible
demonstration of lawinfringement relatedtoacertainDomain
DRL1
Consumer ProtectionAssociations
Legal Action againstconsumer protectionlawinfringements
• proofofentitlementtoprosecution ofconsumer protectionlawinfringements
• credibledemonstration ofconsumer protectionlaw infringementrelated to a certaindomain
DRL1
CertificationAuthorities
VerificationofDomainOwnership
• proof of operation ofcertification services(orknowncertificationauthority)
• proof for request forcertification byRegistrant
DRL1
24 Cf. in this regard also Voigt/Pieper: Impact of the GDPR regarding WHOIS systems", p. 16;Nygren/Stenbeck,gTLDRegistrationDirectoryServicesandtheGDPR-Part1,p.13.
59
WeshouldnotethatthelimitationsimposedbyGDPRwillhavesignificantimpactoncompaniesand
individualsworkingon safety and security issues. These limitations shouldbediscussedwithDPAs
withthegoaloffindingsolutionsthatallowforefficientworkonITandnetworksecurity.
d) Otherrequests
With regard to third party requests, the justifications for disclosure of data outlined above are
exhaustive.Anyotherthirdpartyrequests,suchasgeneral inquiriestotheregistrantcannotjustify
disclosureof registrantdata. It is thereforeadvisable that registrarsoffereitherananonymizede-
mailaddressfortheregistrantsviaawebinterfaceorawebformwheremessagesfortheregistrants
canbeenteredandwillthenbeforwardedtotheregistrant’se-mailaddresstoensureanonymity.
e) Note:DataSubject´sRights,Art.12etseq.GDPR
GDPRalsocontainsanumberofsocalleddatasubject´srights.Inparticular,itmustbeensuredthat
theperson,whosepersonalisbeingprocessed(i.e.inparticulartheregistrant)receivesinformation
about his personal data processed by the data controller on request, Art. 15 GDPR. Further data
subject rights refer e.g. to the deletion (Art. 17 GDPR) or rectification (Art. 16 GDPR) of data.
Consequentlyregistriesandregistrarsmustensurecorrespondingprocedures.Themostconvenient
waytoprovidethosefunctionswithinprotectedcustomerareas.
f) Disclaimer
The legal requirements for disclosure of Whois data described above exclusively refer to the
provisionsoftheGDPR.Pleasenotethattheremightbeadditional limitationsofwhatdatacanbe
disclosedundernationallawsacontractedpartymightbesubjectto.Theotherwayaround,lawsof
non-EU member states may entail legal obligations for disclosure of data (e.g. for criminal law
enforcement). The resulting conflictsbetween thedifferent legal systemsarenotpartof the legal
assessmentinthispaper.
2. ProceduralAspects
a)CertificationofPublicAuthorities
Allinall,evenifthecriterialistedaboveareusedasabasisforthedisclosuredecision,theremaystill
bea largevarietyof legalbasesand,therefore,ofpublicauthoritiesactingonthebasisofsuch. In
practice,thiswould leadtotheresultthat, incaseof informationdisclosurerequestssubmittedto
registrars or registries, the assessment of the legal basis to be performed might be extremely
60
complex and difficult and require significant administrative efforts and time, for which quite a
numberofresourceswouldhavetobeprovided.Saideffortandtimeincreaseswiththenumberof
expectedrequests.In2014,forexample,DeutscheTelekom,alone,disclosedtheownersof733,377
IPaddresses,whichinaccordancewithEuropeanlawmustalsobeconsideredpersonaldata,tolaw
enforcementauthorities25.
Inaddition, in caseof the investigationandprosecutionof criminaloffences ithas tobegenerally
assumedthattherequestofthepublicauthorityisurgent.Anindividualassessmentofallrequests
for information would stand in opposition to the urgent need for information of the public
authorities;evenmisjudgmentsoftheassessorcouldnotbeexcluded.
Aregistrationand/orcertificationofpublicauthoritieslenditselfasapossiblesolutionforpreventing
this.Thus,acase-by-caseassessmentbasedonthecriteriashownabovewouldnotbenecessaryand
quickaccessforthepublicauthoritieswouldbeensured.
In this context, in a registration and/or certification process, first of all an assessment based on
formal criteria canbeconducted inorder toassesswhetherornot the respectivepublicauthority
maybeentitleddue toa legalbasis to request informationon theownershipof adomain (at the
same time constitutes justification for data disclosure under Art. 6 (1) lit. c) GDPR for the
registry/registrar).
Afterthecertification,thepublicauthoritieswouldbeabletoviewtheDRL1dataofsuchdomains
whicharerelevante.g.inconnectionwiththeinvestigationofacriminaloffense.
Inapolicyfortheuseofthedata,anypublicauthoritywouldfurthermorebeobligated
● nottoperformabusiveormassdatainquiries,● nottoforwardtheobtaineddatatounauthorizedthirdparties.
Once certification took place on this basis, access toDRL 1 data can be givenwithin the scopeof
termsofuse.
25 Cf. https://www.telekom.com/en/corporate-responsibility/data-protection-data-security/archiv-datenschutznews/news/transparency-report-2014---cooperation-with-government-agencies-362418.
61
Althoughdisclosureofdatawouldnotbestrictlylimitedtoindividualregistrantdata,theeffectsto
theregistrantarisingfromacertificationmodelcomparedtoagenerallypubliclyaccessibleWHOIS
directory significantly lowers the impact on the data subject due to strict access restrictions and
purpose limitations. The impact to the registrant´s right and freedoms can be further reduced by
implementingtechnicalmeasureslike
• limitationtoinquiriesforindividualdomains
• limitationsofthetotalnumbersofqueries
• localizationoftherequestbasedonIPaddress
• theuseofCAPTCHAs
b)CertificationofPrivate3rdParties
Such certificationmodel could also be used for information requests fromprivate 3rd parties. The
certificationprocesswouldneedtofulfillataminimumthefollowingcriteriatojustifydisclosureof
registrantdata:
Firstly,thecertificationwouldfromthestartberestrictedtothelimitedgroupof3rdpartiestypically
havinglegitimateinterestsindisclosureofWhoisdata(asoutlinedabove).
Fortheregistrationitself,theapplicantwouldneedtoprovideevidenceconcerningtheassociation
with one of those 3rd party groups. This may take place e.g. through electronic transfer of an
attorney’sIDcardortheexcerptoftheregisteroftheassociationorthechamberofcommerce,as
wellasprovidingdetails like organization’swebsitesetc.Theprecisemodalitiesofregistrationcan
alsobeorientedtowardtherespectivenationalspecifications(e.g.reviewingthelistinginapublicly
accessibleattorney’sdirectory,ifavailable).
Further, the requestwouldhave tobe filedbyapersonauthorized to represent the respective3rd
partygroup.Inapolicyfortheuseofthedata,anyapplicantwouldfurthermorebeobligated
● nottoperformabusiveormassdatainquiries,● nottoperformdatainquiriesforadvertisementordirectmarketingpurposes;● onlytoviewdataifthisisnecessarytoestablish,exerciseordefendlegalclaims,● nottoforwardtheobtaineddatatounauthorizedthirdparties.
62
Once certification took place on this basis, access toDRL 1 data can be givenwithin the scopeof
termsofuse.
Althoughdisclosureofdatawouldnotbestrictlylimitedtoindividualregistrantdata,theeffectsto
theregistrantarisingfromacertificationmodelcomparedtoagenerallypubliclyaccessibleWHOIS
directory significantly lowers the impact on the data subject due to strict access restrictions and
purpose limitations. The impact to the registrant´s right and freedoms can be further reduced by
implementingtechnicalmeasureslike
• limitationtoinquiriesforindividualdomains
• limitationsofthetotalnumbersofqueries
• localizationoftherequestbasedonIPaddress
• theuseofCAPTCHAs
Note:
RDAPmakes it possible for CAs to issue certificates granting tiered access basedonpre-defined
parameters.Certificationcanthereforebegrantedformultiplecontractedpartiesandmustnotbe
conductedwitheachandeverycontractedparty.
c)LogicalStructureofaDisclosureProcess
IfarequestortypesinaWhoisqueryonadomainname,theWhoisquerywillreturndatathatcomes
fromtheregistrar,including
• Domain Name, Registry Domain ID, RegistrarWhois Server, Registrar URL, Updated Date,
Creation Date, Registry Expiry Date, Registrar, Registrar IANA ID, Registrar Abuse Contact
Email,RegistrarAbuseContactPhone,DomainStatus,NameServer,DNSSEC,NameServerIP
Address,LastUpdateofWhoisDatabase.
In case a requestor is interested in further information about a registered domain, he is provided
withthefollowingoptions:
63
Certifiedusergroupssuchaspublicauthoritiesandthirdpartiesthatcanpresentlegitimateinterests
canaccessDRL1dataviatheCertifiedRequestorProgram:
64
For other general queries where disclosure cannot be justified under GDPR, requestor will be
providedwithananonymizede-mailaddressorawebformfromwhichmessagescanbesenttothe
registrante-mailaddress.
3. ProposalofaTrustedDataClearinghouse(TDC)AGDPRcompliantWHOISsystemmandatorilyresultsinthefactthatamoreefficientprocessmust
be found, which at the same time continues to provide access to the authorities and 3rd parties
outlinedabove.
Theoutlinedprocedureforprocessinginformationrequestswillentailanextremeorganizationaland
procedural effort both for the requesting party aswell as for the responsible entity, because the
inquiring partywould first have to research the competent registrar or registry for the respective
domain towhich itmustaddress its request for information.Therelevantcontactpartnersand its
contactinformationmustthenbediscovered,inparticularinurgentcases.
An expertly qualified and trustworthy instance as a neutral information broker could coordinate
accesstotherelevantWHOISdataandhandletheparties’relevantobligationstodatadisclosureto
unifythisprocessonagloballevelforallplayersparticipatinginit.ThisTrustedDataClearinghouse
(hereinafter“TDC”)wouldoperateaplatformonwhichtheoutlinedregistrationcertificationprocess
would be set up for the identified groupof authorities and 3rd party groups authorized to receive
information.
Only data category DRL 1 would be accessible through this platform. This category includes in
particularnameandcontactdetailsoftheregistrantaswellasthetimeofdomainregistrationand
thusprovideauthorizedentitieswiththeinformationconcerningtheentitythatislegallyresponsible
forregistrationofthedomain.Basedonthis,interestsconcerningpubliclawenforcementaswellas
thelegitimateinterestintheestablishment,exerciseordefenseoflegalclaimsundercivillaw(e.g.to
prosecutecopyrightortrademarkviolations)wouldbepossible.
Further,acommunicationtoolcouldbesetup fornon-certifiedrequestors throughwhichtheTDC
mediatescontacttothedomainownerandleaves ituptothedomainownertoeithercontactthe
inquiringpartyortoconsenttothedisclosureofitsdata.
65
With regard to information for the prosecution of claims under civil law, this system would be
restricted only in cases in which the registrant asserts its right to object under Art. 21 GDPR. As
presentedabove,Europeanregistrantsareentitledtoobjecttotheprocessingoftheirpersonaldata
forgroundsrelatingtotheir“particularsituation”.
The TDC could also handle the processing of these objections. The registrars and registrieswould
provideacorrespondingemailaddresswithinthescopeoftheirobligationtorefertotheexistence
of this right to object in their privacy notice. Any objections received at would then be legally
analyzedby theTDC to reviewwhethera right toobjectexists in the individual case. If that is the
case,datacanbeanonymized,oratleastdisclosureofsuchdatatorequestorscanbedenied.Art.21
(1) GDPR generally provides that the interests of the responsible entity in data processing can in
particularbepredominant if theprocessing serves theassertionof legal claims,but the regulation
heremeanslegalclaimsintherelationshipbetweentheresponsibleentityandthedatasubject,not
legalclaimsofthirdpartiesdecisivehere,e.g.oforiginatorsortrademarkowners.
PartD–Outlook
Ideally,thecontractedpartieswouldagreeonajointdatamodelwithICANN.
Implementationoftheplaybookmodelinatimelyfashionposesanadditionalchallengetoallparties
involved.Technicalimplementationneedstobedone,registryrequirementsneedtobedefinedboth
contractuallyaswellasinEPP.Registrarsmightneedtowaiveorshortennoticeperiodsforchanges
of registry requirements. Itwouldbeadvisable todefinedifferent classesof registry requirements
andcentrallydefineEPPandRRAstandardizedlanguage.
66