Enom Blog -Enom Blog |

Updates from ICANN64 – Kobe, Japan

April 8, 2019

Industry Insight, News

Like

Views: 272

A small delegation from Tucows attended ICANN64 in Kobe, Japan, and we want to share a few quick highlights about the progress made in some key areas.

RDAP Working Group

RDAP, everyone’s favorite new registration data access protocol, is now in the implementation phase. This means that registrars and registries must implement RDAP according to the documented profile requirements by August 26, 2019.

As we’ve mentioned before, Tucows has already implemented the original version, so we’re now reviewing the final profile to understand what minor updates are needed. The RDAP Working Group recognizes that the current profile is based on the Temp Spec and will need to be modified to align with the policy coming out of the EPDP. As members of the RDAP Working Group, we’ll be participating in that process and making sure we’re on top of any further changes.

Access to Whois Registration Data

ICANN’s Technical Study Group on Access to Registration Data, which we’ll refer to as the “TSG,” met with several different groups during ICANN64 to present information about their work and answer questions from the community.

Leading up to the conference, they were focused on developing a “straw man” technical model that uses RDAP to operationalize the EPDP’s upcoming “Standard Access” (Phase 2) Model. The TSG team members confirmed that they do not plan to build the system they are designing; instead, the objective was to create a Model that can be presented to the European Data Protection Board (EDPB) for review and feedback.

ICANN CEO Göran Marby’s idea seems to be that if the EDPB signs off on this Model, registrars and registries could follow it when providing Personal Data to ICANN for disclosure to third parties, and this would bring a reasonable expectation of “diminished liability.” However, many of us are concerned that the EDPB will not be able to base any decision off the TSG’s Model — they would most likely also require the accompanying Policy. This policy does not exist yet — it will come out of the EPDP Phase 2 work — and until it does, any request to have the EDPB review the Model is premature and ineffective.

Additionally, as we were reminded by Cathrin Bauer-Bulst from the European Commission, any statement by the EDPB that the Model is acceptable could easily be retracted in the future; it’s not a guarantee of legality. The TSG team has a face-to-face meeting planned for mid-April to finalize their report, after which it will be handed back to ICANN’s CEO.

Phase 2 of the EPDP & next steps for the IRT

The EPDP team met four times over the course of the ICANN64 conference, primarily focusing on planning for Phase 2 of their work: the creation of a Standard Access Model for disclosure of non-public registration data.

There was also discussion about convening an Implementation Review Team to bring the Phase 1 recommendations into reality and how to bridge the Implementation Gap period between when the Temp Spec expires (May 25 2019) and when the EPDP recommendations become mandatory policy (February 29 2020).

The team is still looking for a new Chair, as Kurt Pritz stepped down following the end of Phase 1. His admirable leadership and calm in the face of contentious issues will be difficult to replace. In the coming days, the EPDP team will continue to work with ICANN leadership to determine exactly how to proceed with these next steps. The Tucows team will be an active voice in that discussion, and we will keep our resellers up-to-date as things develop.

Read More
ICANN Updates: EPDP Phase 1 Final Report

April 3, 2019

Announcement, GDPR, Industry Insight

Like

Views: 236
ICANN’s Expedited Policy Development Process (EPDP) team has issued their Phase 1 Final Report, marking the end of this stage of the project. The recommendations from this Report will become mandatory as of February 29, 2020, but contracted parties (registrars and registries) are permitted to implement them sooner. We’re still determining what specific changes we’ll need to make, but here’s an overview of the expected operational impacts that you should be aware of.

Changes to which data elements are required for ICANN-regulated TLDs

The EPDP team has recommended that:
- the Admin contact no longer be used at all
- the Tech contact be entirely optional and minimized: only name, phone number, and email address.
Needless to say, we are pleased with this outcome. For months now, Tucows has argued against the continued mandatory collection of Admin and Tech contact data, as it violates the GDPR’s requirement for data minimization. We still allow our reseller partners to pass along these data sets, but we only use them if the registry specifically requires them; if they do not, we simply hold these data on our platform and do not share them with the registry or data escrow provider.

How is OpenSRS handling this change?

OpenSRS will need to delete the Admin contacts we hold for existing domains, unless it’s used for a TLD where the registry contractually requires an Admin contact. Before we delete any data, however, we’ll make sure that the registries have made the required changes on their side. This will ensure that no registrations fail at the registry level due to “missing data.” An additional point to consider is that some domains registered under the 2009 RAA rules do not have any associated Registrant contact info, because at the time the domain ownership information was stored in the Admin contact fields. We’ll ensure that the domain owner information is up to date before removing any of the Admin contact data.

What should resellers do?

We’re doing our best to minimize any work these changes could create for resellers. Right now, our suggestion is to audit which fields you currently list as mandatory in any signup and domain update forms that you provide to your customer base. You may need to make some adjustments and be ready to implement them once the recommendations outlined above are officially required. We’ll provide plenty of notice before implementing changes on our end.

Changes to which data are displayed in the public Whois

The public Whois record will continue to be mostly redacted. However, the EPDP has recommended that registrars display the registrant state and country fields. We’ll soon begin work to reflect this change in the Whois data output for all domains under our accreditation.

Special case: publishing registrant Organization Whois data

In theory, the Organization field holds non-personal data, so displaying it in the public Whois should not be an issue. In reality, however, the Organization field frequently does contain personal data. For this reason, the EPDP team has recommended that the Organization field should be published, but only in a way that avoids the accidental exposure of personal data.

So, how will this be accomplished?

Registrars have been asked to contact all existing domain owners to confirm whether or not they want their Organization info published. If the registrant opts in, the registrar can then publish the Organization data. If the registrant does not opt into publication, or does not respond at all, the data in the Organization field can either be kept on file with the registrar but redacted from the public Whois, or deleted entirely.

What should resellers do?

For the long-term, the EPDP team recommends a more proactive approach where a “disclosure, disclaimer or confirmation” is presented to domain owners as they enter data into the Organization field. This notice would explain both options and give the registrant the opportunity to decide if they want this information published or not. If you collect data through an online sign-up form, you may want to consider how to incorporate this notice. We’re considering how to best implement this recommendation in a way that will be clear to domain owners and represent a minimal workload for our resellers.

Changes to which domain name contact data are shared

Much of the heavy lifting here has been done. As part of our initial GDPR implementation last year, we did a full audit of our TLD offerings to determine which data elements should be shared with the registry by default, as required under our contract with the registry, and which should only be shared if the domain owner gives their explicit consent to do so.

Over the next few months, we expect to receive updated contracts from all the ICANN-accredited registries we work with. Depending on what the various registry contracts include, we may make adjustments to our data processing framework. We could end up sharing more or less data by default for specific TLDs, and may stop the collection of some “optional” data elements.

What should resellers do?

These adjustments will not create any work for you, the reseller, but you should be aware that some of the TLD-specific data sharing settings will be adjusted. You can always refer to Tucows’ Data Use Information page for details about the legal basis for processing the data we collect for any TLD.

Next steps

Hopefully, this review has left you with a good sense of what to expect over the coming months. We’ll have more updates as the EPDP team begins Phase 2 (Standard Access Model, formally referred to as the “Unified Access Model”) and works through the Implementation Review Team (IRT) process, which will turn these Phase 1 recommendations into actual policy.
Read More
Why We’re Applying GDPR Protections to Registrants Worldwide

August 8, 2018

GDPR, Industry Insight

Like

Views: 3382
Remember, although we have a great legal team working at Enom, none of what we share here can or should be taken as legal advice.

Among the world’s leading registrars, Tucows, our parent company, is the only one that has redacted all personal data from the public Whois and announced a data use consent management process for registrants worldwide. In making these changes, we’ve disrupted the status quo and encountered resistance from other industry members who would prefer a more conservative solution. But with our nearly two decades’ experience operating as an accredited domain registrar and supporting a large reseller network, we’ve learned that it is imperative to choose proactive solutions and remain focused on how the industry will develop long-term, rather than default to the most simple or convenient option.

We’ve said many times before that we believe individuals around the world have a right to the privacy and protection of their personal data. We’ve also made the more practical argument that while the GDPR may apply only to EU-local individuals, other governments have also passed data protection laws, and we expect more to follow suit. Today, we want to talk about why we remain confident in our approach and place it within the necessary context of worldwide data privacy regulations.

Comparing Regional Privacy Laws

The GDPR has received a lot of attention not because it’s the only law of its kind, but because of its wide scope of applicability and, perhaps first and foremost, the severity of the penalties for non-compliance. There are other, less well-known laws in countries outside of the EU that establish similar data privacy protections. We’ve looked at a few important examples—Canada’s PIPEDA, California’s new Consumer Privacy Act of 2018, and the 2000 Argentina Personal Data Protection Act—to see how they stack up against the GDPR. You can jump to our summary table, which compares their fundamental concepts and relates them back to Enom’s data-processing practices, or continue on below for a high-level overview of each law.

California

The California Consumer Privacy Act of 2018 (AB 375) was signed into law by the state’s Governor on June 29, 2018. This new legislation takes effect in 2020, and many of the protections it extends to Californians will sound familiar to anyone who’s read up on the GDPR. At a high level, the CCP Act aims to ensure:
1. The right of Californians to know what personal information is being collected about them.
2. The right of Californians to know whether their personal information is sold or disclosed and to whom.
3. The right of Californians to say no to the sale of personal information.
4. The right of Californians to access their personal information.
5. The right of Californians to equal service and price, even if they exercise their privacy rights (s.2.i).
The CCP Act has an interesting fundamental difference to the GDPR: the GDPR protects the data, while the CCP Act protects the consumer. The GDPR sets out rights and obligations for Data Controllers, Data Processors, and Data Subjects, while the CCP Act focuses on the rights a consumer has in relation to businesses that process their data. Even with this scope of applicability in mind, it’s very clear that we can expect to see a heightened level of transparency and consumer control over data in California.

These rights under the California Consumer Privacy Act will, of course, be subject to limitations, and the finer details will no doubt shift as government officials and private interest groups work to tighten up data privacy practices in a way that is not detrimental to the Californian businesses that rely on consumer data, including tech giants like Google and Facebook.

It’s both fitting and encouraging that California, a hub for technological innovation, is leading the U.S. movement to protect individual privacy in our digital age. And while there may not be policy in development at the federal level just yet, other American states are well on their way to passing modernized data privacy legislation—check out this handy, albeit, slightly outdated, map for more details. It seems likely that some of the important provisions in California’s Consumer Privacy Act will serve as a template for other state governments looking to establish stricter data privacy laws.

Canada

Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) has been in place since 2000, but an accompanying document, “Guidelines for obtaining meaningful consent,” was just released in its final form on May 24, 2018, shortly before the GDPR came into effect. PIPEDA shares a number of similarities with the GDPR, which these new guidelines serve to highlight.

PIPEDA may not explicitly mention “data minimization,” but it does state that “an organization may collect, use or disclose personal information only for purposes that a reasonable person would consider are appropriate in the circumstances” (Division 1.3). This idea is echoed and expanded in later sections, including “Principle 5 — Limiting Use, Disclosure, and Retention,” which declares that data “shall not be used or disclosed for purposes other than those for which it was collected, except with the consent of the individual or as required by law.” Much like the GDPR, PIPEDA has a clear aim to curb deceitful or indiscriminate data collection.

In addition to restricting what data is processed, PIPEDA also calls for a high level of transparency around how and why data is processed. Its “Openness” principle affords individuals the right to request information about an organization’s data processing policies and practices, such as “a description of the type of personal information held by the organization, including a general account of its use” (Sched. 1 4.8.2). PIPEDA also requires organizations to obtain an individual’s consent before processing personal data, and specifies that this consent is “only valid if it is reasonable to expect that an individual to whom the organization’s activities are directed would understand the nature, purpose and consequences of the collection, use or disclosure of the personal information to which they are consenting” (Div.1, 6.1).

Does this allow for service providers to bury the “nature, purpose and consequences” in the fine print? The word “reasonable” always invites a high degree of subjectivity. But the Office of the Privacy Commissioner of Canada (the “OPC”) released a related document, “Guidelines for obtaining meaningful consent,” which addresses any confusion. It states that “in order for an organization to demonstrate that it has obtained valid consent, pointing to a line buried in a privacy policy will not suffice.” Pretty clear.

These Guidelines (well-summarized here) also put forth an idea quite reminiscent of the GDPR’s distinction between the legal bases of consent and contract. In Canada, individuals must be offered a clear “yes or no” option to consent to data processing. However, an exception to this rule is the collection or disclosure of personal information that’s required, or to quote directly, “integral to the product or service.” The collection or disclosure of such essential data are referred to as “conditions of service,” and can’t be opted out of without opting not to use the service at all. This is very similar to how contract-based data, those data elements which are required in order to provide the service for which they are collected, do not require explicit consent under the GDPR.

The OPC also acknowledges that while some individuals may be content with a quick overview of what personal data is being collected, others will want a greater level of detail about their provider’s privacy and data use practices before making a consent choice. Organizations are encouraged to meet the needs of all users by presenting information in a “layered-format”, or some other method that provides the user with control “over how much detail is provided to them.” Our consent management process embodies this idea. We’ve clearly outlined the how, what, and why of our data collection practices, in a manner that avoids bombarding the reader with inaccessible legalese. Those looking to dive deeper can review our Data Use Information page, which we’ve also designed to be accessible to the average reader.

Argentina

Argentina’s Personal Data Protection Act is also an older data protection law, in effect since 2000. Argentina was the first Latin American nation designated by the EU as having an “adequate level of data protection” as compared to EU requirements.

