Latest revision as of 16:37, 16 August 2022

[edit] What is it

With the release of second level .AU domains on Mar 24, 2022, private individuals will finally also have the opportunity to register any domain they like under .AU.

AuDA, however, requires all Registrars to validate the details of anyone applying for a .au domain “using Reliable and Independent Electronic Data or valid identity documents” before submitting their application to the Registry systems.

For Australian businesses, this type of validation is already built into the regular registration workflow, using the ABN/ACN numbers provided in the domain registration command.

As 2nd level .au domains are open also to Natural Persons, HEXONET will need to perform validation of the applicant’s details before submitting their orders to the Registry.

Unlike ABN/ACN numbers lookups, these checks are not free.

To meet the demand for .au registrations from private individuals, we have created this separate Verification service that Resellers can use to verify the details of their customers before submitting registration orders on their behalf.

The reason this was built as a separate product was to minimize the changes required to the existing .AU orders flows and to reduce impact of these changes on those Resellers that only work with business customers. Additionally, as each private customer only needs to be validated once regardless of the number of domains they wish to register, this was considered the most efficient way to offer this opportunity also to these customers.

[edit] Important things to keep in mind

• This verification is carried out on the customer’s Residential Address and a supported form of ID that will be checked using global databases (Equifax) and against the Document Verification Service offered by the Australian government.
• Access to this service is regulated through the terms posted on the HEXONET website.
• In particular, Resellers should pay close attention to the fact that explicit and informed consent to verify their personal details must be obtained (and properly tracked) from each customer. The consent can be recorded through a signed form or electronically (e.g. a check-box in the order flow) and proof of this consent must be presented by the Reseller upon request by HEXONET Resellers should keep a copy of the Customer’s consent for 6 months after submitting the request.
• All verification requests are a chargeable operation, regardless of whether the verification is successful or not: Resellers should carefully check the details collected and confirm with the customer that they are absolutely correct before submitting them.
• Each successful verification is valid for 6 months. A validated contact can be used for an unlimited number of registrations, owner changes and renewals during the period of validity. The reason for this limitation is that AuDA requires the Registrar to re-verify Registrant details when a domain is renewed: the limitation is in place to avoid that the same verification can be used both to register and then renew the same domain.
• For the same reason, we strongly recommend Resellers to encourage Registrants to register their .au domains for the maximum allowed period, to reduce the need to perform the verification again each year the domain comes up for renewal.
• It is possible to verify the same details multiple times. Each verification will be treated independently and charged accordingly. The main reason for this is to allow Resellers to re-verify an existing contact and update its “validated until” date even before the original date has passed.

[edit] How to use it

A validated contact is required to process the following types of .AU operations:

• Registration
• Trade (Owner change)
• Renewal

Our system will check the Contact Handle used as Registrant and confirm its verification status. If the Handle is not validated, or the verification has expired, the order will fail.

Please note that only the Registrant handle needs to be validated.

Resellers can verify existing Contact Handles or create a new one as part of the verification process. This operation can be performed through the API.

Resellers can also test this service through the HEXONET OTE system. Sample data is available for testing purposes, please reach out to support should you need to test your integration.

[edit] Supported document types

• Australian Citizenship
• Australian Citizenship by Descent
• Australian Driver's Licence
• Australian Passport
• Australian Visa
• Australian Birth Certificate

[edit] Fields mapping per ID Type

• X-AU-OWNER-DOB is always required. It should be filled in with the Registrant’s date of birth in the YYYY-MM-DD format.

• For Citizenship, the “X-AU-OWNER-IDDATE” should be filled in with the date in which Citizenship was acquired, as it appears in the Citizenship certificate.

[edit] Additional guidance on how to enter the ID data

[edit] Australian Citizenship

Notes:

• It is only possible to validate Citizenship by Descent certificates issued from 1 July 2007.

[edit] Australian Citizenship by Descent

Notes:

