On August 14, over 50 representatives of internet organizations met at the headquarters of DENIC, the German top-level domain registry, to attend the first ID4me summit. ID4me is the current name of the project, which was started last year under the name DomainID — I mentioned it briefly in my presentation at our last year’s conference IT 17.2. It was initiated by the .DE domain administrator, together with the major German registrar 1&1, and Open-Xchange, the operator of online collaboration tools. However, there are many other companies that are willing to support it, including the UK domain registry Nominet. The goals set by the project are quite familiar to us — reducing the number of passwords and registrations that people need while using the Internet. Like CZ.NIC with its mojeID project, the authors of ID4me have come to the conclusion that the domain world is just the place for an attempt to achieve these goals.
Unlike mojeID, which is a ready-to-use service, ID4me seeks to create an ecosystem of collaborating organizations that will support the solution described by a set of standards developed within the project. A relatively large campaign has succeeded in inviting a number of interesting companies into this ecosystem. Quite recently, ID4me AISBL (Foundation) was established in Brussels, which will be a member organization backing all activities related to the project. At the moment, the development of the project is concentrated around three working groups and their corresponding mailing lists. The technical working group addresses the protocols and specifications on which the project is based. The governance working group addresses how the ecosystem should work at the level of different (e.g. legal) relationships between its members. The last adoption working group is focused on marketing the entire project.
From a technical standpoint, ID4me builds on the OpenID Connect standard, which provides a fairly good starting position for interoperability with existing systems. In mojeID, we have supported this protocol since 2015. ID4me, however introduces three concepts that are not very common and reflect the effort to link the world of identities to the world of domains.
The first of these concepts is to divide the authentication service into two entities. The ID4me terminology operates with Authorities and Agents. An Agent is an entity to which the customer comes first, provides it with his or her data and requests the service. As you may have already guessed, in the world of domains, such entity is called a Registrar. An Authority, on the other hand, is a service that guarantees ownership of the identifier and assigns it to a particular user. Again, the corresponding entity in the domain world is a Registry. An Authority is therefore responsible for verifying the user’s credentials, and an Agent is responsible for storing and forwarding his/her additional data. The way this concept is mapped on the OpenID Connect protocol is quite unique. In OpenID Connect terminology, this approach is referred to as “Distributed claims”. As usual, an OpenID Connect user would log in with the Authority, but instead of passing the data of the logged-in user, the Authority would provide an address from the Agent’s system, where the data can be accessed. However, one particular entity may play the role of both the Authority and the Agent. For a standard service that enables sign-in with OpenID Connect, this distribution should not pose a problem.
The second concept is the idea of establishing a domain name as the primary identifier. A user would purchase a domain and use it to log in to all systems supporting ID4me. Only by manipulating the domain’s DNS record can the user determine who the Authority and Agent are for this domain name. This is determined by a special TXT record for the _openid subdomain. Of course, records on this domain must be secured using DNSSEC. In theory, this should allow the domain holder to switch to a different provider of identity services by simply changing the TXT record. Although there are efforts to standardize this way of initial user identification, it is not currently part of the OpenID Connect standard, and changes on the part of service providers are required.
The third concept, which is closely related to the second one, but which I see as a separate element, is the effort to provide a service that uses ID4me with information that the logged-in user is indeed the holder of the selected domain. This information becomes available upon login from the special id4me_identifier attribute. A certain level of trustworthiness is given to this attribute by an authentication process using a DNS variety of the ACME protocol that the Authority should execute before it creates an account for the user. However, this is a one-time verification at registration, which does not tell anything about the current status. In addition, if this verification was mandatory, it would limit the involvement of existing services. However, according to my information, introduction of this obligation is not yet on the agenda.
The ID4me authors do not satisfy themselves with theory and have prepared a set of libraries that implement the described concepts. There is a project on Gitlab, where you can download the code or discuss the proposed changes. There are already some pilot projects that allow logging through ID4me. In order to test ID4me compatibility, we have added the necessary DNS record in the following format:
_openid.mojeid.cz. IN TXT “v=OID1;iau=mojeid.cz/oidc;iag=mojeid.cz/oidc”
If you want to log in to the Open-Xchange collaboration solution using mojeID, simply type mojeid.cz into the form and click the “Sign with ID4me” button. If you also register a domain and add the same TXT record to it, you will become able to sign in using your domain. Similarly, you can test your login to the AndroidPIT technology news server. It will be interesting to see further development of this project.