Argentina’s Data Protection Act is easily comparable to the GDPR, particularly in regard to the latter’s data minimization principle and distinctive treatment of consent- and contract-based data. The Argentine law requires that data collected must be “certain, appropriate, pertinent, and not excessive with reference to the scope within and purpose for which such data were secured” (Chapter 2, s.4.1). In addition to restricting what data can be collected, the Act also states that data must only be kept while it is necessary and relevant to the purposes for which it was initially collected—if it ceases to fulfill these requirements, it must be “destroyed” (s.4.4.7).

These obligations go hand-in-hand with consent requirements: data processing is not permitted without the consent of the individual whose data is being processed, except in certain defined circumstances. The most notable exception to this requirement is the processing of data that arises “from a contractual relationship,” and which is necessary to develop or fulfill that contract. Here again, the consent request cannot be buried in the fine print. It must appear in a “prominent and express manner” (s.5.1).

Argentina is currently working to create updated data protection regulations, which will be “heavily based upon the GDPR.” Thus far, we’ve only been able to locate a Spanish-language version of the updated draft bill, so we are relying on secondary sources for insight into how it compares to its EU equivalent. In a 2017 IAPP article, GDPR matchup: Argentina’s draft Data Protection Act, Pablo A. Palazzi and Andres Chomczyk provide a solid overview of the changes being made in an effort to bring the Argentine Law in line with the EU Regulation. Their review of the draft bill notes the introduction of “new legal bases” for data processing, including, “legitimate interest,” and the addition of “sections on child consent, data breaches, accountability, privacy by design, the duty to have a data protection officer and mandatory impact studies,” all of which closely resemble the GDPR’s data protection methods.

It seems we can expect the updated Argentine law to mirror many of the GDPR’s fundamental components and, according to Palazzi and Chomczyk, even its scope of applicability; the draft outlines “new ways to determine whether an entity or certain data processing is subject to Argentine Law, quite similar to the criteria found in the GDPR.”

We’re eager to view the new law in its final form and learn when it will take effect. The law in place at this time already includes many safeguards to ensure a high level of transparency and individual control around data collection, so in some ways, we don’t expect anything truly surprising from its successor, especially if the new version does indeed follow closely the GDPR. Our GDPR implementation efforts will likely prove sufficient to meet any updated Argentine requirements as well.

Evolving Global Data Privacy Standards

The policy revision efforts underway in Argentina speak to the GDPR’s global impact. Not only do the Regulation’s data processing requirements apply to organizations outside the EU that process the data of EU locals, the GDPR also serves as a standard, perhaps particularly for countries who wish to maintain or establish adequacy status with the EU.

Just before this blog post went to “print,” India took a major step toward data privacy reform with the release of a report, “A Free and Fair Digital Economy Protecting Privacy, Empowering Indians,” that’s to serve as a draft data protection bill. In a recent Data Protection Committee press conference, Ravi Shankar Prasad, Union Minister for Law and Justice & Information Technology, Government of India, noted that India’s Supreme Court “would like Indian’s data protection law to become some kind of model for the…world…” (4m20s).

For those interested, France’s Commission Nationale de l’Informatique et des Libertés maintains a global map existing privacy law (check it out!), which may look quite different even five years from now.

A Comparison of Data Privacy Laws and Enom’s GDPR Changes

To contextualize our recent changes in relation to the GDPR, California’s Consumer Privacy Act, Canada’s PIPEDA, and Argentina’s Personal Data Protection Act, we’ve put together this comparison chart. As you’ll see, many of the core concepts remain the same across borders. This confirms our position that our recent updates demonstrate a proportionate and forward-thinking approach to the rapidly-shifting landscape of global data privacy regulation.

Reflecting on Our GDPR Changes

We could have applied our GDPR processes to EU-locals only, allowing resellers who don’t offer services to clients in the EU to proceed with business as usual, unconcerned with the GDPR. But that solution would not only have put our resellers and us at risk of improperly processing the personal data of EU-local individuals, it was also not a viable long-term option. Data privacy standards around the world are evolving and not in a direction that supports the unnecessary collection of personal data or the continued display of unredacted personal data in the public Whois directory without the data subject’s clear and specific consent. If the laws we reviewed today are any indication of where things are headed, Enom and our reseller partners can feel confident that our GDPR implementation work has positioned us all to meet and adapt to changing data privacy requirements.

Our decision to redact data from the public Whois, even before ICANN confirmed this as an appropriate response to the GDPR, was part of larger move towards a gated Whois solution. In designing our “Tiered Access Directory”, we’ve done our best to balance individual privacy and the rights of registrants with those of law enforcement and other community members. Our consent management process establishes a high level of transparency about what data we collect and why and provides registrants an easy means of revoking consent and submitting data use disclosure requests. These changes may cause some friction in the short term but we are confident they will help us meet the long-term needs of our resellers and ensure we’re protecting their businesses as well as our own.

On a less practical note, our parent company, Tucows, maintains a long-time commitment to “lobby, agitate, and educate to promote and protect an open Internet around the world.” Part of ensuring that the Internet remains free and open is ensuring that basic individual rights, including control over one’s personal information, continue to be protected as personal data becomes more ubiquitous and easy to share than ever before. The laws we’ve looked at here take varied approaches to addressing this challenge but also share some important similarities and reflect values that are becoming more and more universal: greater transparency on the part of organizations and greater control for individuals.
Read More
Why Choose an EV SSL Certificate?

June 13, 2018

Advice, Featured, SSL

Like

Views: 2544

Identity theft and browser warnings are growing concerns among consumers. And while you may think enabling SSL on your website will allay these fears, failure to select the right TLS/SSL certificate can erode customer trust. To regain trust, site owners need an easy, reliable way to show customers that transactions are secure and that the site operator is who it says it is. But with the variety of TLS/SSL certs available – DV, OV, or EV – figuring out the best certificate for your business can be confusing. There are major differences in how domains are validated, and the following outline provides some key insights as to which certificate to select for your specific needs.

Domain Validation (DV) SSL Certificates

DV certificates prove ownership of the actual domain through a simple email validation process. DV certificates can be issued in minutes, show trust indicators in browsers (like the padlock icon), and enable HTTPS.

However, DV certificates do not vet the legitimacy of an organization and should not be used for e-commerce sites. Accordingly, DV certificates are best for internal sites, test servers, test domains, and for small to medium-sized businesses seeking cost-effective security.

Organization Validation (OV) SSL Certificates

OV certificates provide the same level of protection as DV certificates but go one step further. With an OV certificate, the Certificate Authority (CA) confirms the business is registered and legitimate, checking details such as business name, location, address, and incorporation or registration information, making these certificates more suitable for public-facing websites.

An OV certificate will also enhance a website’s reputation, providing customers greater assurance in conducting e-commerce transactions.

Extended Validation (EV) SSL Certificates

EV SSL certificates provide the highest level of trust, giving customers greater confidence that they are conducting business through trusted websites. EV SSL certificates are the industry standard for e-commerce websites. An EV SSL certificate triggers high-security web browsers to display an organization’s name in a green address bar and show the name of the Certificate Authority that issued it:

EV SSL certificates confirm site identity and validate the organization according to rigorous industry guidelines established by the CA/Browser Forum, including a strict vetting process using techniques that have been proven reliable in protecting the internet’s most valuable online businesses for more than ten years.

EV SSL certificates are a good choice for businesses, as these certificates can enhance credibility by showing suspecting consumers that sites are legitimately what they purport to be and that a business is serious about protecting the data of its customers.

Summed up, for the greatest level of website security, EV SSL certificates are the best choice.

Find Out More

This post was sponsored by Comodo CA, one of our trusted SSL providers. For more information about SSL, and a complete list of their products, visit www.ComodoCA.com.

Read More
A Guide to Choosing the Right SSL Certificate

May 24, 2018

Advice, Featured, SSL

Like

Views: 2757
A parent preparing a toddler for her first beach vacation and a seasoned kayaker preparing for Zambia’s Ghostrider rapid will not reach for the same life jacket. In the world of digital security, the purposes and specs of the various products are also highly relevant to the consumer, although the differences between them may not be so immediately clear. But in both cases, it’s important that the customer find the right fit. Whether you’re a business owner looking for the right SSL certificate for your own website or a domain provider looking to curate a solid SSL offering for your own customers, here’s what you should know about TLS/SSL certificates and what to look for when selecting a certificate provider.

What are TLS/SSL Certificates?

SSL is short for “Secure Sockets Layer,” and SSL certificates are used to secure communications between a website, host, or server and the end users that are connecting to it (or between two machines in a client-server relationship). An SSL certificate confirms the identity of the domain name (for example, ComodoCA.com) that is operating the website and enables encryption of all information between the server and the visitor to ensure the integrity of all the transmitted information.

Why are TLS/SSL Certificates So Important?

Identity theft and browser warnings are growing concerns among consumers. Failure to select the right TLS/SSL certificate for your website can erode customer trust and lower your rate of completed transactions, negatively impacting your bottom line.

How SSL Encryption Works

Encryption makes use of keys to lock and unlock your information, meaning you need the right key to “open,” or decode, the secured information.

Each SSL certificate comes with two keys:
- A public key, which is used to encrypt (scramble) the information.
- A private key, which is used to decrypt (unscramble) the information and restore it to its original format to make it readable.
Where Are SSL Certificates Used?

SSL certificates should be used in any instance where information needs to be transmitted securely. This includes:
- Communications between your website and your customers’ internet browsers.
- Internal communications on your corporate intranet.
- Email communications sent to and from your network (or private email address).
- Information between internal and external servers.
- Information sent and received from IoT and mobile devices.
Determining If a Site Has a Valid SSL Certificate

A website without an SSL certificate displays “http:// ” before the website address in the browser address bar. This moniker stands for “Hypertext Transfer Protocol,” the conventional way to transmit information over the Internet. Most internet users are aware that this indicates a website is not secure and historically have looked for https:// and a closed padlock symbol in their browser window to confirm that they are on the site of an authenticated organization:

However, it’s no longer sufficient for business websites to simply enable HTTPS and display the standard padlock symbol to their visitors. Online consumers are demanding assurance that the identity of the website they are visiting has been verified by authentication procedures that are proven to be highly trustworthy. And this assurance is provided in the form of an Extended Validation (EV) SSL certificate. EV certificates display a hard-to-miss green identifier in the URL bar and indicate to the visitor that the website was subjected to extensive scrutiny by the issuing Certificate Authority. The consumer can be confident that they are at a legitimate website, not a phishing website.

That’s not to say an EV certificate is necessary in every situation. But they can generate a higher level of consumer trust than other options, such Organization Validation (OV) certificates, or Domain Validation (DV) certificates, which undergo far less scrutiny.

Choosing between EV, OV, and DV Certificates

Domain Validation (DV) SSL Certificates

DVs are best for small- to medium-sized businesses seeking cost-effective security with no need to establish site visitor trust. Issuance of a DV certificate simply requires proof of ownership of the associated domain name, which is provided through a simple email validation process. These certificates can be issued in minutes, enable HTTPS, and display a clear indicator, such as the padlock symbol, in internet browsers.

However, DV certificates do not vet the legitimacy of the organization the website represents and should therefore not be used for e-commerce sites or sites that deal in sensitive information. They are, however, a great option for many internal sites, test servers, and test domains.

Organization Validation (OV) SSL Certificates

OV certificates provide the same level of protection as DV certificates but go one step further than simply requiring proof of domain ownership. With an OV certificate, the issuing Certificate Authority confirms the business associated with the domain name is registered and legitimate by checking details such as the business name, location, address, and incorporation or registration information. This makes the OV certificate a more suitable option for public-facing websites that represent companies or organizations.

Extended Validation (EV) SSL Certificates

EV certificates provide the highest level of trust by assuring consumers that they are conducting business through a trusted website. For this reason, these certificates have become the industry standard for e-commerce websites. EV SSL certificates trigger high-security web browsers to display a green address bar that includes the name of the company or organization that owns the domain. They also show the name of the issuing Certificate Authority:

Confirmation of the website’s identity and validation of the organization is carried out according to the rigorous industry guidelines established by the CA/Browser Forum and involves a strict vetting process that is shown to be effective over the course of more than ten years of real-world use.

EV SSL certificates are essential for large businesses or e-commerce sites as they can enhance credibility by showing discerning consumers that a prospective transaction is with a legitimate recipient and that the site is serious about protecting the data of its customers.

What to Look for When Choosing a Certificate Authority (CA)

As the world’s largest commercial Certificate Authority, Comodo CA is proactively monitoring for potential threats and attacks, working hand-in-hand with government agencies, browser providers, and our customers, to ensure it is keeping up with the ever-changing market.

When evaluating a CA, be sure that it:

1. Follows CA/B Forum Baseline Requirements.

This industry group consisting of Certificate Authorities and browser manufacturers developed standards that each CA must meet for its roots to remain trusted in browsers. These include:
- All information contained within the certificate must be validated to be true through a strict, clearly defined authentication process.
- Certificates must meet specific minimum levels of cryptographic strength to protect the integrity of the certificate and private key from evolving threats.
- Certificates must not exceed maximum specified durations.
- CAs must follow guidelines for CA security, certificate revocation mechanisms, audit requirements, liability, privacy and confidentiality, and delegation of authority.
2. Conducts Annual Audits – Both WebTrust and SOC 3

Annual audits are crucial to CA security, yet not every CA makes them a priority. At a minimum, your CA should meet these auditing standards.
- Maintain membership in the WebTrust program for CAs
  The WebTrust for Certification Authorities program was developed to increase consumer confidence in the Internet as a vehicle for conducting e-commerce and to increase consumer confidence in the application of PKI technology. Comodo CA, for example, undergoes an annual audit from Ernst & Young, which validates that:
