/
GS-ADR-0001

GS-ADR-0001

Owned by Ali González
Last updated: Feb 25, 2025
5 min read

Go to:Architectural Decision Records

Status

Date

Decision Makers

Consulted

Informed

Status

Date

Decision Makers

Consulted

Informed

DRAFT

2025-02-06

Wallet Working Group

Architecture Committee

Technical Committee Facilitation Team

Governance Committee

 

Solve compatibility between eIDAS 2 and Wallet Building Block

Context and Problem Statement

The current conflict regarding the Wallet Building Block is that some of the group members have a professional opinion that it is not possible to have a technical software component that would work in EU that without being fully compliant with eIDAS - essentially that "digital service" of a wallet is equal to the technical component(s) of the wallet and cannot be separated. - @Kristo Vaher

The current Identity BB draft isn't a wallet according to eIDAS (Article 3, point 44)—it's specs for the "Electronic Attestation of Attributes" feature, part of the Wallet, but not the Wallet itself. - @Ott Sarv

Related Meeting Minutes

Decision Drivers

  • The challenge arises from the fact that eIDAS not only defines policies but, through Implementing Acts and Architecture & Reference Framework, also defines the technical architecture and standards to be used and how. - @Torsten Lodderstedt

  • Other jurisdictions use other technologies or a different mixture thereof. Moreover, eIDAS has a broader scope than just wallets. Also, eIDAS has (currently) unique requirements (e.g. on wallet to RP authentication). - @Torsten Lodderstedt

  • Wallet-BB is not a Wallet in itself, but a descriptor of the Electronic Attestation of Attributes (EAA)

    and the Electronic Presentation of Attributes (EPA) so the name Wallet is misleading. - @Ott Sarv

Considered Options

  • Come up with a common denominator (conceptually and technically) among wallets being built in different jurisdictions: Such a common denominator (a wallet core spec if you like) could be used and augmented to build wallets for certain jurisdictions. That's how I have perceived the wallet build block document so far. - @Torsten Lodderstedt

  • Write a Building Block that is a super set of all required technologies: Given the fact that other jurisdictions require other technical standards, this could be a solution (e.g. OpenID4VC, ISO, DIDComm, ..., W3C VCs, ISO mdoc, IETF SD-JWT, ...). That's the way some of our projects at OpenWallet Foundation (https://tac.openwallet.foundation/projects/ ) have decided to pursue. - @Torsten Lodderstedt

  • Proposal on how we could check compatibility of non-BB software: The idea: compatibility is measured by fulfillment of cross-functional req AND with integration of the foundational BBsNon-BB Software Integration Compliance (proposal) BB Specs Value Proposition and Guiding Requirements - @Nico Lueck

  • Turn the current Wallet BB into a reusable Attributes Attestation FBB: or a subset of an FBB (in my opinion) that includes the attestation feature but isn’t a full FBB. - @Ott Sarv

Decision Outcome

Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.

<!-- This is an optional element. Feel free to remove. -->

Consequences

  • Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}

  • Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}

  • … <!-- numbers of consequences can vary -->

<!-- This is an optional element. Feel free to remove. -->

Confirmation

{Describe how the implementation / compliance of the ADR can/will be confirmed. Is there any automated or manual fitness function? If so, list it and explain how it is applied. Is the chosen design and its implementation in line with the decision? E.g., a design/code review or a test with a library such as ArchUnit can help validate this. Note that although we classify this element as optional, it is included in many ADRs.}

<!-- This is an optional element. Feel free to remove. -->

Pros and Cons of the Options

Proposal 1: Technical Wallet and Trust Services Building Block

Estimated delivery time:

2 weeks for BB-Technical Wallet + What’s needed for Trust Services BB (unknown, TBD)

How does it work:

  1. The current scope of wallet building block would be split in two to consist of the technical wallet component building block and then a second "trust service" building block.

  2. Terminology of the current wallet building block should be updated and anything related to trust services (if such exist) to be removed from its scope.

  3. Trust service building block scope should be defined likely by the wallet and digital identity building block working groups.

  4. A dedicated working group will be called to start contributing to the trust service building block.

More information is available on this Minute:

2025-02-06 - ARCH - Meeting Notes

Pros:

  • Good, because {argument a}

  • Good, because {argument b}

Neutrals:

  • Neutral, because {argument c}

Cons:

  • Bad, because {argument d}

  • … <!-- numbers of pros and cons can vary -->

Proposal 2: Electronic Attestation of Attributes and Electronic Presentation of Attributes + Roadmap for the rest of the Building Blocks

Estimated Delivery Time:

  • Stage 1: ~2 weeks to Draft and turn Electronic Attestation of Attributes (EAA) and Electronic Presentation of Attributes (EPA) into release

  • Stage 2: ~40 days for the rest of the Building Blocks, however, they need to be treated as new specifications and each should follow its own process

How does it work?:

The current Wallet BB will be split into two distinct Feature Building Blocks (FBBs):
Electronic Attestation of Attributes (EAA)
Electronic Presentation of Attributes (EPA)

  • The spec needs updating to reflect this modularity and align terminology with the eIDAS framework for clarity.

  • GovStack will no longer define a standalone Wallet BB but instead provide modular & interoperable FBBs based on eIDAS features.

  • Each country will define the internal Wallet architecture based on its specific use cases and chosen components.

  • This approach ensures GovStack remains usable for Wallet use cases inside and outside the EU while remaining flexible for different regulatory environments.

  • If a country wants to build a Wallet, they can do so using GovStack’s modular specifications, ensuring interoperability without dictating architecture.

  • The rest of the components are mapped put on an open road-map by Wallet WG, AC WG, and other related WG’s (such as ID). The goal is to have (f)BBs as modular components (Lego pieces) for solutions considering the whole ecosystem around it rather than pre-built solutions, then Wallet, Identity, and Electronic Signature solutions involve approximately 26 BBs and 22 FBBs (this initial iteration has been identified by @Ott Sarv which includes components such as Certificate Authorities, Timestamping Service, Electronic Attestation Validation, Electronic Attestation Verification, Electronic Signature Validation)

Pros:

  • At two-thirds of these BBs and FBBs are reusable and required by most modern e-Government solutions. Identity, authentication, authorization, and electronic signatures are the foundation of any e-Gov system

  • Electronic Attestation and Electronic Presentation are basics of a Wallet solution and the progress on the Wallet BB can be used for term harmonization to publish

Neutrals:

  • Neutral, because {argument c}

Cons:

  • Bad, because {argument d}

  • … <!-- numbers of pros and cons can vary -->

More Information

References

External

Internal

Related content