The IRMA app is a digital wallet that holds personal information, such as a user’s name, mobile number and citizen service number. IRMA allows users to disclose this information to requesting parties, e.g., to log in to a website. A core principle of IRMA is that users are in control about whether they disclose their data. To decide this, users need to know who is asking for their information, what information is requested from them, why it is required and how it will be used. Together, the IRMA made easy project and the IRMA team at SIDN have looked into how to present the information about who is requesting information from users more clearly and intuitively. In this blog post, we present the outcome of this investigation and the resulting new feature, which is called pretty verifier names.

Displaying verifiers in IRMA

In the IRMA ecosystem, verifiers are the organisations that want to know something about their users. For instance, a webshop might want to know the address and bank account number of a customer. When a user encounters such a request, the IRMA app asks them if they wish to reveal the requested data to the verifier. If they agree, the information goes directly from their phone to the verifier.

To make an informed decision about whether to disclose the data or not, it is crucial that users know who is asking for their information. In the current implementation of the IRMA app, IRMA displays a URL to inform users about who will receive the data if they agree to the request. For instance, when using the video call service irma-meet, a disclosure request will look like this (see screenshot):

Screenshot: When facing a disclosure request, users see the name of the verifier (requesting party) in the form of an URL.

At this step, users need to check the URL of the verifier in the IRMA app to make sure the data will end up in the right hands. If the IRMA app shows a suspicious verifier (e.g., irma-meat.nl instead of irma-meet.nl), users ideally notice this and decline the request.

The problem

For end-users, a URL makes it difficult to quickly judge whether the requesting party is the organisation to whom one wants to disclose the data. For instance, during a user test conducted by the municipality of Amsterdam, people were confronted with “attr.auth.amsterdam.nl” as the verifier URL. Such a URL can cause distrust and scare people – even in cases where the URL is legit. At the same time, URLs make it difficult for people to spot tiny alterations that indicate something shady is going on. Thus, fishy URLs might go unnoticed and not raise any suspicion when they actually should.

What is more, because companies might want to run their IRMA server at an external party, users might get confused by seeing the URL of the external party rather than the URL of the verifier. In such situations, it is hard - if not impossible - for users to judge if they should disclose the data to the displayed party.

From a company’s perspective, the display of a URL is also not ideal. Companies certainly do not want users to experience anxiety or doubt about their data requests. It is in their best interest that users can trust that their data falls into the right hands. Also, more fundamentally, companies usually have a name and prefer being referred to by this name. For brand recognition, companies also often like to accompany their name with their logo.

The solution: pretty verifier names

To allow IRMA users to understand who is requesting information from them, protect users from phishing attacks, improve the user experience, establish trust, and make companies more recognisable in the IRMA app, a new way of displaying the verifier is to need.

The IRMA made easy project has taken up this challenge on the UX side of things by creating mockups and designing a possible solution. By now, the IRMA team at SIDN has implemented this suggestion. The resulting concept is called pretty verifier names. With this feature, IRMA now displays the requesting party’s name, together with a badge and an optional logo. The blue badge indicates that the name has been verified by SIDN. (This badge is similar to the badges used by Twitter to indicated verified accounts.) The URL is no longer visible. Rather than seeing, for instance, the URL “login.irma-meet.nl” the user can see the word “IRMA-meet” (see screenshot). The resulting text is much more human-friendly, and the logo allows for quick recognition.

Mockup: The "pretty verifier names" feature displays the name (and optionally logo) of the requesting party rather than an URL.

The pretty verifier names feature is part of the current beta release, and it is only a matter of time before it will make it to the production release of the IRMA app. Users who have the beta app installed can already try the feature, for instance, by visiting the IRMAtube demo.

Because the requesting parties need to be verified by SIDN before getting a pretty verifier name (a human-readable name, badge and optionally logo), many requesting parties are still displayed as a URL. But all the IRMA demo’s of the Privacy by Design Foundation (except for AngryGames) are using the feature. Furthermore, verifiers that also issue IRMA cards already have a pretty verifier name. You can find the list of these parties here. We expect this list to grow soon.

How to get a pretty verifier name

In principle, every organisation can get a pretty verifier name. However, verifying the party behind a specific URL is currently done by SIDN manually and individually for each organisation. The verification process entails a check at the Kamer van Koophandel/KvK). (In cases where there is no KvK registry, alternative processes are in place.) Because of this manual process, the feature is introduced gradually. It also comes with some costs. Interested parties who want a human-readable name, badge and optionally a logo displayed instead of the URL can contact Bob Kronenburg at SIDN (see contact-data at the bottom of the site).

Limitations

Pretty verifier names give users certainty about who is requesting their data. One limitation of pretty verifier names is that they can not prevent imposters. A verifier who, e.g., uses the URL IRMA-meat.nl will still be able to ask users for their data – and users might still mistake it for IRMA-meet.nl. However, once most verifiers use pretty verifier names, users might be triggered to be cautious whenever they see a URL instead of a human-readable name. The feature needs to be implemented more broadly, and users need to get used to seeing pretty verifier names before we can tell whether this is indeed the case.

With the new feature in place, IRMA provides users with clear information about who is requesting data and what data is asked for. However, it tells users nothing about why (for what purpose) the requesting party needs the information or how it will use it. To allow users to make an informed decision, the requesting parties need to explain why they need the data and what they will do with it on their own website. This means users need to integrate information from different sources (the verifier’s website and the IRMA app) in their decision-making process. This can feel unnecessarily complex.1 In the future, it would be nice to explore if there are possibilities to include verified (or at least contractually binding) information about why and for what purpose information is requested from users in IRMA as well.

It is also important to realise that a pretty verifier name does not tell users anything about whether the request is reasonable. A webshop with a pretty verifier name, e.g., could still ask people for their BSN. Such a request would still be unjustified. In the end, users still need to think for themselves whether they want to disclose the information to the requesting party. A possible danger of the pretty verifier name and verification badge could be that it serves as a visual heuristic that nudges users to share their data without thinking and gives them the feeling that IRMA has approved the request itself. Thus, user tests should verify whether users correctly understand that the pretty verifier names only inform them about the requesting party and do not indicate that IRMA approves of the request.

Conclusion

With the design concept for the pretty verifier names, the IRMA made easy project has yet again contributed to a better IRMA user experience. We expect the feature to help users easily understand who is requesting information from them. We also think it will make companies more recognisable in the IRMA app. We hope this increases trust when this is justified and help users be cautious when this is necessary. Some benefits are expected to come from long term use and broad adoption. We thus hope many verifiers will make use of the feature and thereby help to make IRMA easy.


  1. There are reasons not to provide information about why (for what purpose) an organisation is requesting data and about how it will use the data in the IRMA app. IRMA only displays information that has been verified and thus can be trusted. The team behind IRMA can’t verify why a specific party is requesting information and what this party does with the data. By including such information, the IRMA app would mix information that has been verified, and that can be trusted (what is requested and by whom) with unverified information about why the data is needed and how it is used. In order to ensure users can trust all the information in the IRMA app, the disclosure screen can thus only show who is requesting information and what information is requested. ↩︎