stateDiagram-v2
[*] --> Intake: PR opened by any consortium member
Intake --> Review: Ready for review
Intake --> Rejected: Not ready / out of scope
Review --> Decision: Max. 12 days
Decision --> Approved: No blocking issues
Decision --> Iteration: Blocking issues
Decision --> Rejected: Insufficient support
Iteration --> Approved: Issues resolved
Iteration --> Rejected: Issues remain
Approved --> [*]
Rejected --> [*]
1 Architecture decision records
WE BUILD maintains a lightweight architecture decision record (ADR) for each software-related decision affecting interoperability.
Propose new ADRs using the template. Announce them to the Architecture group in the Portal to get feedback to understand the consortium’s opinion.
1.1 ADR overview
- Publish consortium trusted lists
- Baseline protocols
- Specify PID and eAA formats
- Provide EBWOID as a stable minimal basis
- Wallet Unit Attestation and Lifecycle Management (For EBW)
- Replace LPID with EBWOID
- Deliver business wallet data using QERDS
- Attestation Revocation Mechanism
- Separate QERDS registry from relay
- Structure the European Digital Directory as identification, discovery, and connection
- Separate attestations, documents, and data in EBW
- Acceptance of Self-Issued Attributes
- Atomic Granularity for Mandate-Related Attestations
- EAA Extension for the EDD
- EBW EAA Exchange Automation
- Role-Based vs Service-Based Authorization
- Support for Sole Trader Representation
- QEAA Attestations and QERDS Documents
- Credential Offer Endpoint Registry and Lookup Service
- Business Wallet Unit Attestation based on TS3
- Pre-flight CS
- Pseudonyms for User Accounts
- Architectural Scoping of the EBW
- Mutual identification for EBW presentation requests
- Verify QERDS Provider trust via Trusted Lists before and after delivery
- Verify EAA issuer key binding via an AuthZEN API call
1.2 Supporting analysis
1.3 ADR process for WE BUILD
ADRs are handled through a timeboxed process to avoid proposals remaining open indefinitely.
1.3.1 1. Intake – next Architecture Group (AG) meeting (max. 14 days)
- checks that the ADR is ready for review;
- identifies required stakeholders/reviewers; and
- identifies whether additional approval is required for high-risk decisions.
1.3.2 2. Review – max. 12 days
Required stakeholders are requested as reviewers in GitHub.
Feedback should identify any blocking issues. No response by the deadline is treated as no blocking objection.
1.3.3 3. Decision – next AG meeting
The AG decides to:
- Approve – no unresolved blocking issues → merge.
- Iterate – blocking issues remain → one iteration allowed.
- Reject – insufficient support, maturity or relevance → close.
Additional stakeholder engagement may exceptionally be requested if a required stakeholder has not had a reasonable opportunity to respond.
After one iteration, the ADR is approved or rejected.