- The Certification Authority (CA) discloses its SSL certificate practices and procedures and its commitment to provide SSL certificates in conformity with the applicable CA/Browser Forum Requirements.
- Subscriber information was properly collected, authenticated and verified.
- The integrity of keys and certificates is established and protected throughout their life cycles.
- Logical and physical access to CA systems and data is restricted to authorized individuals.
- The continuity of key and certificate management operations is maintained.
- CA systems development, maintenance and operations are properly authorized and performed to maintain CA systems integrity.
- The Certification Authority maintains effective controls to provide reasonable assurance that it meets the Network and Certificate System Security Requirements as set forth by the CA/Browser Forum.
- Submit to publish an annual Service Organization Control 3
  The SOC3 report is published to confirm that the security controls for this cloud service have been examined by an independent accountant. Again, as an example, Comodo CA undergoes an annual audit from Ernst and Young, to validate that Comodo CA has maintained effective controls over its system as it relates to four core principles: security availability, processing integrity and confidentiality.
To sum it up…

Trust is everything in the world of online business. Investment in technology to protect customers and earn their trust is a critical success factor for any company that does business online or hosts an e-commerce website. The effective implementation of TLS/SSL certificates is a proven tool to help establish customer trust. Check out Enom’s lineup of Comodo Certificates, or browse our full inventory of SSL products.

Looking to learn more?

This post was sponsored by Comodo CA, one of our trusted SSL providers. For more information about SSL, and a complete list of their products, visit www.ComodoCA.com.
Read More
GDPR Checklist for Enom Resellers

May 17, 2018

Advice, Announcement, Featured, GDPR, Uncategorized

Like

Views: 4471
Any time there’s a dramatic shift in our industry, we focus on minimizing the impact on our resellers and providing you as much information and assistance as possible. Admittedly, our GDPR communications work has proven fairly challenging, in part because we’ve simply never seen a shift quite as dramatic as that prompted by the GDPR. While we wanted to equip our resellers with specifics about our implementation plan and a concrete list of action-items right from the get-go, developing long-term solutions that both achieved GDPR compliance and established processes in which registries, registrars, and resellers can play their specific, essential roles required considerable collaborative efforts from players across our industry.

There’s still much work to be done, but today we’re happy to be able to offer a concrete list of GDPR action-items for Enom Resellers and helpful resources in the form of flowcharts, example landing pages, and FAQs. We’re even happier to say that the to-do list is a short one which will likely require minimal work on your end.

Having said that, we must remind you that legal counsel is an essential part of any comprehensive GDPR compliance strategy. This checklist is not legal advice, and ensuring its completion by no means guarantees your compliance with the GDPR. Speak with a lawyer who is familiar with your business and equipped to judge whether your internal practices achieve compliance.

Reseller Action-Items

Most of these items will necessitate adjustments on your end. You may determine that some do not require action on your part, but all are significant and important for our clients to understand.

1. Make Sure You’re Familiar with Our Newly Introduced Consent Management Process

Moving forward, Enom will reach out to end-users to request their consent to process certain pieces of personal information. This “Consent Management” flow involves the sending of a request email which contains a link to the registrant’s unique Data use consent settings page. This Data Use Consent Settings page serves as the registrant’s means to view their settings, manage their settings, and withdraw consent, should they choose to do so. It also contains a link to the Data use information page, which provides more information about how personal data is processed.

To the registrant, it’s a straightforward experience that makes clear Enom’s relationship with their Registration Service Provider (Reseller). We recommend you take a look at these samples, so you’re aware of what this process will involve for your customers:

Consent management sample flow – new registration
Consent management sample flow – consent choice change

Resellers will be able to view the GDPR consent status for each domain they have under management from the Domain Control Panel, within their Enom reseller account. If you’d like more information on why we require the end-user’s consent to process certain personal data, please check out our Consent blog post.

2. Understand How to Provide Your Customers Access to Their Data Consent Settings Page

According to the GDPR, “It shall be as easy to withdraw as to give consent.” With this in mind, we’ve provided our resellers two straightforward options to email a registrant the URL for the registrant’s Data Use Consent Settings page upon request:
- Option 1: Via the API using the SendConsentEmail command
  Resellers can use this command to integrate into their own end-user portal an option for users to request that the Data Use Consent Settings page URL be sent to the registrant email.
- Option 2: Via the soon-to-be-available “Send Consent Email” option in your Enom reseller account.
  Resellers can use this new button in the “Domain Control Panel” section of your Enom reseller account to send out the Data Use Consent Settings page URL to the registrant email listed for any domain in their account.
Please note: both of these options will be available as of Monday, May 28, 2018.

3. Ensure You’re Prepared for Our Updated Domain Transfer Process

Once the public Whois “goes dark” in the days leading up to May 25, 2018, Enom will begin using a new process for domain transfers. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

You can check out our blog for the full details, but here’s a snapshot of the updated process:

4. Enom Is Moving to a Gated Whois System

For the full scoop, refer back to our Whois Changes blog post; for today, just keep in mind that after that go-live date, most public whois servers will cease the publication of personal data, and providers will start offering a “gated” or “tiered access” Whois system. Enom resellers don’t need to make any changes — your own clients’ data will continue to appear in your Enom reseller account, and we’ll take care of making sure the public Whois output is fully compliant with privacy regulations, so you’re good to go.

These changes are also summarized in this quick PDF.

5. Our Updated Reseller Agreement Now Requires That Resellers Process Data in a GDPR-Compliant Manner

Hopefully, you’re well on your way to compliance with the GDPR. Enom has updated our Reseller Agreement to include information about the consent management process and the addition of a Data Processing Addendum (DPA), with EU standard contractual clauses to allow data transfer from the EU to non-EU jurisdictions. We encourage you to familiarize yourself with all the recent GDPR-related changes we’ve made to our Reseller Agreement by taking a look the updated version.

6. We’ve Updated Our Agreement with Registrants

Our Domain Registration Agreement serves as the service contract between Enom and the domain owner (registrant). We don’t expect the GDPR-related updates to this agreement to be reseller-impacting, these changes primarily relate to the registrant’s consent management flow and the data retention and erasure policy. Keep in mind that all resellers need to display this updated agreement to customers as part of the domain registration process.

Reseller Resources

All important Enom resources relating to the GDPR can be found in our central GDPR knowledge base article, but for convenience, we’ve also listed them below. We hope the following resources help our reseller partners assist your clients with GDPR-related changes:

Overview

Our GDPR Webinar
Central GDPR knowledge base article and FAQ

Specific Platform & Process Changes

Consent Management

Consent management sample flow – consent choice change
Consent management sample flow – new registration
Consent management FAQ

End-user consent request emails – The means by which we send the Data Use Consent Settings page URL (see below) to the registrant.
Data use consent settings pages – The location from which a registrant can set, view, and update their consent preferences or revoke consent.

Domain Transfers

Transfer process changes infographic – a before and after GDPR comparison

Whois Changes

Whois Changes Overview PDF
Whois Changes FAQ

API Changes

A new SendConsentEmail command has been introduced.

Contract Changes

Updated Reseller Agreement
Updated Domain Registration Agreement
Data Processing Addendum

And there you have it. We appreciate that for those resellers affected by the GDPR, achieving compliance has involved a great deal of internal work, in addition to that required to accommodate the changes Enom is making to our platform. And while we’ve made every effort to keep this Reseller Checklist short and easy-to-implement, we know, as members of that same complex registry-registrar-reseller channel in which you operate, that small changes made by one player can have a big impact on others. We view our GDPR implementation work as essential to ensuring that the Enom platform evolves to meet the long-term needs of our resellers and the demands of a highly interconnected internet ecosystem. Greater control over one’s personal data is a good thing, and we’re happy to be able to extend to all users on our platform the rights and protections outlined in the GDPR.
Read More
The nTLD Reseller Starter Guide: Which new gTLDs should I offer?

November 14, 2017

Uncategorized

Like

Views: 4894

If you currently sell or are considering selling domain names as part of a business, you may have asked this question to yourself before. The huge variety of gTLDs out there can turn the task of curating a lineup that makes sense for your business into a rather daunting undertaking. Instead of getting bogged down by all the variables that could weigh into your final decision, I suggest you focus on the handful of key considerations that really matter. The questions below will help you better evaluate TLDs and equip you to make smart choices as you expand or refocus your offering. And in case you still feel stuck, we’ve included a list of extensions you might consider.

Is the TLD easy to implement?

Most of the new gTLDs fall into the “easy-to-implement” category, free to be registered by anyone, anywhere, much like a .COM. Others have strict registration requirements, such as a local presence in their associated geographic area, or an affiliation with a particular professional group. If you ever need to verify whether an extension you’re considering is restricted, take a quick look at our TLD reference chart.

The TLDs we’ll highlight in this post are all easy to implement, but that’s not to say you should steer clear of those that are restricted. In fact, offering restricted TLDs can be a great way to cater to a niche market. For example, many firms might find the credibility of a .LAW extension advantageous. Similarly, the appeal of geoTLDs like .NYC, .BARCELONA, or .BERLIN among local citizens make them a great choice if you attract a significant volume of customers in any of these cities. If you think you’re likely to sell a high volume of a certain restricted extension, the payoff may well be worth the extra implementation efforts involved. It really comes down to knowing your audience and presenting them with options they are likely to find meaningful.

Is there a high level of interest in the TLD?

Unless you’re catering to a highly specific market, you’ll benefit from starting with TLDs that have wide appeal. This appeal can be generated by both the generic nature of the extension (.WEBSITE or .ONLINE), or its specificity (.CLOUD, .BLOG, .SHOP, .STORE or .DESIGN). Note that each of those last five extensions has an unambiguous meaning that resonates with a huge number of potential buyers.

This doesn’t mean a small TLD offering shouldn’t include more niche extensions. Again, the level of interest your customers show for a particular TLD will always depend on who your customers are. I had a musician friend, for example, that was thrilled to launch her new business with a .STUDIO name. And I’m willing to bet there are a lot of artists out there who might be open to a similar departure from the traditional, more corporate-sounding extensions.

Does the pricing make sense?

Most potential nTLD buyers compare new possibilities to .COM alternatives. So presenting them with fresh, viable options in a similar price range is smart. There are many solid performers, with broad applications, that fall into this category. Of course, this isn’t to say that a high price tag should deter you from offering an extension that seems particularly well-suited to your customer base.

It’s also not just the initial purchase price you should be aware of. Simple and predictable pricing structures are an important factor in building an enduring customer base. So while offering TLDs with substantial first-year discounts might translate into increased registrations, you could find yourself unpleasantly surprised by relatively low renewal rates. A customer who purchases a domain on promotion might not be put off by a slightly higher renewal fee. But there are numerous registries that present enticing first-year TLD price tags in the .COM range, with renewal fees that might be 10x greater. These kinds of discrepancies not only deter savvy buyers from making the initial purchase, and put a dent in your renewal rates, but also place you at risk of angering customers who are caught totally off guard by the increase.

In short, it’s advantageous to offer first-year promotional prices, as they can be a real incentive to potential buyers. But it’s also important to make sure you’re transparent about the renewal price, displaying it clearly within your purchase flow. For those who sell domains as a part of a larger bundle or package, the renewal price, and the margin it allows for, should be factored into your pricing structure.

Is the renewal rate and customer quality fairly high?

It’s been a few years since the launch of the first nTLDs, which means we’re now in a much better position to evaluate their long-term potential. When determining the value of a new extension, look into its renewal rate and whether its registrations are, generally, being used in a meaningful way. Arguably, there’s a link between the two.

That latter point is what I mean by “customer quality”. If you’re a hosting provider or CMS business, you stand to make more money off customers who are actually using their domains. They’re certainly far more likely to show interest in email, SSL and hosting services. They’re also more likely to renew. Not to mention, there’s a case to be made that websites that have valuable content, and employ a new TLD, effectively function as an advertisement for the extension itself. That certainly can’t hurt an extension’s organic growth over time.

In this regard, .BLOG is a standout – according to ntldstats, only 27% of its registrations are “parked”, a term applied to any domain “in use as a parking page [displaying ads], or without any content.” To put this number in perspective, the average parked page percentage for the TLDs we highlight in the chart below is roughly 53%.

Still feeling a little lost?

That’s fair! The paradox of choice is a powerful thing. Here are some suggestions that might serve as good place to start. Judging them based on the checklist above, these TLDs don’t necessarily score high across the board, but they are all easy-to-implement and offer the potential to target a sizable audience – some because of their generic nature and global recognizability, and others because of their appeal to a specific, but substantial, market.

To reinforce my early point: while we haven’t focused on geoTLDs in this post, they represent a sizable portion of the nTLD pie. Depending on your target market, they can be incredibly profitable.

If you’re ready to explore what options might work best for your business, you can view all available TLDs at enom.com.

Read More
Tucows acquires wholesale domain registrar Ascio Technologies

March 19, 2019

Announcement, Industry Insight

Like

Views: 947

Earlier this morning, our parent company, Tucows Inc. released some exciting news: we’ve officially acquired Ascio Technologies, another wholesale domain registrar that, like Enom, is dedicated to supporting a growing reseller network.

Enom and our sister brands, OpenSRS and EPAG, are thrilled to welcome Ascio to the Tucows family. The venture further solidifies Tucows’ position as the leading global wholesale domain registrar and is a natural step in expanding what we believe to be the best reseller-focused domains business in the industry.

The Ascio acquisition not only adds 1.8 million domains under management, but a thriving network of 500 resellers that fits squarely within Tucows’ core customer profile: ISPs, web hosting companies, and website builders. The move to acquire Ascio makes sense precisely because its business is so complementary to Enom’s. It will support Tucows’ efforts to scale and leverage synergies, while remaining focused on serving a specific customer base and investing in a platform and services that benefit resellers across all Tucows wholesale brands, Enom included.

