wb-147: Add ecosystem overview diagram to architecture overview#199
wb-147: Add ecosystem overview diagram to architecture overview#199eklaver wants to merge 2 commits into
Conversation
|
Thank you very much for this work, @eklaver! My only concern is that the EBW boxes might confuse issuers and verifiers a bit since we haven't generally been talking about "wallets all the way" (until now) - but all problems are solveable. @webuild-consortium/blueprint-coordination-group what do you think? @lalc @leifj @gfour for a start? (@malinnorlander has been involved in the issue discussion and @sander is on vacation) @peppelinux, @Sebastian-Elfors-IDnow any takes on the drawing? |
|
I think it might be good if the arrows from the Wallets to the Trust framework said "verifies and validates" somewhere, but except for that, this drawing is fine by me. |
|
Ok, I can update that |
Co-authored-by: Sarah Amandusson <80251383+Saramandus@users.noreply.github.com>
|
BU2 will use EBW for issuance and verification for Issuer and Verifier roles. I think we will confuse issuers and verifiers if we say not to use EBWs. |
|
So, are you saying that the only way to issue an attestation into an EUDIW (or to receive a presentation from one) would be through an EBW? |
|
My view is that adding EBW "all the way" will add a layer of complexity that is not compatible with the eIDAS2 CIRs, EUDIW ARF and the ETSI/CEN standards. The PID/EAA issuance protocols have already been specified by the ARF, OID4VCI, ETSI TS 119 472-3 and CEN TS 18099. It will be too challenging to design and implement all those protocols in an EBW as an issuer intermediary. The PID/EAA presentation protocols have already been specified by the ARF, OID4VP and ETSI TS 119 472-2. The ARF allows for a WRP intermediary, which should then use a WRPAC. If the EBW plays the role of a WRP intermediary, the EBW would need a WRPAC, which is a bit oakward since the EBW is a wallet in itself. |
|
I do not understand at all. Are you then saying that instead of a few wallet providers imlementing the standards, protocols, security and so on, we all have to implement components ourselves? Why on earth should we introduce intermediaries when we can just use EBWs? I don't understand the argument "The PID/EAA issuance protocols have already been specified by the ARF, OID4VCI, ETSI TS 119 472-3 and CEN TS 18099. It will be too challenging to design and implement all those protocols in an EBW as an issuer intermediary." As they must be implemented, who shall implement them if not EBW? As an RP and Issuer I fully intend to buy a EBW that does it all for me, I have no interest in either an "issuer intermediary" or an "rp intermediary", they bring no value and only inceases complexity in comparison to EBWs. |
|
I'm not sure "either EWB or intermediary" is the correct dichotomy here. Both are possibilities, but issuing/verifying with neither one nor the other is an option just as well. To cite the longstanding meme, your issuer/verifier component could even be a dog as long as he speaks the protocols and is on the trust list. ;-)
This may be true for your situation, but others may have different views. I believe the challenge is that this PR aims to mandate one specific setup (which, as Sebastian pointed out, is not grounded in eIDAS/the Implementing Acts) where instead implementers' choice should be maintained. CC @austenaa @ardvanderheijden @LaurentBailly-Visa @KevinBVN for awareness |
|
Well, according to Stefans post there is no choice for EBWs. And the point of the consortium, as I was lead to belive, was to pilot use cases utilizing wallets, not intermediaries, not components that act like wallets but aren't, but EUDIW and EBW. What choices are made in production can be different from what we pilot, but as I understood, our focus in WB was to use wallets and show the comission what an eco system of wallets can look like, what the benefits are, how complexity is reduced compared to other systems, how security is implemented, how to build a scalabale trust framework, how wallets support automated use cases and brings business value. That is really hard to achive when not using EBWs. |
This I don't understand. Could you elaborate?
From what I see, each and every Use Case in WE BUILD contains an EUDIW, an EBW, or both. At the same time, wallets (at least EUDIWs) communicate with Wallet-Relying Parties, which can come in a number of shapes and forms. |
|
Thanks, @eklaver, for the drawing; @Saramandus, for moving this forward; and @malinnorlander, @Sebastian-Elfors-IDnow, and @stefan-kauhaus for the review. WE BUILD's purpose, as set out in the DoA, is to define and build the European Business Wallet so that usage of the EU ID Wallet scales securely and in compliance with applicable requirements. The DoA scope and the Use Cases, including BU2 and PID/EBWOID, consistently assume EBWs on the Issuer and Verifier sides. The blueprint's ecosystem overview should reflect that as the WE BUILD reference pattern, IMHO. There is also a practical observation from our earlier LSP engagements that further strengthens this position. Except for pure-issuer cases like WUA and PID, almost no Issuer in the EUDIW or EBW ecosystem is only an Issuer. A bank issuing a payment attestation first verifies PID and supporting QEAAs. A university issuing a diploma first verifies the PID/Or any ID and enrollment. An employer issuing an employment attestation first verifies PID and right-to-work credentials. In other words, real Issuers invariably exercise both Issuer and Verifier capabilities in the same business flow, which is exactly what an integrated EBW provides out of the box. Coming from a PKI world, I would go a step further: A holder capability on the organisation side is what enables Issuers and Relying Parties to scale beyond the trust mechanisms available today. Once an organisation needs to assert its own attestations (EBWOID, Mandates, QEAAs) to many counterparties, the wallet trust fabric scales in ways that bilateral trust establishment or federation arrangements do not. This is exactly the EBW value proposition the WE BUILD Consortium was set up to evidence. The component-level protocols (OpenID4VCI, OpenID4VP, ETSI TS 119 472, CEN TS 18099) of course remain implementable piece by piece, and nothing here contradicts that. The point is that an integrated holder/issuer/verifier stack tends to deliver better UX, lower integration cost, and a cleaner upgrade path as HAIP, TS 119 472, and TS 12 evolve. That is a hypothesis that the WE BUILD pilots are well placed to evidence. The concerns raised on component conformance under eIDAS2 and on WRPAC handling for a wallet-shaped intermediary are valid and worth addressing. A small wording adjustment under the diagram could clarify that the EBW configuration is the WE BUILD reference pattern, without implying it is the only conformant approach. The WRPAC question for a wallet intermediary could usefully be tracked as a separate issue, so it does not block this PR. Happy to help draft either the wording tweak or the follow-up issue if that would be useful. |
|
I fully agree with @malinnorlander that we are building and piloting the EUDIW/EBW in this consortium, so why would we use different components for issueing and verifying when we have integrated solutions available in the wallet provider group. Furthermore every issuer and verifier also needs to identify and authenticate itself. So we might as well use the holder capabliity of the EBW for that. I agree with @lalc that we can add some wording under the diagram to clarify that the EBW configuration is the WE BUILD reference pattern. If we all agree, I'll be happy to make a suggestion. |
|
What concerns me is the compliance of the QTSP that will issue the QEAAs. QTSPs are strictly regulated under eIDAS2, and the Registration Authority (RA) must comply with ETSI EN 319 401 (QTSP policies), ETSI TS 119 471 (QTSP QEAA policies), ETSI TS 119 461 (identity and attribute proofing) and ETSI TS 119 478 (authentic sources). The QTSP QEAASP RA must be audited by a CAB and then be certified by a supervisory body. This is a very demanding procedure, which several QTSPs are currently going through. Adding the EBW as an eIDAS2 compliant RA-component to the QEAA issuance process would require each EWB to undergo the same certification. Or would you recommend an architecture whereby the EBW could be designed to be out scope for the QTSP QEAA issuance process? Given the complexity of this topic, it would make sense to have a meeting about it. Would it be possible to arrange that in Amsterdam? |
|
Thanks, @Sebastian-Elfors-IDnow. This is an important point and worth addressing carefully. In my mind, the EBW is a product and architectural pattern (software, cryptographic components, and operational backend) that conforms to the ARF and the WE BUILD specifications, not a regulated entity in itself. The QTSP remains the regulated entity. The EBW is something a QTSP (or any other Issuer) deploys and operates within or alongside its certified perimeter. With that in mind, a QTSP can, of course, adopt an EBW for QEAA issuance and gain the same scaling, UX and integration benefits as any other Issuer. The architectural question is only about which functions fall within the QTSP's certified perimeter and which fall outside it. So, with that, I would lean towards the second option you suggest, that the EBW should be designed to be out of scope for the QTSP QEAA Registration Authority (RA) certification, rather than extending the RA scope to cover the EBW itself. The reasoning is that the regulated RA functions under ETSI EN 319 401, TS 119 471, TS 119 461, and TS 119 478 (policy compliance, identity and attribute proofing, authentic source consultation, LoA determination) should remain inside the QTSP's certified perimeter. The EBW then acts as the delivery and protocol endpoint, operated by or on behalf of the QTSP, handling OpenID4VCI issuance, key binding to the Holder wallet, the status mechanism, and audit logging for the QTSP. The interface between the QTSP RA and the EBW would be a defined API, with the QTSP retaining responsibility for the regulated functions. This mirrors the established pattern for QTSP remote signing services under the CSC API and ETSI TS 119 432, in which the signing service (Ref: CS for Remote Signing) operates on behalf of the QTSP without becoming the QTSP itself. It keeps the certification scope tractable, lets multiple QTSPs use compatible EBW deployments, and preserves the scaling property that makes the EBW pattern attractive in the first place. There are details worth working through, in particular, how the QTSP's TS 119 461 identity-proofing evidence is conveyed to and bound by the EBW at issuance, and how the QTSP's audit trail is maintained across the EBW boundary. These feel tractable, but they should be explicitly specified in the blueprint or a companion document. A dedicated session on this would definitely be valuable. I am not yet sure whether I have enough time in Amsterdam, but I am happy to contribute in some capacity. |
|
Hi @lalc, Thanks for the elaborated answer on the EBW role in a QTSP eco-system. If we can conclude that:
Then I think we are in agreement. |
In general I agree, however to add a flavour to this: the usage of the EBW is not mandatory, and so it would be fair to demo e.g the usage of a complete EBW solution interacting with a component. I know in practice not all companies / institutions will use a complete EBW solution, but some just components. E.g Banks will have out of their eidas2 scope already a verifier capability in place. They could interact with an EBW, without needing to hold an EBW themselves. This of course comes back to a trust and authentication question, as you have clearly outlined. |
We need to check this statement. If the attestation is issued by an EBW held by a QTSP, then it will be signed by the EBW, not by the certified system of the QTSP that might act behind it. So if the EBW, as an independent module, doesn’t have the same certification as the rest of the QTSP system where it might be integrated, I’m not sure that it could issue QEAAs. Also, how about the trust system? There’s no Trusted List or LoTL for wallets, then how can we ensure the validation path? If we have the EBWOID delivered by a QTSP, we can use the chaining mechanism to validate the other attestations issued by the related EBW, but if even the EBWOID is issued by an EBW (even held by a QTSP), it won’t be possible to use the current trust system architecture (as defined in the ARF). But basically, why did we decide to put the EBW everywhere? We can keep QTSP providers as issuers at the ecosystem level (EBWOID, VAT, …) and keep the EBW issuing at the company level (PoX, mandates, …). |
Interesting view, but I don't agree with this statement. When an EBW is held by a QTSP the signing will still be performed by the QTSP, so you still can issue QEAAs. You could even connect a QTSP remote signing solution to your EBW. The EBW will create the attestation and send the hash to be signed to the QTSP. |
|
The QEAAs will always be issued by the backend of the QEAASP (which is a QTSP). The QEAASP must be audited and certified against ETSI TS 119 471 and ETSI EN 319 401. The QEAASP frontend is the Registration Authority (RA), which must also be audited and certified against (different chapters of) ETSI TS 119 471 and ETSI EN 319 401. The RA must also be certified against ETSI TS 119 461 (identity and attribute proofing) and ETSI TS 119 478 (authentic sources). The EBW may serve the RA with certain technical functions, such as ERDS distribution of QEAAs, which is out scope of the QEAASP certification. The EBW will however not be part of the QEAASP backend, so the EBW will not be responsible for the issuance of QEAAs. |
|
I'd like to add another aspect, on the side of presentation. Let's take a practical example. A user wants to open an account at a bank. As part of the onboarding, the bank wants to get the PID from the user's EUDIW. Following the reference architecture proposed in this PR, the bank does not operate the verifier itself but instead uses an EBW from a vendor. The EBW serves as the counterparty for the user's PID presentation. IMHO, this makes the EBW an Intermediary under eIDAS Art. 5b (10): "Intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction." This has two effects:
Not sure this is something EBWs would be keen pursuing? |
Hi Stefan, Yes, I agree. That's in line with my comment from two days ago: "The ARF allows for a WRP intermediary, which should then use a WRPAC. If the EBW plays the role of a WRP intermediary, the EBW would need a WRPAC, which is a bit oakward since the EBW is a wallet in itself." |
|
If the QTSP is responsible of issuing so this is fine. But then, the statment "The Issuers will use the European Business Wallet to issue attestations" is misleading, especially that the EBW is able to issue its own signed certificates |
I think we have a different definition of what an EBW is. You are talking about EBWs like it's a legal entity. For me an EBW is a piece of software with Issuance and Verifier Capabilities that could be hosted by the relying party, or could be run under the domain of the relying party and uses the cryptographic material of a relying party. So, I don't see why an EBW should be treated as intermediairy. There is not much difference between implementing your own Issuance and Verifying Service or using a software product like an EBW from a technology/wallet provider. We are not stating this is the only way to implement it, but for the scope of WE BUILD, where we are piloting EBWs, it does make sense to take this as the general principle solution, so we can actually test and pilot EBWs. |
|
In my mind, we are arguing three different questions as one: architecture, attestation tier and deployment. Separating them resolves most of the disagreement. One thing worth stating up front: the EBW is an architectural construct, not a regulated entity, not a certification artefact, and not a deployment specification.. It defines a role and a set of capabilities, and each role (Issuer, Holder, Verifier) shapes its own flavour of that pattern. An Issuer EBW operating within a QTSP's certified perimeter looks different from a Verifier EBW handling presentation, which in turn looks different from a company-level Issuer EBW issuing attestations such as employment, role or mandate. In practice, these roles also overlap: an Issuer typically needs to verify prerequisite attestations before issuing (a bank verifies PID and supporting QEAAs before issuing a payment account attestation; an employer verifies PID and right-to-work before issuing an employment attestation), which is exactly where an integrated EBW supporting Issuer, Holder and Verifier capabilities pays off. Who runs each one, under what regulatory regime, and against which standards are separate questions, addressed by the layers below.
The result:
Proposed next steps:
|
|
@lalc Can you make a suggestion for the wording adjustments. Do I need to change the picture to reflect these adjustments? |
|
Very interesting discussion here and also in the tech talk that we just finished. Some questions many people seemed to share that should be clarified in the describing text surrounding the overview regarding it's purpose.
|
8 participants
Summary
images/ecosystem-overview.pngshowing the WE BUILD ecosystem at a glance (Issuer / Holder / Verifier roles, attestation providers on the issuer side, relying party backend systems on the verifier side, and the WE BUILD trust framework).blueprint/03-architecture-overview.md, between the actor list and the System Landscape section.Test plan
blueprint/03-architecture-overview.mdand confirm the image loads and the surrounding text reads correctly.