EU Wallet In Depth #4: The Missing Network
Now the EU Digital Identity Wallet (EUDIW) Architecture Reference Framework (ARF) has been published, we can get a really good insight into the plans for the world’s largest digital credential ecosystem. I’m going deeper into a number of parts of the ARF and give you my thoughts on some key areas that merit further attention.
Having kicked off with Trusted Lists in post #1, covered use of the EUDI wallet without a PID in post #2, and decoupling of issuers and verifiers in #3, now it’s time to look at a conspicuous omission in v1 of the ARF.
The ARF doesn’t yet specify the “Layer 1” verifiable data registry or registries (“VDR”) that will be used by the EUDIW. This means that we’re missing an important building block in the EUDIW ecosystem, and this component provides the root of trust for the entire ecosystem.
To understand all the components that you need in a digital credential ecosystem, it is useful to have a model or framework that you can use to piece them together. It then quickly becomes obvious if you have any gaps that need filling.
I’ve found that the best model to use is the one developed by the Trust Over IP Foundation, and you can find an interactive version of it on their website which is really useful.
In this post, I’m referring to the bottom layer, which is the place where information that is vital to the functioning of the ecosystem is held. This is commonly called a “verifiable data registry”, as it is a place where you can be very sure that the data within is genuine and authentic. Anyone who wants to verify the authenticity and validity of a credential can look up the required data and check it is OK. Such data is likely to include public verification keys, credential schemas, revocation registries, trusted lists and organisation identifiers.
Here are some of the parts of the ARF that indicate the need for a layer 1 verifiable data registry:
4.1.3. Person Identification Data (PID) Providers: make available information for Relying Parties to verify the validity of the PID. (Footnote: Without prejudice to the actual mechanism of how the information is provided, including whether directly or indirectly.)
4.1.4. Trusted List Providers: When used, Trusted Lists need to provide a registration service for the relevant entities, maintain a registry and enable third party access to the registry information.
4.1.10. Relying Parties: To rely on the EUDI Wallet, Relying Parties need to inform the Member State where they are established and their intention for doing so. Relying Parties need to maintain an interface with the EUDI Wallet to request attestations with mutual authentication. Relying Parties are responsible for authenticating PID and (Q)EAA.
4.1.14. Qualified and Non-Qualified Electronic Attestation of Attributes Schema Providers:?(Q)EAA Schema Providers publish schemas and vocabularies describing (Q)EAA structure and semantics.
6.2. Architecture Components: “Cryptographic keys management system. This component is responsible to manage and store cryptographic information like the private keys generated for instance during the PID issuance process.”
Currently therefore, the ARF is quite “loose” when it comes to specifying where and how such verification information, keys, trusted lists will be stored. This does allow freedom for developers to come up with the best option, but similarly it opens the door for a proliferation of different methods causing confusion and technical complexity.
If I were a wallet developer, I’d be looking to someone to provide me with clear guidance of which layer 1 infrastructure to use, otherwise there’s no way I’d be able to develop an app that works (though I could guess, or decide on my own of course).
This brings us back to post 1 in this series about trusted lists, and the possible multitude of them that will emerge. Technically, these trusted lists have to be stored somewhere. In this post I’m letting you know that there’s a lot more that also needs to be stored somewhere, including issuer public keys, schemas, revocation registries etc. The risk is that, without clear direction of which verifiable data registry to use, we have uncertainty, confusion and delays.
领英推荐
Thankfully there is some detail in the ARF that points to a need for one or more VDRs, for example 5.1.2 details what is required of PID issuers:
PID attestation MUST contain the information required to identify the PID Provider.
PID attestation MUST contain the information required to perform a data integrity check.
PID attestation MUST contain the information required for verifying the authenticity.
PID attestation MUST contain all the information required to perform validity status checks on the attestation.
We can see that any PID (to take one credential type example) must contain the information needed to point the holder and verifier to a place (a verifiable data registry) where they can find the required keys, lists, schemas etc. The ARF is also clear that these specifications will evolve over time.
Given the parallel funding that has been given to the European Blockchain Services Infrastructure (EBSI) to further develop their VDR, and the impressive level of advancement of their trusted issuers list, I can assume that EBSI is in the running to play a significant role as an EUDIW VDR.
And this brings us neatly to the multi-protocol nature of the ARF, which I’ll cover in detail in the next article. Two protocols currently specified. The PID (for example) will have to be issued in both formats:
PID attestation MUST be issued to be presented in accordance with both the data model specified in ISO/IEC 18013-5:2021 and the W3C Verifiable Credentials Data Model 1.1.
These different formats use different methods for key storage and retrieval, which points to having at least 2 VDRs in the ecosystem. When you add in the fact that individual Member States may implement their PID and EUDIW differently, the number of VDRs could multiply.
As someone who has been intrinsically involved in credential wallets for the last 7 years, I know how difficult it is to handle just one VDR from a wallet app. Handling multiple VDRs, and being able to dynamically select the right one, is a tough ask.?
And of course, someone has to build, run and operate each VDR. This is a challenge in itself as I know only too well, having been involved in the creation of the Sovrin network in 2016.
In conclusion the following still needs to happen: