Digital Identity Wallet room – how can service providers get paid?

The European Digital Identity Wallet (EUDIW) is set to transform digital identity across Europe, but a crucial question remains unanswered: how will commercial actors get paid? While the eIDAS Regulation envisions private sector participation, sustainable business models are missing from the discussion. Without viable payment mechanisms, the system risks relying entirely on government funding, which may not be ideal. This post written by Jon Ølnes explores potential solutions and payment models to ensure a financially sustainable EUDIW ecosystem.

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.

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.

Model 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.

Model 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.

Model 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.

Model 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.

Read the article in full