The elephant in the European Digital Identity Wallet room – how can service providers get paid?

From the legal foundation of the revised eIDAS Regulation, Europe is building a unified identity ecosystem. It is a clear intention of the regulation that private sector, commercial actors shall contribute to the ecosystem. But they can only do so if they can get paid, which everybody knows, but no-one seems to properly acknowledge—a classic case of an elephant in the room. Unless these actors in the ecosystem can get paid, we end up with an infrastructure that must be fully financed by government budget on taxpayers’ money, and that might not be what Europe needs.

We sketch four models to pay commercial infrastructure service providers at the end of this post. All require changes to protocols or use of additional infrastructure components. Metadata of payment information should also be added to ensure transparency of fees, e.g. for attribute attestations.

1. Ensure by protocol a call to the provider that shall receive payment, a “billable event”.
2. Introduce a clearinghouse role in the infrastructure.
3. Ensure by protocol that a smart contract is executed for payment.
4. Capitalisation on the role of intermediaries may alleviate the problem somewhat.

The European Digital Identity Framework and its ecosystem

The European identity ecosystem is centered around the European Digital Identity Wallet (EUDIW). All Member States must issue at least one EUDIW at the latest towards end of 2026. There is hectic activity, but notably almost only on technical matters and legal issues. Surely, there are challenges there, but let’s take for granted that the EUDIW and the ecosystem will technically work, and that it will be properly regulated. “Working” and “regulated,” however, are not the success criteria for the EUDIW; those are “widespread deployment” and “active use.”

The EUDIW ecosystem (source: EUDIW Architecture and Reference Framework)

The figure above shows “the official view” of the EUDIW infrastructure. This is a lot more than “the EUDIW”, and the EUDIW won’t work unless the other components are in place. Looks straightforward? Well, multiply it by 30 or likely a lot more. There will be one or several EUDIW instances per EU Member State plus the EEA states Norway, Iceland, and Liechtenstein.

Business models for roles in the EUDIW infrastructure

Any infrastructure will only work in real life if every role in the infrastructure can be taken by actors based on a sustainable business model. Only two business models exist:

1. Commercial viability, getting sufficient payment.
2. Government funding, or similar “donation” from non-government sources.

Several roles in the EUDIW ecosystem will for sure be funded by government, like accreditation, supervision, and operation of Trusted Lists of actors authorised for roles in the infrastructure.  The EUDIW itself can, according to the eIDAS Regulation, be provided by the government, on behalf of the government (an actor contracted and funded by the government to do the job), or by actors in the private sector approved by government. In the latter case, the Wallet Provider needs to get paid. The PID Provider (Personal Identification Data) role is kind of the same, where the government needs to exercise control but can leave the job to commercial actors. The same applies to Authentic Sources, which are government-approved sources of information, which can be the government’s own registers, but also can be provided by commercial actors approved by government.

Core to the topic of this post is the crucial role of (Qualified) Electronic Attestation of Attributes (QEAA/EAA) Provider, which according to eIDAS is a (qualified) trust service. And the eIDAS definition is “trust service means an electronic service normally provided for remuneration…..”. The intention is that (Q)EAA providers must get paid for their services. The exception is the PuB-EAA role, which is a public organisation providing attribute attestations directly from governmental Authentic Source(s).

The role of provider of remote (qualified) electronic signature (QES/QESRC) is also defined as a (qualified) trust service and hence a role that normally shall get paid for the services. The same goes for any issuer of certificates in the infrastructure, e.g. the role of Access Certificate Authority.

Device manufacturers and relying parties (read, service providers) do not depend on the EUDIW for their commercial income. 

The challenges of getting paid

eIDAS Article 5f requires that public services and a range of private sector service providers accept any EUDIW, all the 30+ EUDIWs, for authentication and access to services. If the service provider uses attribute attestations, it should accept any (Q)EAA provider that may have issued attributes for an EUDIW. The number of (Q)EAA providers to-be is unknown but can be big. While actors will adhere to common standards, they are different legal and commercial entities. There is a simplification; the trusted lists will ensure that all actors can be authenticated, and their authorisation for their role can be verified.

