The priority allocation period for .AU direct closes on 20 September 2022. If you hold a domain name in any other .au namespace (eg. com.au, org.au, id.au etc.), created prior to 24 March 2022, you are able to apply for Priority Status to register its exact match in .au direct until this date.
Domains on priority hold will be released on Monday 3 October 2022.
To be eligible to register a domain name in .au direct (forexample.au), the registrant must have an Australian presence as defined in licensing rules of AUDA.
For foreign companies, this means they must have a trademark registered with IP Australia, and the domain name must be an exact match of the trademark.
If the launch of .AU direct represents an opportunity for companies wishing to gain visibility on the Australian Web, it also constitutes a risk for trademark holders in case of reservation of domain names identical to their trademarks from a third party (whether it is a cybersquatter with the opportunity to register with a connection to Australia or a homonymous rights holder).
The starting date of the system called TRABIS (.tr Network Information System), which covers the management and operation of the system and database of domain names in Turkey, was announced at the meeting organized by BTK on 22/07/2022.
It is confirmed, TRABIS will be launched on September, the 29th 2022.
We can expect to see the date of liberalization of the Turkish extensions: .com.tr, .org.tr and .net.tr to be specified in the following days.
At the moment, it is still necessary to send documents to register your domain names in Turkey, and this until September, the 29th 2022.
Managed by DotKids Foundation, a non-profit organization, the new extension .KIDS will be launched on August, the 11th in Sunrise period.
Dedicated to children, parents, educators, communities and groups related to child protection, .KIDS is an extension dedicated to all subjects related to children.
The mission of DotKids is:
• to create a dedicated Internet space for kids, supporting and advocating for a better cyberspace favorable to the positive development of kids;
• to serve as a source of support to children’s rights and welfare initiatives, especially related to the Internet.
.KIDS Launch Schedule
The launch of .KIDS will proceed according to the following schedule:
TMCH Sunrise period: from 11/08/2022 to 14/09/2022
Reserved for holders of trademarks registered in the TMCH.
Community Sunrise period: from 20/09/2022 to 19/10/2022
Reserved for non-profit organizations, institutions or charities whose main mission is to advocate for children’s rights, children’s well-being, education or child-welfare.
Pioneer Domains period: from 19/10/2022 to 29/11/2022
Reserved for the participants of the .KIDS Pioneer Program, which aims to encourage active and positive use and the development of relevant content for .KIDS domain names. The program is designed to identify qualified applicants with the best potential and capabilities to maximize the development of a domain name in children’s best interest.
General availability: from 29/11/2022
Protection Policy
The registry has implemented protective Guiding Principles that require .KIDS domain name holders to not post any illegal or inappropriate content, to protect the privacy and confidentiality of the personal data of children who visit their website.
For more information on the conditions for registration of your .KIDS, please contact your Nameshield consultant.
Between ICANN66 in Montreal, Canada and ICANN74 in The Hague, Netherlands, thirty-two months and seven summits will have passed exclusively online. In 2020, the prospect of a return to face-to-face meetings was already being discussed under the heading of ‘hybrid mode’, a mixture of face-to-face and remote meetings. The question remained as to when this could be implemented. A more favorable health context was needed, with all the questions posed by covid variants and its repeated waves, and sufficient guarantees of security for the participants, who generally come from the four corners of the world. The 74th edition, which was held last month in The Hague, was finally chosen to experiment the ‘hybrid mode’.
The return of face-to-face meetings with the lessons learned from the pandemic
A return to face-to-face sessions in The Hague, but nevertheless extremely constrained, due to health security. Pre-registration was compulsory for all sessions, with a limited number of places per session. This meant that some sessions were already fully booked well before the summit. The compulsory pre-registration led participants to pre-register for sessions they were not sure they would attend in order to reserve a place. Each participant also had to be able to prove that their vaccination status was up to date. Tests were provided on site as well as temperature taking. Finally, masks and distancing measures were mandatory, hence the limited number of places per session. The organization also decided that everyone should go through the video conferencing medium, including those present on site, an idea that aimed to ensure that all participants could interact equally. For those connected remotely, it was also noted that, as promised, the organization planned shorter sessions, generally not exceeding one and a half hour and very often even one hour. The conditions were therefore met to guarantee safe conditions for those present and good conditions for those connected remotely.
Two ODP processes running in parallel
The subject of the next series of new generic extensions has been discussed in sessions of various bodies. The project is now in the Operational Design Phase (ODP), which consists of an assessment of the risks, tasks and resources required, and which is to be concluded with an Operational Design Assessment (ODA). A related subject, that of closed generic extensions, has entered a new sequence. The principle of a so-called “Small Team”, which includes representatives of the GAC, the body representing governments, the ALAC, which represents end-users, and the GNSO, the body in charge of generic policies, has been validated in order to discuss this subject and see if a compromise can be found to envisage next steps. In the 2012 round, it was not possible to create such extension models. The question is therefore whether such extension models will be possible in the next round. Regarding the ODA, the GNSO, which estimates its publication on 31 October, has mentioned a possible postponement of six to eight weeks due to another ODA that is also mobilizing many people on the creation of a Standardized Domain Name Registration Data Access System for legitimate purposes. The SSAD ODA with contrasting conclusions, particularly with regard to its number of potential users and its particularly high cost, was delivered on 25 January. Its findings are still being evaluated. The next step on this second subject is the creation of a sort of prototype called “SSAD Light” which could be based on technologies mastered by ICANN teams to limit delays and costs. The latter would help to validate or not the implementation of an SSAD with, in this case, a prior implementation phase.
Accuracy of registration data, an important issue
Among the many issues currently being examined, the accuracy of domain name registration data is an important one for Europeans. Indeed, it is the Regulation on the Protection of Personal Data, the GDPR, which has prompted ICANN to call for the removal of personal data from registration directories and which, in turn, explains the aforementioned SSAD project and the accuracy of data. How can we ensure that masked data is accurate? In October 2021, a Scoping Team began a mission to evaluate the obligations related to the accuracy of registration data. It planned to verify the effectiveness of the accuracy of the data. Their findings were expected in June, but the measurement of effectiveness has been hampered by the difficulty of obtaining the necessary data, which is stored at the registrars. Transmitting all registration data to ICANN for research purposes requires a legal basis. The Scoping Team is thus put on hold.
This is particularly important because, as EURALO, the European part of the At-Large body representing end-users, has pointed out, Europe is about to adopt the NIS2 Directive. The directive is due to be voted on in the plenary session of the European Parliament in September before being published in the Official Journal and transposed in the 27 European states. EURALO recalled that NIS2 provides for specific obligations notably on domain name registration data, storage, access and verification and therefore interferes with the role of the regulator ICANN. Moreover, if specific measures apply only to European providers, this creates a disparity of obligations between players, not to mention that the transposition of the text could be unequal in the states. Accuracy at the ICANN level can help harmonize future obligations for all players regardless of their location.
The impact of regulations and disasters
At ICANN73, which followed the outbreak of the conflict in Ukraine, ICANN had the good idea of creating a session dedicated to geopolitical, regulatory and legislative aspects. This meeting highlighted the risks of fragmentation of the single Internet model advocated by the organization. This meeting was repeated at this summit and allowed to note that the initiatives of the States are increasingly interfering with ICANN’s role as regulator.
EURALO had the good idea of completing this panorama with a session on governance and multipartyism in times of emergency. This session consisted mainly of a round-up of At-Large representatives from different continents. The representative from Ukraine logically started the session. In a moving speech about the tragedy in her country, she reminded us that the Internet infrastructure in her country has been heavily impacted. For the Asia-Pacific region, the representative mentioned the volcanic eruption in Tonga in January 2022, which cut the submarine cables and caused a five-week blackout on the islands. She also mentioned the situation in Myanmar where the Internet has been cut off since a coup in February 2021. The representatives of the two American continents spoke of natural and climatic disasters such as Hurricane Maria in Puerto Rico, which had knocked out telecommunications antennas and the electricity network. For part of the population, electricity and Internet access had been cut off for several months. Finally, the representative of Africa recalled that today at least 60% of Africans do not have access to the Internet.
Our comments
The return to face-to-face meetings was not an easy task for ICANN. While many participants felt that the proposed framework was too restrictive, it seems that the organization worked quite well overall in allowing everyone to attend the sessions fairly. The protection measures also seem to have dissuaded many participants from coming, including the speakers scheduled for the week of exchanges who assumed to participate remotely. Indeed, the figures given by the organization indicate 1817 participants from 101 countries, half of whom attended remotely. A good point for the planet but the limit was the possibility to interact outside the sessions.
On the ongoing policy development and review processes, the sessions during the week of the event reminded us that there are a lot of issues being dealt with in parallel, undoubtedly too many issues. This inevitably makes it difficult to keep track of them and causes delays, such as the two ODPs being conducted simultaneously on SSAD and the next round of new generic extensions. However, the overall feeling is that the topics are moving forward, even if the finish line is often unclear.
The last day provided a break from policy issues as geopolitical and regulatory issues and the impact of disasters reminded us that the governance model and access to the Internet are two particularly fragile critical aspects. While NAMESHIELD offers you solutions to the risks associated with compromised names and malicious registrations, we must also remember that we are not all equal when it comes to accessing the Internet. In addition to stricter legislation, other risks such as armed conflicts or climate change must indeed also be considered.
The registry that owns .SEXY will drastically increase the price of new registrations under this extension from April, the 30th 2022, 18:00 (Europe/Paris).
All registrations, transfers and renewals of a .SEXY domain name registered after April 30th 2022 will be charged 3850 € HT per year.
This very important price increase, which has not been explained by the registry, will only apply to domain names registered after this deadline.
Domain names registered before April, the 30th can still be renewed at the current price (70 times lower).
To protect your brands without suffering this increase, we invite you to register your .SEXY domain names now.
In recent years, ICANN, the regulator of a “universal resolution” of the Internet for all Internet users, has been confronted with new difficulties that are weakening the body and its model. Its mode of operation has had to be adapted to an unprecedented global pandemic and its model of a global Internet is now being questioned by the growing desire of states to emancipate themselves from it, with the tragic conflict in Ukraine pushing the Urals a little further away from the Rockies. But the difficulties also come from its immediate environment with the rise of alternate roots. It is in this context and following a previous edition marked by tensions around the subjects that make up its topicality and which are struggling to move forward, that the 73rd summit opened with great expectations.
For once, the 73rd ICANN meeting did not kick off on a Monday, the day scheduled for the first working sessions. On Sunday 6 March, ICANN published a communiqué stating that its Board of Directors had decided to allocate an initial sum of US$1 million in financial assistance to support access to the Internet infrastructure in emergency situations in Ukraine. This was a way to launch an edition where the conflict in Ukraine was bound to be on everyone’s mind and in many debates.
The conflict in Ukraine in the background
Indeed, on Monday afternoon the very first plenary session of the summit, that of the GAC, the body representing governments, began with a condemnation of Russia’s actions in Ukraine. Several members of the GAC, including France, took the floor.
Two weeks earlier, Ukraine was hit by the first Russian strikes. Ukraine, through Mykhailo Fedorov, Deputy Prime Minister and Minister of Digital Transformation, asked ICANN to target Russia’s access to the Internet by revoking specific country code top-level domains operated from Russia, revoking SSL certificates associated with the domain names and shutting down a subset of root servers located in Russia. ICANN responded negatively to this request in a letter from Goran Marby, ICANN’s CEO, to the Minister, reminding that ICANN’s mission is to take steps to ensure that the Internet operates in a global and non-politicised manner. ICANN is a neutral body, Goran Marby repeated at the Public Forum that closed the summit.
Prospects for ongoing policy development processes
During the previous ICANN summit, tensions were palpable in certain bodies, especially the one representing the registries, due to policy development processes that have become longer with additional stages such as the ODP (Operational Design Phase) that now intervene between the return of final recommendations and the Board’s vote on them.
The first subject to be affected by the ODP stage is the Standardised System for Access to domain name Data. This system, known as SSAD, has been under discussion for more than three years as part of a policy development process known as ePDP, of which SSAD is part of phase 2. It is intended to return to a more uniform model of access to domain name registration data for legitimate requests. However, the ODP, which has just been finalised six months later than the initial estimated timetable, has highlighted the difficulty of framing this project. The number of users is in fact estimated at between 25,000 and 3 million to address 100,000 to 12 million requests, values that lead to a particularly wide range of implementation and maintenance costs (from 34 to 134 million US dollars) and consequently to access costs for the future system that are very difficult to evaluate, the idea being to finance the system exclusively with access costs. At ICANN73 , a way out was suggested: Create a pilot project to limit the risks, in other words, envisage a small-scale SSAD before considering the next steps.
It has been noted that regarding phase 1 of the aforementioned ePDP there is now a finish line. It is estimated to be completed by the end of 2022. This phase aims to create a perennial policy to replace a Temporary Specification that addressed the GDPR in the domain name eco-system in 2018.
The other major topic is that of a next series of new generic extensions. Let’s remember that the previous series will celebrate its ten years in 2022. Since then, it has been a policy development process (PDP) that stretched from December 2015 to February 2021 when the body representing generic policies, the GNSO, adopted the final recommendations report. Last September the ICANN Board decided to initiate an ODP process that could last until early next year. This topic has been the subject of much criticism as the finish line seems to be getting further and further away, even though it has been ten years since the last round. Nevertheless, one option was discussed at ICANN73, that of starting the implementation work without delay, a proposal that, while it rather displeased the ICANN CEO, was rather positively received by the ICANN Board, which should however only vote on the recommendations of the final report of the PDP process after the end of the ODP.
Geopolitical, legislative and regulatory aspects – a new feature
Among the novelties of this summit was a plenary session devoted to geopolitical, legislative and regulatory aspects. This session provided an overview of the many initiatives coming from institutions such as the United Nations, the International Telecoms Union, the Council of Europe and the OECD, as well as from States such as Russia with its digital sovereignty law and China with its law on cybersecurity and data security. This session also allowed to clarify perceptions such as ICANN’s position on the European NIS2 directive. Goran Marby indicated that ICANN does not have an official position on this issue.
The return of the GDD/GDS summit?
Until 2019, ICANN proposed a more operational summit called GDD Summit in addition to the three policy summits. This was abandoned in the context of the global pandemic and has not been mentioned since. The possibility of relaunching this mechanism was put on the table at ICANN73. There could therefore be a fourth annual ICANN meeting as early as the end of this year, with November being mentioned as a possible date. However, between now and then, there will be ICANN74 in June and ICANN75 in September, two events where the hybrid mode, face-to-face and remote, should be in place.
NameshieldComments
ICANN 73 was undeniably marked by the conflict in Ukraine. A conflict that paradoxically allowed to find a semblance of unity with the outline of solutions as the fact of allowing the Ukrainian registrars to derogate from the ICANN policies through a device called “extraordinary circumstances” and to recall the ICANN to its fundamentals, an apolitical body working for a global Internet. By mapping out the geopolitical, legislative and regulatory contexts, the body also seems to have realised that the world ahead may make it even more difficult to preserve its model of a globalised internet. The feeling after this summit is that more concrete proposals and perspectives have been given on some of the subjects discussed.
For the next round, it is the threat of alternative roots to the DNS that could give an unexpected boost to the current process. These roots that tend to develop could cause collisions between requests if one day identical TLDs cohabit in two environments, a risk that is all the more increased if ICANN marks the step on a future round. Another risk is to be challenged for the allocation of regulatory TLDs when an identical TLD would exist on an alternate root.
Important: information relating to the situation in Russia, Belarus and Ukraine.
In response to the evolving geopolitical situation in Ukraine, many SSL certification authorities are suspending the issuance and reissuance of all types of certificates affiliated with Russia and Belarus.
This includes suspending issuance and reissuance of certificates to TLDs related to Russia and Belarus, including .ru, .su, .by, .рф, as well as to organizations with addresses in Russia or Belarus. We will keep you informed as soon as the situation returns to normal.
Also, we observe a significant increase in phishing attacks. We advise you to be extra vigilant, especially when it comes to new domain name registrations using your trademarks.
Nameshield remains of course at your disposal to accompany and advise you in this complex context.
Since March 1st 2022, the Tanzanian registry allows the registration of .TZ.
A first phase of 3 months (until 31/05/2022) will allow the registration to the holders of .CO.TZ registered before 01/03/2022.
From 01/06/2022, it will be possible to register .TZ domain names equivalent to domain names recently registered in .CO.TZ (.co.tz registered after 01/03/2022).
Identity is an integral part of the digital world in which we live. Any individual, organization or computer is represented virtually by one or more identifiers, closely or distantly linked to different data. The digital identity allows to make the link between a real entity and its virtual representation.
Whether it is to authenticate, communicate or use a service on the Web, we use unique identifiers, which are associated with several personal information (email addresses, pseudonyms, random ids, etc.). These identifiers are usually managed by organizations that have control over our data. This data can be analyzed, altered, sold or stolen without the users’ consent, which represents a threat to their privacy. We must not forget that the data business is worth billions of euros; users do not always realize that their data has a real value.
It is from this observation that the concept of decentralized identity, also called self-sovereign identity (SSI), was born.
Decentralized identity aims to give users back control over their data, being at the core of Web3. It is based on decentralized identifiers (DID), deployed on a distributed registry. Users are the only ones who can manage their DID and the data linked to them. They can associate only the information they wish to share.
Several actors are developing solutions to build decentralized identity systems. Today we are going to take a look at one of them: ION (Identity Overlay Network). It is a decentralized identity management network, based on Bitcoin.
Source : https://identity.foundation/ion/
SideTree: an identifier management protocol
In 2017, members of the Decentralized Identity Foundation (DIF) began working on a solution to manage decentralized identifiers, particularly using Blockchains as registries. The idea being to register credentials on a block chain, so that they can be verified and self-monitored by their holders. Because of its decentralized registry properties, Blockchains are particularly well suited to this need. Several projects around decentralized identity have used this type of technology to manage DID.
One of the problems of blockchains is the difficulty to scale up: scalability. For example, on Ethereum the network is often saturated, which causes slowness in transactions processing and increasing costs. Other blockchains offer better performance, but make a compromise on security or on system decentralization. This is known as the blockchains trilemma.
For an identity system to work on a global scale, it must be scalable. For this, there are solutions called Layer 2. These are solutions built “on top” of an existing blockchain, in order to aggregate several operations into a single transaction. This allows to significantly increase the number of transactions per second that can be processed, and thus to decrease the costs. This mechanism is particularly used by the Lighning Network on Bitcoin, and by various applications on Ethereum.
The members of the DIF then developed a Layer 2 protocol to manage decentralized identities: SideTree. This protocol allows to create a network on which the different nodes are connected in peer-to-peer. The protocol can be adapted to different underlying blockchains, to offer some interoperability. It is also important to underline that it follows the recommendations of the W3C regarding DID and Verifiable Credentials.
SideTree is built with several software components:
REST API: an interface to allow users to interact with the system.
SideTree Core: this is the “logical” part of the system, which manages the various operations on the identifiers.
Content Addressable Storage: manages the storage of identifiers and their metadata. SideTree uses IPFS, a protocol allowing to store and distribute data in a decentralized way. A MongoDB database is also used for local storage.
Blockchain Adapter: allows to communicate with an underlying blockchain, in order to record “states”.
ION: SideTree protocol coupled with Bitcoin
Bitcoin as layer 1
ION (Identity Overlay Network) is an implementation of the SideTree protocol based on Bitcoin and developed by members of the DIF. Thus it is a public, decentralized identity management system that is not controlled by any organization. It is able to handle several thousand transactions per second.
SideTree also has other implementations, including Element, which is based on the Ethereum blockchain.
ION has chosen Bitcoin for:
Its decentralization:
The network is open to all
The nodes are numerous and decentralized
Transactions are transparent, checkable and unchangeable
Its security:
Bitcoin has proven its resistance for over 10 years
Participants are encouraged to maintain and operate the network
The cost of a 50% attack is extremely high, and considered impossible
DID and documents
Concretely, an identifier on ION looks like a unique and complex sequence of characters: did:ion:EiD3DIbDgBCajj2zCkE48x74FKTV9_Dcu1u_imzZddDKfg
This DID is linked to a JSON document that contains several properties.
The user can also add all the properties he wants. It is possible to obtain the document from the identifier, by performing a resolution. This can be done using the REST API of an ION node, or by using a dedicated explorer. The idea is to be able to retrieve the information associated with a DID, in the same way as when retrieving IP addresses associated with domain names (DNS).
How does it work?
To generate a DID, a user must either use their own node or use one available on the network. The node operator must have a wallet with Bitcoin, as the operation requires a transaction. Managing identifiers is a multi-step process, on the command line and through a REST API; it is not trivial.
Each identifier is linked to 3 pairs of cryptographic keys:
Update keys
Recovery keys
Signature keys
The operations carried out during creation are recorded in a file. This instruction file is distributed on IPFS, and its unique identifier is recorded in a Bitcoin transaction. Simultaneous operations on multiple identifiers are grouped together, in order to have a single executed Bitcoin transaction. SideTree uses Merkel trees to structure the states of the different identifiers, and to allow the management of a large number of operations per transaction.
All other nodes in the ION network observe Bitcoin transactions and extract those that match the ION protocol. They retrieve the instruction file from IPFS, thanks to the unique identifier contained in the transaction. Then they execute the instructions in order to update themselves and contain the latest created identifiers. Thus, the new identifier is distributed throughout the network. The synchronization time may vary; we have not found any measurements of this time.
By definition, DID are not transferable; the user at the origin of an operation on a DID is thus necessarily the “owner” and the only one to have control over it with his private key. This property allows, in particular, to do without a consensus mechanism during operations on DID, because there are no possible double expenses.
Which future?
Several use cases
The ION project is developed by members of the DIF, and actively supported by Microsoft. The American company wants to exploit this protocol to offer new services based on decentralized identity.
Several use cases are possible:
Users can create their DID and use the OpenID authentication system. Thus, it would be possible to authenticate on various applications, sites and web services with a unique and decentralized identifier. Passwordless authentication is possible.
Users could choose the data they want to associate with their DID and revoke their access at any time. Business models could be developed to pay users directly for their data.
Users can manage different identities with multiple DID, through their digital wallets.
Companies, schools or organizations can generate verifiable digital certificates associated with DID. (Verifiable Credentials).
DID can be associated with domain names, in order to use readable names rather than complex addresses.
Services to be developed
ION’s ambition is to become a standard for tomorrow’s decentralized identity. The ingenuity of the protocol is interesting, and could stand out from other competitive solutions in particular thanks to the use of the Bitcoin protocol. Layer 2 solutions are promising for many use cases, and can significantly increase the scalability of decentralized registries.
However, today the protocol remains complex to use; tools and applications to facilitate its use will have to be developed. Microsoft will certainly offer services using ION, but it is to be hoped that other players will follow this path, especially with non-proprietary “end solutions”.
Furthermore, the recommended technical specifications for deploying a node are quite demanding; this can represent a significant cost in terms of hosting. The cost of registering a DID is also the responsibility of the node operator, who will submit the transaction on the network. Thus, there is no economic incentive to deploy a node, other than to create a business model by selling DID registration to other users. At first glance, these elements may be barriers to decentralization and adoption of ION, but it is still too early to tell.
Many competitors
Competition is tough in the world of digital identity. On the one hand, there are the identity solutions proposed by the big players (Google, Facebook, Thales, etc.), which today dominate the market, and on the other hand, there are the sovereign identity solutions pushed by governments (France Connect, Essif, etc.). Alongside these more or less centralized systems, there are also many self-sovereign identity protocols. Apart from ION, there is also Ethereum Name Service based on Ethereum, Evernym, Sovrin and countless projects under development.
The realization of concrete applications and the adoption by the general public are essential points in the success of a project; time will show us which ones will make the difference and become indispensable to tomorrow’s Web.
Are you interested in blockchains and crypto-assets? Do not hesitate to visit the website of our expert Steve Despres: https://cryptoms.fr/
BIMI (Brand Indicators for Message Identification) allows you to authenticate your emails and reinforce the trust of your customers by displaying your logo in their inbox. VMC (Verified Mark Certificate) is a certificate associated with BIMI, which ensures the authenticity of the logo displayed.
What is BIMI?
BIMI is an industry initiative aimed at standardizing the use and display of brand logos in email clients. By placing a brand or company logo next to an email, it is more easily identifiable by customers and users, builds a sense of legitimacy and trust, significantly impacts open rates, and increases consumer protection against fraudulent emails.
Technically speaking, BIMI is an emerging security technology that works alongside DKIM, SPF and DMARC protocols to protect your domain name from being used by malicious actors to send fraudulent emails.
Before BIMI, the steps to get your logo next to an email were specific to each email service your message was sent to. Sometimes the process was entirely manual or relied on other applications to aggregate your brand information and share it across participating platforms.
The AuthIndicators group, which includes email service providers such as Google, Verizon Media, IONOS by 1&1 and Fastmail, is working to implement BIMI in the most common email clients. Many players have already adopted BIMI, others are in the process, Microsoft’s and Apple’s positions are expected to drive final adoption of the standard.
Why is BIMI important?
To complete the arsenal of a brand’s protection on the Internet, more specifically against hijacking attempts through fraudulent spoofing emails whose goal is to deceive the user and lead them to phishing sites.
306 billion emails circulated worldwide in 2020, with an ever-increasing proportion of fraudulent emails hijacking brands.
To increase the desirability of emails, particularly in marketing campaigns. The implementation of BIMI and more widely of security protocols and certificates on the domain name associated with a brand is essential today and has a major impact on online reputation.
Because it is becoming a market standard, easy to implement unlike the number of existing anti-fraud email solutions that are often difficult to test and implement.
How does BIMI work?
BIMI uses a process of several steps to validate emails by ensuring that they are actually associated with the sender’s domain name. Senders must add a TXT DNS record dedicated to BIMI.
For BIMI to work, domain names must also have several other fraud protections, including:
SPF (Sender Policy Framework): authenticates emails by identifying mail servers authorized to send from specific domain names ;
DKIM (DomainKeys Identified Mail): adds a digital signature to each email to verify that it was sent from an authorized domain name;
DMARC (Domain-Based Message Authentication, Reporting, and Conformance): confirms SPF and DKIM records and specifies how non-compliant emails should be handled.
When emails are sent using BIMI, the receiving mail server will first do the standard DMARC/DKIM authentication and SPF validation. If the email passes these checks, the mail server will verify that it has a valid BIMI record and display the brand logo.
How does BIMI interact with DMARC, DKIM and SPF?
The first step towards using BIMI to display a logo is to implement DMARC. This is stored as a DNS record of TXT type on the domain name. For DMARC to work with BIMI, the reject policy in this record must be p=quarantine or p=reject for all emails sent from your domain.
BIMI requires DMARC… and DMARC requires your domain name to have DKIM records to work. While DMARC only requires SPF or DKIM to work, it is best to include SPF records for more security when using BIMI. These 2 security tools are also stored as TXT DNS records in the domain name zone.
VMC, the final link in the chain
A Verified Mark Certificate is a digital certificate that authenticates the ownership of a logo, and completes the use of BIMI in email clients such as Gmail.
The VMC certificate guarantees the authenticity of the logo displayed, which is necessarily owned by the domain name holder sending the email. It is the last link in the chain to guarantee the authenticity of the email received.
When you send an email to a contact, the receiving mail server that manages their inbox will take the URL of the tag that indicates where the logo should be displayed. It will then check the VMC certificate to ensure that the correct logo is used. Once the logo is verified by the VMC, BIMI will display it next to the email in the inbox.
To obtain a VMC certificate, the implementation of DMARC on the domain name is a prerequisite. Then follows a reinforced authentication process with a Certification Authority that will validate the identity of the Organization, the registration of the logo with a certified body and will issue the certificate after a one to one meeting with a notary.
Depending on the country, the intellectual property offices for logos registrations may vary as well as the rules of acceptance to issue the certificate. The notions to keep in mind, the authorized trademarks can be:
Design trademarks: consist exclusively of a design;
Verbal trademarks: contain words, letters and/or numbers, without any particular font, size, color or style;
Combination trademarks: include a combination of words with a design, stylized letters or numbers.
While this is not a requirement for implementing BIMI on your domain name at this time, VMC should be part of the standard in the future.
Entrust Datacard and DigiCert are the first 2 companies to issue VMC certificates for the BIMI standard. Nameshield is a partner of both companies and will assist you in obtaining VMC certificates. You can contact directly our certificates department for any question on the subject.
BIMI + VMC = Guarantee of authenticity
BIMI, VMC… and Nameshield
Nameshield now assists its customers in all aspects of the implementation of DMARC, SPF, DKIM, but also BIMI protocols and the obtaining of associated VMC certificates. The domain name is at the core of the implementation of these different protocols. Our historical business as a registrar and DNS zones manager allows us today to assist our customers on these major subjects of the fight against online fraud and the increase of emails desirability.
Nameshield uses cookies
Nameshield wishes to use cookies to ensure the proper functioning of the site and, with our partners, to measure its audience🍪.
Nameshield wishes to use cookies to ensure the proper performance of the website and, with our partners, to monitor its audience. More information in our Cookie Policy 🍪.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
![[New gTLD] Launch of .KIDS](https://blog.nameshield.com/wp-content/uploads/2022/08/DotKids-Logo-Lg-new-1-1200x800.png){kind=logo}
![[New gTLD] Launch of .KIDS](https://blog.nameshield.com/wp-content/uploads/2022/08/DotKids-Logo-Lg-new-1.png){kind=logo}