Moving forward, it will be business as usual for all brands, Ascio included, as Tucows works to leverage the strengths of all brands to improve the business as a whole. Tucows has always been reseller-focused — it’s in our DNA — and this acquisition, much like that of Enom itself in 2017, is a testament to Tucows’ continued commitment to, and investment in, its wholesale domains business.

Read More
Enom’s Tiered Access Directory: eight months later

February 19, 2019

GDPR, Industry Insight

Like

Views: 610
Tucows’ Tiered Access Compliance & Operations portal (which we commonly refer to as a “Tiered Access Directory” or “gated Whois”) launched at the end of May 2018. With its launch, our public Whois “went dark.” From that date forward, all personal registrant data has been redacted from the public Whois by default, and made accessible only via the gated Whois.

Most people saw this is a good thing—registrants deserve to have their personal information protected. A few argued that the change would impede efforts to identify and take legal action against cyber criminals and trademark or copyright violations. We’ve always advocated that a balance could be reached.

Now, eight months into our Tiered Access program, we’re looking back at the data access requests to see what the numbers reveal about how the system is working out.

The Big Picture

We have received more than 2100 data access requests since our Tiered Access system started last May, and of these requests:
- Just over 25% resulted in applicable registration data being provided to the requestor
- Only a small percentage of requests get denied: 4.6%, as of 13 February 2019
- 13% of all requests are duplicates
- 65% of all requests came on behalf of a single requestor; only 21% of these requests resulted in the provision of data, as the majority did not provide sufficient legitimate purpose, nor did the requestor respond to our request for more information
Perhaps surprisingly, 70% of data access requests are not fulfilled because the requestor did not respond to Tucows’ requests for additional information (including assurances regarding who the requestor was, how the data would be handled, and why the data were needed). For example, some requests failed to include the requestor’s own identity, their legal basis to access the information, or even which specific domain name they’re asking about. In all cases, we reply promptly to ask for the missing information but, so far, for 70% of the requests we have received, that information was never provided.

Whois (pun intended) requesting registration data?

The vast majority of requests—just over 90%—come from commercial litigation interests and relate to a suspected intellectual property (copyright or trademark) infringement. The remaining 10% are spread across other types of requestors, including law enforcement, security researchers, registries, the registrants themselves, and third-parties interested in purchasing specific domains.
- 92% of requests were made by commercial litigation interests, mostly trademark interests (85%) but also some copyright (4%: fewer than 100 total copyright-related requests)
- Within the “trademark” category, 76% of all requests are on behalf of a single entity. The next highest entity requestor accounts for only 7% of trademark requests.
- Law enforcement requests account for less than 2% of all requests—this does not include warrants, as the intent of a gated Whois is to provide data which what had previously been publicly available; requests for additional information still require a warrant or subpoena
- Fewer than 1% were requests from security researchers, one of the major groups who have expressed concerned about the loss of public Whois
Interestingly, we have had only a single request that appears to be related to illegitimate pharmaceuticals being sold online and zero requests related to terrorism. These are categories that we were led to believe we would receive a high volume of requests for.

Requests from ICANN Compliance

There are also a significant number of requests for personal data that we’ve excluded from the stats and total number referenced above: those made by ICANN Compliance. These were not included because, although ICANN Compliance has requested personal data from us in relation to complaints filed by third-parties, they have not yet demonstrated a legitimate purpose for processing that data. Since the introduction of our Tiered Access system in May, no Tucows-owned registrar has shared any personal registration data with ICANN Compliance; we have discovered that we can successfully help ICANN’s compliance investigation of registrant or third-party requests without disclosing any personal data to ICANN. We are always looking for innovative solutions that allow us all to rethink the traditional way of doing things.

What do these numbers tell us?

We see significant spikes of requests surrounding ICANN meetings:

These spikes and the prevalence of certain requestors strongly suggests an attempt to skew the data to create an argument against the loss of public Whois data. Regardless of that attempt, however, what we clearly see is a system working the way that it should: when sufficient legitimate interest is shown and assurances regarding the handling of data are made, the process of providing personal data is smooth.

The sky didn’t fall. The dire predictions that commercial litigation, law enforcement, and security research interests made prior to our GDPR implementation did not come to pass. Our Tiered Access team is able to respond to requests in a timely manner and to provide access to registration data when the requestor can demonstrate their legal basis for access. The system works well.

The future of Tiered Access

There remains much to be done regarding Tiered Access. The “Technical Study Group on Access to Non-Public Registration Data”, a recently-created group of ten members hand-picked by the ICANN Board, is engaged in technical work on Tiered Access, although not the thornier legal or policy challenges. There is a lot of work happening in the ICANN Community as well. The Expedited Policy Development Process (EPDP) Team work has not yet been finalized; a Registrar Constituency document outlining guidelines for requesting registrant data will be published soon; and there are ongoing informal discussions among registrars and other interests intended to streamline access and make it less difficult and confusing.

The EPDP’s Phase 1 Final Report, which will focus on data collection and, later, its Phase 2—which will be focused on a Standard Access Model—may affect what we collect and disclose in the future. We won’t know what the Tiered Access system will look like long-term until there is clarity around these items, which are still very much up in the air. That said, we’re in a position to adapt our system to meet the ICANN Community’s final requirements. In the meantime, we’ve created a solution that achieves an effective balance between protecting registrants’ right to privacy and providing legitimate third-parties timely access to the data they’re legally entitled to.

As we’ve said before, while it marks a big change in the domain space, the introduction of our Tiered Access Compliance and Operations system is a move in the right direction, in step with evolving privacy laws across the globe. Tucows remains committed to protecting registrant privacy and applauds the efforts underway by various governments to establish privacy-by-default standards.
Read More
What Brexit means for .EU domain owners in the UK

February 11, 2019

Industry Insight

Like

Views: 1291
If you sell .EU domains to UK residents, you may already be aware of an announcement made by the European Commission last March on the future of .EU domains registered to UK organizations and individuals. In short, once the UK officially withdraws from the European Union, individuals with an address in the UK and Gibraltar, and UK companies without a presence elsewhere in the EU, will no longer meet the eligibility requirements.

Much to the disappointment of the domain community, the European Commission has decided against “grandfathering” the 300,000 .EU domains already registered with a GI or GB country code, an action which would have allowed existing owners to renew their domains indefinitely, despite the country code no longer being eligible. We would have appreciated a more creative solution than existing registrants simply losing their right to ownership. Regardless, it’s time to start preparing affected registrants for this change.

No one knows how Brexit will proceed, but in late January 2019, EURid, the .EU registry, released details on how it would approach this transition. There are three possible scenarios:
1. Hard Brexit: The UK leaves the EU with no deal on March 30, 2019.
2. Soft Brexit: The UK leaves the EU on or after December 31, 2020, following a planned transitional period.
3. Soft Brexit with .EU Provisions: The UK leaves the EU with a planned transitional period, and the deal includes provisions for .EU domains.
Below you’ll find what each of these three scenarios would mean for .EU registrants based in the .UK.

Scenario 1 — In the event of a “hard Brexit”