The usual way for a trust service provider to get paid is agreements with its customers regulating payment. While agreements are not prohibited, they are not required, or even foreseen, in the EUDIW infrastructure. How can actors then get paid?

Let’s look at the (Q)EAA role as example. As shown in the figure below, this role relates to three actors: the source(s) of the information that goes into the attribute attestation, the user that requests the attribute attestation into their EUDIW, and the relying party – let’s assume it’s a service provider of some kind – that obtains attribute attestations from the user’s EUDIW.

                            Issue and use of attribute attestations

Will the information sources pay? Possibly in some cases, like one could imagine a university paying a provider to make proofs of degrees available to EUDIWs. But in most cases no. A special case is a government paying a (Q)EAA to make information from the government’s authentic sources available, but then we are on the government funding business model. Payment is anyway easy as there is a direct connection between EAA provider and the information source.

Will the user pay? Again, possibly in some cases, like one could imagine that a user pays to get proof of their university degree. But in most cases no, or the willingness to pay is too limited for the EAA provider to make a business out of it. Payment can be arranged as there is a direct link between the user’s EUDIW and the EAA provider.

Will the service provider pay? Today, this is the actor that usually pays for trust services, and it is the actor that mostly will gain from getting attribute attestations in a trustworthy and easy way. But eIDAS requires unlinkability between the service provider and the EEA provider; an EAA provider shall not know where its attribute attestations are used. Attestations can be used towards any service provider, and there will (hopefully) be thousands of service providers accepting the EUDIW. Even if the service provider is willing to pay, how can this be arranged?

If there is payment for use of an EUDIW, the same challenge appears. The EUDIW can be used towards any of the thousands of service providers in the ecosystem, and the EUDIW provider shall have minimal knowledge of how the EUDIW is used. How can a service provider pay?

For remote signing services, the ecosystem leaves more leeway, e.g. the service provider can select one or a few remote signing services and use them subject to agreements and payment. But the competitive situation for remote signing is blurred by the eIDAS requirement that qualified signature shall be available “by default and free of charge” for the user, which is not a major change since even today the user rarely pays for signing. But the “by default” requirement will presumably by many Member States be solved by linking the EUDIW user to one specific remote signing service at the time of onboarding to the EUDIW. And the user may want to always use this service when signing. Then, the same situation appears: Unless signing is paid by the EUDIW holder’s Member State, how can a service provider pay any remote signing service attached to any user’s EUDIW?

Pre-requisites for paying trust service providers

Let’s try to be constructive. Below, we sketch some ideas but there can be other setups that can work, and some alternatives below may not be possible when studied with more scrutiny. In any case, we can’t see any way of paying providers in the EUDIW infrastructure without changes to protocols and specifications. Further infrastructure roles can also be possible. If such changes are to be incorporated for the EUDIW launch late 2026, we’re running out of time.

Without pre-settled agreements, subscription fees and similar types of payment seem impossible, and only transaction fees can apply. Two pre-requisites must be in place for payments to be possible:

1. Information on amount, payment method, and identification of receiver of the payments; the receiver should be known from current protocols as trust service providers in the infrastructure shall be authenticated.
2. Definition of events that trigger payment of a specified amount.

Number 1 is assuming one wants rates to be transparent, i.e. the service provider knows what to pay. Maybe it should be possible to reject use of an attribute attestation if the amount demanded from the EAA issuer is “outrageous”? The payment information must be available as metadata delivered with the attribute attestation or elsewhere, e.g. in trusted list entries (payment method could go there) or as part of the attribute schema. A setup must cater for the fact that an attestation may consist of parts from several EAA issuers, and different attestations will have different pricing.

Regarding number 2, definition of “billable events” is in general difficult but may in this case have extra challenges. If an event is only recorded locally to the service provider, one must either trust the provider to be honest or have a mechanism to detect free-riders. Otherwise, a billable event towards the EAA issuer (or other actor to be paid) or towards another, trusted actor must be mandatory for the protocol.

Sketches of payment models

Four models are briefly discussed below. The first one may be the most realistic approach, but more study is needed on that one as well as the other, or any other idea that might emerge.

Alternative 1: Ensure a billable event towards the provider that shall be paid

A service provider or other actor relying on EUDIWs must validate the information received, identity and attributes. A suggestion being discussed in the European standardisation organisation ETSI is to require a validation check that triggers a transaction towards the actor that needs payment, e.g. an EAA provider. In this proposal, the key management setup ensures that the EAA provider will be informed by the relying party of each use of an attestation (and can charge for this), while ensuring that the EAA provider is not able to determine which attestation (of which end-user) is being used. See this presentation for more on the suggested approach.

The transaction will create a billable event at the EAA provider, and invoicing or other type of payment can be done towards the actor asking for the validation. Payment information can be metadata for the validation request, even up to authorisation to charge a bank account or payment card, or be included in the Trusted List of relying parties and/or the national register of relying parties, e.g. for sending an invoice. A standardised validation protocol is needed, and all actors must support that protocol. A standard from ETSI can be the foundation.

Today, revocation/status information is published as revocation lists, and download of such a list doesn’t create the billable event. And status check is not mandatory for attestations with a shorter lifetime than 24 hours. For a billable event, the status check must always be mandatory and be a real transaction and not only download of a list.

This approach can work without any addition of payment metadata to attribute attestations but then the approach may not be transparent regarding the cost of the attribute attestation.

Alternative 2: Use a clearinghouse

A new role of payment clearinghouse can be added to the EUDIW infrastructure. Actors that need to pay can send the amount to the clearinghouse, specifying who the receiver is but with minimal information on what the payment is about. The clearinghouse settles payments and pays the actors regularly according to payment information included in Trusted Lists or elsewhere. This requires at least amount to pay to be available as metadata for an attribute attestation. 

In this case, the billable event is local to the service provider, and one must trust this actor to pay. Mechanisms to avoid cheating could perhaps be possible but require more study and would result in changes to protocols in the ecosystem

Adding the role of clearinghouse to the EUDIW infrastructure will require legal work to set requirements on the role, but this may refer to actors already authorized for payments. Standards or specifications must be in place for the payment transactions.

Alternative 3: Smart contracts 

Another alternative related to revocation/status checking is to set this up in a ledger, where checking would execute a “smart contract” to carry out the payment. Use of ledgers, notably the European EBSI initiative, is not specified for the EUDIW infrastructure but is being studied by the DC4EU pilot. This alternative would require all actors to publish status information in a standardized way on the ledger and a protocol to be defined for the checking. The amount to pay can be transparently available on the ledger.

Alternative 4: Use intermediaries to reduce complexity and alleviate the problem

The EUDIW Architecture and Reference Framework recognises the role of “Intermediaries acting on behalf of relying parties…offers services to Relying Parties to, on their behalf, connect to Wallet Units and request the User attributes that these Relying Parties need”. A service provider will integrate only to a single intermediary, which in turn integrates to all the national EUDIWs and handles all attribute attestations and possibly also signing on behalf of the service provider. While there are still scaling issues, an intermediary may be able to enter agreements with all relevant parties: EUDIW issuers, (Q)EAA providers, and remote signing service providers, and ensure payment “the usual way” for trust service providers. The intermediary will receive payment from service providers and pay the trust service providers in the EUDIW infrastructure accordingly. 

The intermediary setup is foreseen as crucial in the start of the EUDIW journey to relieve service providers of the complexity of the infrastructure and get them going. However, use of intermediaries will of course not be mandatory, so settling payments through intermediaries will only somewhat alleviate the situation. 

Conclusion

Now that we’ve identified and revealed the big elephant in the EUDIW room, it’s time to handle it. Let’s start finding solutions. And not least, let’s tell the European Commission and the Member States’ representatives in the European Digital Identity Cooperation Group that they too need to open their eyes and see the elephant.

About the author

Jon Ølnes is a leading expert in digital identity, with over 25 years of experience in eIDs, electronic signatures, and trust services. He plays a key role in shaping European policies on digital identity and recently led the revision of ETSI’s identity proofing standard. At Signicat, Jon has spent the past five years driving product development for the European market.

Written in cooperation with Esther Makaay, Vice President, Digital Identity at Signicat