Introduction

Financial TLDs require special considerations in terms of security. The Security Standards Working Group (SSWG) formed by BITS has drafted a set of policy recommendations that should be applied to financial TLDs. We have adopted various security principles and guidelines commensurate to establishing a secure TLD, including the principles recommended by BITS with respect to financial TLDs.

The Security Standards Working Group (SSWG) formed by BITS drafted a set of policy recommendations that should be applied to financial TLDs. The policy comprises of a set of 31 recommendations that should be adopted by ICANN in evaluating any applicant of a financial TLD. All our financial TLDs are fully compliant of these recommendations.

We ensure that any general domain name is only activated after the validation of eligibility requirements policy, name selection policy and identify verification, thereby ensuring zero abuse of the name space, and digital assertion of the Registrant. We will appoint a credible and specialized 3rd party agency to carry out the eligibility verification.

Given below are the some highlights of our proposed policies as applied to our bid for .loans, .insurance and .bank:

Eligibility Requirements And Name Selection:

All Financial TLDs will have a well defined eligibility requirements and name selection policy for domain registrations within their namespace, along with a dispute resolution process (Eligibility Restrictions Dispute Resolution Process - ERDRP) to resolve potential abuse. Some salient features of our proposed Eligibility and Name Selection policy are:

  • Ensures that general domain names within the Financial TLDs are registered by legitimate financial institutions and professionals
  • Each registered general domain name must be similar to the business name, common name, common law name, personal name, nick name, trademark name, corporate name of the registrant or one of its employees or its products or services or offerings
  • Ensures that in the unlikely scenario of a registrant or domain name that violates our eligibility criteria or name selection policy the same can be addressed through the ERDRP
  • Ensures that the identity of the registrant is validated before the domain name is activated
  • The above applies to general domain names whether registered during sunrise, landrush or general availability

By ensuring that a general domain name is only activated after the validation of eligibility requirements policy, name selection policy and identify verification we ensure zero abuse of the name space, and digital assertion of the Registrant. The validation will be performed by an external 3rd party agency.

Domain Validation:

Domain names in the financial extensions will not be activated until the following domain validation is completed successfully:

  • Locks are applied to a Domain name upon initial registration to prevent any updates
  • The domain is directed to a temporary landing page providing next steps to the Registrant
  • The domain name and Registrant undergo validation
  • Upon successful validation, the locks are removed
  • A two-factor authentication token (eg RSA SecurID token) is sent to the Registrant
  • The Registrant will be able to modify the nameservers of the domain and activate the same
  • If the validation fails the domain name is deleted

By ensuring that a domain name is only activated after validation we ensure zero abuse of the name space, and digital assertion of the Registrant. Proxy Registrations will not be permitted.

Registrant Verification at the time of Registration:

The Whois information of every domain name is manually checked at the time of registration before it is activated. This ensures that no domain registration can have inaccurate Whois information at registration time. The process involves verifying the identity of the Registrant by performing background checks, validating incorporation documents and verifying contact information.

Registrant Authentication:

Each Registrant will be issued a two-factor authentication token (eg RSA SecurID). All Registrants will have to provide the value displayed on the token along with any request for modification to an existing domain name. This value is then passed along by the Registrar to our platform utilizing the key value pair extensions described above. Only if the token password provided matches will the EPP command be carried out. Otherwise the EPP command will return a failure response. This ensures digital assertion and multi-factor authentication for the Registrant.