If the UK leaves the EU on March 30, 2019, without having reached a withdrawal agreement, here’s what will happen. You can also jump to the summary table below.

Starting at March 30, 2019, 00:00 CET (March 29, 2019, 19:00 EDT), EURid will immediately stop allowing new registrations of .EU domains using a GB (Great Britain) or GI (Gibraltar) country code. For existing domains, EURid will no longer allow registrant transfers to GB or GI residents.

In March 2019, EURid will contact existing registrants who have listed a postal address with a GB or GI country code, giving them “the possibility to demonstrate their compliance with the .eu regulatory framework by updating their contact data.” For organizations, this would involve indicating a legally established entity in one of the eligible EU27 or EEA Member States. For individuals, this would involve updating their residence to a physical address located in one of the EU27 or EEA Member States.

The registrant may also choose to transfer the domain name to an EU resident.

Between March 30, 2019, at 00:00 CET (March 29, 2019, 19:00 EDT / 21:00 GMT time), when registrants are officially notified, and May 30, 2019, at 00:00 CEST (May 29, 2019, at 18:00 EDT), the registry will lock the impacted domains to prevent the following actions:
- Registrant transfer (Ownership Change) to a non-EU registrant (Only Ownership Changes to an EU registrant will be permitted)
- Explicit renew
- Auto-renew (ineligible domains will automatically enter Withdrawn status)
During this two-month window, UK registrants who wish to keep their domain active must update their contact info to satisfy the eligibility requirements or transfer the domain to an EU resident.

On May 30, 2019, at 00:00 CEST (May 29, 2019, at 18:00 EDT), any registrant who has failed to demonstrate their eligibility will have their domain placed in Withdrawn status — the domain won’t resolve (and any linked services will become inactive), but the registration record will remain on file with the registry. At this point, the registrant is still able to reactivate their domain by updating their registration data to satisfy the eligibility requirements, thereby removing the Withdrawn status.

On March 30, 2020, at 00:00 CET (March 29, 2020, 19:00 EDT), all ineligible domains in Withdrawn status will be deleted and made available for registration.

We know this is quite a lot to keep in mind, so here is a summary of the “hard Brexit” key dates and events:

Scenario 1 summary table.

Domains belonging to EU citizens living in the UK

There are, no doubt, many EU27 citizens who reside in the UK and own a .EU domain name. These registrants, though still EU citizens post-Brexit, would become ineligible on March 30, 2019, as the current EURid policy determines eligibility based on the physical address of the registrant.

However, the EU Commission has announced policy changes which would allow EU citizens based in the UK to regain eligibility. The registrants would, therefore, lose their eligibility upon the UK’s withdrawal from the EU on March 30 2019, but would likely become eligible again once the new .EU regulatory framework comes into force later this year. Unfortunately, it’s not yet clear how long of a gap there will be between the UK’s withdrawal from the EU and the implementation of updated .EU policy.

Scenario 2 — In the event of a “soft Brexit”

If the UK were to leave the EU on or after 31st December 2020, following a planned transitional period, EURid’s plan would be similar to the “hard Brexit” plan, but with an extended timeline. Here’s what would happen (summary table below):

In December 2020, EURid will contact existing registrants who have listed a postal address have with a GB or GI country code, giving them “the possibility to demonstrate their compliance with the .eu regulatory framework by updating their contact data.” Once again, for organizations, this would involve indicating a legally established entity in one of the eligible EU27 or EEA Member States. For individuals, this would involve updating their residence to a physical address located in one of the EU27 or EEA Member States.

The registrant could also choose to transfer the domain name to an EU resident.

Between January 1, 2021, at 00:00 CET (December 31, 2020, at 18:00 EST), when registrants receive their final notice, and March 2, 2021, at 00:00 CET (March 1, 2021, at 18:00 EST)the registry will lock the impacted domains to prevent the following actions:
- Registrant transfer (Ownership Change) to a non-EU registrant (Only Ownership Changes to an EU registrant will be permitted)
- Explicit renew
- Auto-renew (ineligible domains will automatically enter Withdrawn status)
During this two-month window, registrants who wish to keep their domain active must update their contact info to satisfy the eligibility requirements or transfer the domain to an EU resident.

On March 2, 2021, at 00:00 CET (March 1, 2021, at 18:00 EST), any registrant who has failed to demonstrate their eligibility will have their domain placed in Withdrawn status — the domain won’t resolve (and any linked services will become inactive), but the registration record will remain on file with the registry. At this point, the registrant is still able to reactivate their domain by updating their registration data to satisfy the eligibility requirements, thereby removing the Withdrawn status.

On 1 January 2022, at 0:00 CET (December 31, 2021, at 18:00 EST), all ineligible domains in Withdrawn status will be deleted and made available for registration.

Here is a summary of the “soft Brexit” key dates and events:

Scenario 2 summary table.

Domains belonging to .EU citizens living in the UK

As mentioned above, an updated .EU regulatory framework that will allow for .EU domains to be registered by EU citizens living in the UK will come into effect in 2019. Therefore, EU citizens living in GB or GI would NOT become ineligible as a result of a “soft Brexit.” Depending on how EURid implements the new policy directive from the EU Commission, EU citizens living outside of the EU could potentially be required to actively validate their eligibility in order to maintain their registration.

Scenario 3 — If provisions are made for .EU domains

In the event of a “soft Brexit” where the deal includes provisions for .EU domains, EURid would forgo the transition plans outlined in the scenarios above and instead adopt whatever transition plan the provisions call for.

Preparing for this change

The OpenSRS team is exploring how best to approach this situation and find solutions to minimize the impact on registrants. If you sell .EU domains we strongly encourage you to sign up for our .EU-Brexit Updates, an email series we will use to share developments, recommendations for resellers, and information about our own action plan, including how resellers can identify domains in Withdrawn status via the Control Panel and API.

Have you already given this situation some thought? If you’d like to share your approach, ask questions about this change, or provide feedback, please get in touch.

In the meantime, we have a few recommendations for our affected reseller partners.

1. Consider restricting multi-year renewals and registrations for .EU domains.
This will help avoid situations where a UK customer pays a sizable renewal fee, only to lose their .EU domain a few months later.

2. Consider displaying a warning to registrants during the registration process
It’s important that before registering a .EU domain, your UK-based customers are made aware of the impending change to the domain’s eligibility requirements. We recommend displaying a warning to customers attempting to register a .EU domain using a GB or GI address.

3. Keep in mind that the registry could contact your customers as early as March 23, 2019.
We recommend preparing to contact your affected customers before March 23, 2019, so that, in the event of a hard Brexit, the notice from the registry doesn’t come as a surprise. Over the next couple of weeks, we’ll provide more information that will help to inform your communications.

3. Advise those registrants who can to update their information to meet the eligibility requirements as soon as possible.
This will ensure their domain(s) does not fall into Withdrawn status and become inactive.

Once again, if you sell .EU domains, we highly encourage you to subscribe to our .EU-Brexit Updates series to stay up-to-date as things develop.
Read More