ADR: Architectural scoping of the European Business Wallet - #200
ADR: Architectural scoping of the European Business Wallet#200MiikaAntila wants to merge 3 commits into
Conversation
New proposed ADR
| Within the WE BUILD consortium architectural scope, the EBW is not assumed to: | ||
| - Act as a system of record for operational business data | ||
| - Orchestrate or execute business processes | ||
| - Serve as a continuous ERP‑to‑ERP or CRM‑to‑CRM transaction or integration channel |
There was a problem hiding this comment.
In general I agree with the ADR. The business wallet should support on identity and trust. But what do you exactly mean by this last sentence? It would help if you can give examples of what is within scope and what is not.
There was a problem hiding this comment.
Needs to be reformulated with the scope of QERDS in mind. In light of the services/tools above, QERDS is there when/if you need legal effect on the proof of delivery of a transaction.
There was a problem hiding this comment.
Thanks, good question! I agree that this sentence needs clearer examples. By “EBW does not serve as a continuous ERP‑to‑ERP or CRM‑to‑CRM transaction or integration channel”, I mean that the Business Wallet is not intended for general-purpose business data exchange or system integration, but rather for identity, trust, and verifiable business evidence exchange only.
Out of scope examples
- Continuous data synchronization between systems (e.g. order, invoice, or master data replication)
- ERP-to-ERP or CRM-to-CRM integration flows
- High-volume transactional messaging unrelated to identity or trust
- Acting as a middleware layer or integration bus
These would be better handled by integration platforms and existing system-to-system interfaces.
|
|
||
| ## Decision | ||
|
|
||
| Within the scope of the WE BUILD consortium architecture, the European Business Wallet is assumed to function primarily as an **identity, trust, and authorisation component,** and not as an operational business system or as an ERP‑level data exchange platform. This may include limited issuer capabilities for mandates, delegations, or other trust-related attestations within an organisation’s own trust domain, where such issuance is anchored in the broader trust infrastructure. Within this architecture, the EBW serves as an entry and anchoring point into a broader trust infrastructure, rather than constituting the trust layer itself. |
There was a problem hiding this comment.
Instead of one component (that it functions as) I would describe the BW as a set of standardised (but potentially distinct) identity and trust services (or tools) exposed to the EOs enterprise systems enabling them to access and use the broader trust infrastructure (or trust ecosystem). Article 5 in the regulation proposal describes the core tools/services that needs to be provided to be able to call the collection "a wallet".
There was a problem hiding this comment.
Good point, updated the wording to describe the EBW as a set of standardised identity, trust, and authorisation services exposed to enterprise systems, rather than a single component.
|
@MiikaAntila @kjorlaug @eklaver - is this still consistent after the Amsterdam WS ADRs, no collisions there? Ready to merge? |
4 participants
This PR proposes a new ADR defining the scope of the European Business Wallet (EBW) within the WE BUILD architecture.
The ADR clarifies:
This aims to reduce ambiguity across use cases and improve consistency in integration design.
Feedback and comments from the consortium are welcome.