Add draft guidance: Wallet Provider onboarding in WE BUILD - #9
Conversation
Separates the three registrations a wallet provider faces — the Wallet Capability Viewer, the WE BUILD Trusted List of Wallet Providers, and the ITB Conformance Overview — and gives the full procedure for Trusted List onboarding. Ten open items are addressed to the WP4 Trust Infrastructure group and the WP4 Testing group.
thodoris
added
documentation
Answers received from the WP4 Trust Infrastructure group on 4 September 2026 are applied. OI-05 (approver and support channel) and OI-07 (trust anchor validity) are closed. OI-01, OI-03 and OI-04 are narrowed to their remaining question, OI-02 is re-addressed to the console operator, and OI-06 is kept open with the reason recorded. Interim CSR guidance added to Step 2, and the confirmed console entry point and the stale UC-03 reference to Step 3. OI-11 added on the issuing certificate profile. Root README status line updated to match the register.
endimion
left a comment
endimion
left a comment
There was a problem hiding this comment.
Hey Thodoris,
sent an email as well... :)
Thanks for putting this together. I reviewed the ITB-related parts of the draft.
A few clarifications on OI-08–OI-10:
OI-08 — Trust Framework Integration test cases and prerequisites
The “WE BUILD CTS – Trust Framework Integration” suite is already available within the ITB under:
Conformance statements → Base Protocols → WE BUILD CTS Trust Framework Integration
The current suite is:
WE BUILD CTS – Trust Framework Integration
Conformance Test Suite v1.1 — August 2026
Coverage: WBCS 001 / 002 / 004, including the optional WUA-related checks.
Conceptually, the Trust Framework Integration suite builds on the same issuance and presentation scenarios exercised by:
WE BUILD CTS – CS-01 Issuance, CTS v1.0 — WBCS 001
WE BUILD CTS – CS-02 Presentation, CTS v1.0 — WBCS 002
but adds the corresponding trust-framework validation checks, based on the trust framework and infrastructure defined by the WP4 Trust Infrastructure group.
You are also correct that the current Base Protocols README needs to be updated. It reflects the previous organisation of the test cases and does not yet document the suite structure introduced in the recent ITB updates.
OI-09 — Dependency on the Trusted List
Your working assumption is correct.
The normal Base Protocols / CS-01 / CS-02 conformance tests do not require prior onboarding to the WE BUILD Trusted List of Wallet Providers. Their purpose is to establish protocol-level interoperability for issuance and presentation.
The Trust Framework Integration suite takes those flows one step further and verifies the applicable trust-framework checks. Where a test requires the ITB/reference implementation to establish trust through the WE BUILD trust infrastructure, the relevant entity must therefore have been onboarded to the appropriate WE BUILD Trusted List.
So the useful distinction for providers is:
Base Protocol conformance → no Trusted List onboarding prerequisite.
Trust Framework Integration conformance → relevant Trusted List onboarding is a prerequisite for the trust-dependent checks.
OI-10 — Conformance Overview and evidence
At present the public Conformance Overview records Base Protocols conformance only.
There is no separate evidence artefact required specifically for the trust framework: the ITB-generated conformance statement report is the evidence, just as it is for Base Protocols.
We should extend the Conformance Overview with a Trust Framework Integration section/table so that this result is visible independently from Base Protocols conformance.
Answers from the Trust Infrastructure group and the Testing group are folded into the text and the register now lists only what is still needed, phrased as the outstanding action rather than as the question that was asked. OI-05, OI-09 and OI-11 are answered and no longer listed; a line under the register says where their content went. Step 5 gains the trust model: resolution runs top down from the LoTL to the wallet-solution certificate, which is used directly as a trust anchor and does not chain to the list-signing certificate. That certificate is correctly profiled CA:FALSE with keyUsage digitalSignature per ETSI TS 119 612, so a path-validation tool reporting errors 79 and 32 is the wrong instrument rather than evidence of a defect. WRPAC and WRPRC certificates do chain in the ordinary way, which is the trap worth naming. B.1 identifies the Trust Framework Integration suite, B.3 states that the ITB conformance statement report is also the evidence for it, and B.4 replaces the working assumption with the dependency rule. Step 6 says what is wrong with the pointer certificates. The change log is dropped; git history carries it. Root README status line updated to match the register.
The banner said confirmation on this pull request had been requested. For the ITB items it has been given: the Testing group's answers on OI-08 to OI-10 are a review on this pull request, not private correspondence. The Trust Infrastructure group's answers are still e-mail only, so the banner now states the gap plainly instead of asking for something already supplied.
|
Thanks Nikos — all three are in, at
Diff: 56d1302...5c084d9 Re-review when you can, and correct anything I have overstated. |
The console operator answered OI-02, OI-03, OI-06 and OI-07 and published a Direct Onboarding page documenting the flow, added as reference 23. Closed: OI-02, no verifiable-credential wallet is required and a console account is all you need, business-wallet login being roadmap rather than implemented; OI-03, lists are browsable without an account while submitting a request needs one and verifiers need none; OI-06, no service level is offered but requests are usually answered within a day. Step 2 cites the operator's openssl commands for the mechanics of producing an acceptable CSR while stating plainly that they are not the WE BUILD profile: that page is operator documentation scoped to a test environment and its example subject is generic rather than the UC-03 legal-entity data. OI-01 stays open on #131 for the profile itself. Step 4 lists the fields the form actually collects. OI-04 is recast from "is this published" to which data set governs, since the form and UC-03 do not agree in either direction. OI-05 is reopened: the operator states that IDunion approves by default, which does not obviously match the Trust Infrastructure Responsible Group and the WP4 lead and co-lead deciding as Ecosystem Authority. Step 5 records what approval produces, and Step 6 that the pointer certificate reissue is in hand.
The guide explained itself to the reader: which source it trusted and why, that another document's line was stale, what it deliberately would not say, and how confident it was. None of that helps someone onboarding a wallet. Removed throughout. The CSR block now says generate a P-256 key and CSR with your legal-entity data in the subject; the Step 3 note about UC-03 naming Open Social is gone; the form-fields note says what is missing and to have the rest ready; the turnaround paragraph drops the aside about "without undue delay"; "The trap" loses its label. The reference-source caveat and the record of which items were answered in earlier revisions are gone with them. Every open item still carries its marker and its register row.
OI-01 asked for a P-256 example and openssl commands that the console operator has since published, and said publication waited on three open points that were answered on #131. It now asks only for the WE BUILD CSR profile in Task 3. Reference [7] is the operator's older user guide, which still tells readers to log in with an EU Business Wallet — the text Step 4 now contradicts. The onboarding flow cites the current page [23] instead; [7] survives only for key management, which [23] itself defers to. Step 5 names the Ecosystem Authority and IDunion's role in one paragraph rather than a statement followed by a blockquote that read as a rebuttal. OI-05 still carries the question of who decides.
6 participants
A wallet provider in WE BUILD faces three separate registrations, run by three different groups, and
they are routinely confused with one another:
Infrastructure group
This draft separates them and gives the full procedure for the one that establishes trust. It defines
nothing: every factual statement links to the owning group's document, and what the published
material does not answer is listed in Annex A, addressed to the group that owns each item.
Now at v0.8. Answers from the WP4 Testing group, the WP4 Trust Infrastructure group and the
console operator have been incorporated.
Answered, and no longer listed as open:
involved, and business-wallet login is roadmap rather than implemented. Trusted Lists are browsable
without an account, submitting a request needs one, and a verifier needs none because it resolves
the lists through the LoTL. The operator has published a
Direct Onboarding page
documenting the flow, now reference 23.
several days when the operator's team is away.
the trust-dependent checks. Stated as the rule in B.4.
down from the LoTL and stops there; nothing chains back to the list-signing certificate, which is
correctly profiled
CA:FALSEwithkeyUsagelimited todigitalSignatureper ETSI TS 119 612.Step 5 also names the trap: WIA and KA do not chain, while WRPAC and WRPRC do.
Still open — six items:
wp4-trust-group #131. Step 2
now cites the operator's
opensslcommands for the mechanics of producing an acceptable CSR, butexplicitly not as the profile: that page is operator documentation scoped to a test environment,
and its example subject is generic rather than the UC-03 legal-entity data.
direction: no QTSP or single-person-company flag, no natural-versus-legal-person field, no
status-list URI, no associated body; plus e-mail, phone and website that UC-03 does not list. Which
data set governs is the question.
otherwise on request, which does not obviously match the Trust Infrastructure Responsible Group
reviewing and the WP4 lead and co-lead deciding as Ecosystem Authority.
hand.
Corrections and contributions from either group are welcome as pull requests. If either group would
rather own this document, we will move it to their repository.
No CI applies to this change:
validate-pr.ymlis path-filtered to the capabilities CSV, anddeploy.ymltowallet-capabilities/**, so merging will not republish the viewer.