• It is only possible to validate Citizenship by Descent certificates issued from 1 July 2007.

[edit] Australian Driver’s Licence

Notes:

• Expired licences cannot be verified.
• WA extraordinary licences cannot be verified.
• Apostrophes can be used but inverted commas will result in verifications failing.
• Middle name, if supplied, is not sent for verification.
• Card Number, if supplied, is sent for verification.

[edit] Passport

Notes:

• The following types of Australian travel documents can be verified; Passport (including Ordinary, Frequent traveller, Diplomatic, Official and Emergency).
• Provisional travel documents cannot be verified.

[edit] Visa

Notes:

• Foreign nationals that arrived in Australia prior to mid-1990 may not be able to be verified.

[edit] Australian Birth Certificate

Notes:

The following birth certificates can be verified;

• ACT where the certificate was issued after 01/01/1930 or those where data has been electronically captured
• NSW where the birth occurred after 01/01/1914 or those that have otherwise been electronically captured
• NT birth certificates, including Aboriginal Population Record certificates, where the certificate was issued after 01/01/1870 or those that have otherwise been electronically captured
• QLD where the birth was registered after 01/01/1941
• SA where the certificate was issued after 01/01/1944 or those that have otherwise been electronically captured
• TAS where the certificate was issued after 01/01/1970
• VIC birth certificates issued after 01/01/1929 or those that have otherwise been electronically captured
• WA where the certificate was issued on or after 01/01/1841.

The following birth certificates cannot be verified;

• NSW birth records occurring prior to 1952 that contain a district number only
• WA birth certificates issued in the Cocos Islands prior to 1955
• WA birth certificates issued by/in Christmas Island prior to 1 July 1993.

[edit] Ensuring a successful address validation

Resellers should ensure that the address provided is the Registrant’s current Residential address (e.g. the one that appears on utility bills) and that all names and addresses are spelled correctly to minimize the possibility of failed validation requests.

The following sources are used to populate the database. As long as the address provided matches the one listed in one of these services, the check should pass without problems:

• Electoral Roll (Historical)
• Credit Bureau Commercial
• Credit Bureau Public Record
• National Tenancy Database
• Equifax Phone Directory
• Phone Directory

Please note that the check performed on the address is not a credit check. Only the Credit Header is checked to match the Name & Address against the file.

In case automated address validation should fail, Resellers can contact support providing proof that the address listed in the validation request is a 1:1 match to the Customer’s residential address. A copy of a utility bill or other document confirming the address should be provided, and the address listed on it MUST match exactly the one provided in the Validation request.

[edit] Updating a validated contact handle

Please note that while it is possible to update the details in a validated contact handle, this will cause the handle to lose its “validated” status.

If the handle is associated with domains that are coming up for renewal, or if the customer wishes to use them for new registrations or trades, a new validation request must be submitted which will be charged as a new request.

[edit] API Commands

command   = ValidateContact
contact = (TEXT) (in case the Reseller wants to add validation to an existing handle rather than creating a new one)
firstname = (TEXT)
middlename = (TEXT)
lastname  = (TEXT)
street0   = (TEXT)
city          = (TEXT)
state          = (TEXT)
zip           = (TEXT)
country   = (COUNTRY) (must be AU)
phone         = (PHONE)
email         = (EMAIL)
REGISTRY = AU
X-AU-OWNER-IDTYPE = [INT] (see list above)
X-AU-OWNER-IDNUMBER =  [TEXT]
X-AU-OWNER-IDISSUER = [TEXT]
X-AU-OWNER-IDDATE = YYYY-MM-DD
X-AU-OWNER-DOB = YYYY-MM-DD
X-AU-OWNER-ACCEPT-VALIDATION-TERMS = 1 (required. The regulation requires us to obtain explicit consent from the user to validate their data)

[edit] Returned values

property[x-au-validated] = [0|1]
property[x-au-validated-until] = YYYY-MM-DD