Conformance specification for Wallet-Relying Party access and registration certificates - #287
Conformance specification for Wallet-Relying Party access and registration certificates#287sander wants to merge 14 commits into
Conversation
CLAUDE.md is a per-developer local file; contributors may keep their own uncommitted version, so it should not be tracked in the repo. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Authenticate via the organisation's EBWOID attestation (rb-ebwoid) instead of a Power of Attorney. EBWOID.id is the same EUID-style identifier format as wrp-id, so the WRP binding becomes a direct, testable match: the ACME Server MUST verify EBWOID.id == wrp-id and EBWOID.name == the RP List WRP legal name (new normative MUST in 7.2 item 9, with matching conformance bullet in 9). Authorisation now derives from control of the organisation's EBW; no separate POA or representative binding. Bumps version to 0.3 and adds author. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Implements the new normative check (CS-06 7.2 item 9): the EBWOID bound to
the ACME account must correspond to the WRP being ordered.
- client: EAB now carries a simulated EBWOID {id, name} claim in its
protected header (the identity the RA would verify out-of-band).
- facade: newAccount extracts and stores the EBWOID; registrar-api-01
challenge validation rejects (403) unless EBWOID.id == wrp-id and
EBWOID.name == the RP List entry's legal name.
- negative_tests: fresh_account carries a (default-matching) EBWOID and a
new t_challenge_ebwoid_mismatch asserts a 403 when EBWOID.id differs from
the ordered wrp-id.
- README: documents the EBWOID claim and the 7.2 item 9 enforcement; notes
the EBWOID is trusted as-presented (HMAC still not verified) in this MVP.
Not run end-to-end here (requires the live Dogtag CA + FastAPI services);
py_compile passes and the seeded test identity matches the new check.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Better move to the wp4-qtsp-group repository.
This version aims to stay as little as possible specific to WE BUILD but keep the simplicity brought by utilisation of ACME protocol carrying WRP data. Particularly it : - Limits adaptation of ACME Protocol, both for server and client; - Separates clearly registration of RP from certificate issuance process; - Give up RP's writing in the Trust List; - Specifies certificate profile; - Precises instanceID positionment in certificate profile; - Deletes automatic revocation in case of new issuance of an RPAC; - Precises RA's actions and revocation timeframe in case of suppression of RP's entry in the Trust List; - Repositions RPRC optional issuance sooner, just after registration; - Deletes simultaneity between RPRC issuance and RPAC issuance Original commits: jillesvo#1 Original pull request: FCHASSERY#1 Amendment by Sander: change into a single change to the original file. Co-authored-by: Sander Dijkhuis <sander.dijkhuis@cleverbase.com>
sander
changed the title
|
It would be interesting to hear if members from the trust group, such as @lj-raidiam, also has input to these WBCS. Added him as reviewer. |
miluDIGG
left a comment
miluDIGG
left a comment
There was a problem hiding this comment.
Some updates in light of the new CIR 2026/1730 amending CIR 2026/848 that I left in PR 196 before I saw that this one was the new one :) My comments are still relevant since the two PRs are so similar.
I want to also add that all comments referring to the WRPRC being optional should be revised - that changed in ARF 3.0.0 Reg_10c.
| } | ||
| ``` | ||
|
|
||
| **Multi-instance issuance**: A single WRP identified by one `wrp-id` value MAY obtain multiple WRPACs, one per Relying Party Instance, in accordance with the Relying Party Instance model described in the EUDI Wallet ARF v2.8 [15]. Each order MAY include an optional `instanceId` string that uniquely identifies the specific Relying Party Instance within the WRP's deployment. When `instanceId` is provided: |
There was a problem hiding this comment.
This specification models multi-certificate issuance per instance. Under ARF 3.0.0 Reg_10a, a registering entity SHALL receive at least one access certificate for each registered Service; as Reg_10a note b) and RPA_06 note a) make explicit, a single Relying Party Instance may hold several of these, one per Service. Maybe add serviceID and serviceTradeName and require uniqueness on serviceID within wrp-id per reg_33?
There was a problem hiding this comment.
If a RP is offering different services he'd rather carry this information in the Common Name which is the friendly name for users trusting his service, and keep the advantage of OU field to carry the information about instances.
| 10. Express attribute content (e.g. `organizationIdentifier`, semantic identifiers) using the Subject DN and certificate-extension attributes defined in ETSI EN 319 412-1 [18] and ETSI TS 119 475 v1.2.1 clause 5 [4]. | ||
| 11. Conform to ETSI TS 119 475 v1.2.1 [4]. | ||
| 12. Use RSA (min. 3072 bits), ECDSA (P-256 or P-384), SHA-256 or stronger. | ||
| 13. Have a validity period of **one year** from the date of issuance. Shorter validity periods are NOT used in WE BUILD interoperability testing. |
There was a problem hiding this comment.
Maybe it should be also be specified how the wallet Unit checks WRPAC revocation status if the certificate is valid for so long. Is that specified somewhere else or does it belong here?
There was a problem hiding this comment.
Revocation status information is a standard practice for CA and the collection of this information by wallet units is not to be treated in this CS.
| 5. Contain one unique WRP identifier (Annex I point 3), listed in the CP among EUID, LEI, National Trade Register number, or VAT identification number. | ||
| 6. Include a certificate policy OID (Annex IV). | ||
| 7. Include certification path information (URI). | ||
| 8. Include a SAN extension containing contact information of RP as described in ETSI TS 119411-8 (6.6.1-07) |
There was a problem hiding this comment.
This is not the right references I believe. I think it should be Annex I, points 1,2,3,5,6,7 and 16 (as per the new CIR 2026/1730). 7 is at least one of website/phone/email, and 16 is "where applicable".
point 8 is not required.
There was a problem hiding this comment.
ETSI TS 119411-8 §6.6.1-07 specifies contact information that shall be included in WRPAC certificate, and using a SAN to carry this information seems appropriated.
|
Dear all, François, thank you for the good work. After reviewing the document I have the impression that both the EBW and an integrated ACME client are prerequisite for Access & Registration Certificates issuance. I fear this will be an issue for relying parties which are not using an EBW (as the EBW should mainly be used by Wallet holders, not by relying parties - which has been further clarified in the latest version of the draft regulation, as the requirement for public sector bodies acting as relying parties to have an EBW has been deleted). Furthermore I am also concerned it will be an issue for any relying party verifier service which has not implemented an ACME client. I would suggest that we propose :
|
…icates.md This version adds an alternative to full automated issuance process in order to serve RP that does not use EBW or does not wish to integrate an ACME client in their IT systems.
|
|
Dear Romain, |
…icates.md redactional corrections
…icates.md redactionals
…icates.md redactionals
7 participants
Note
This PR replaces #196 which originated from a personal fork by @jillesvo, which @FCHASSERY could subsequently not take over due to GitHub limitations. I have removed the prototype code (which we should use in wp4-qtsp-group) and included the latest proposed changes by @FCHASSERY. While I could not assign @FCHASSERY to this PR, consider him to be the owner/assignee. @sander
WE BUILD Conformance Specification: Issuance of Relying Party Access and Registration Certificates
Summary
This PR proposes the first version of the WE BUILD Consortium Conformance Specification (CS) for the automated issuance of Wallet-Relying Party Access Certificates (WRPACs) and optional co-issuance of Wallet-Relying Party Registration Certificates (WRPRCs), based on the ACME protocol (RFC 8555).
What this spec defines
wrp-id) for WRP identifiersregistrar-api-01) for verifying WRP authorization against WE BUILD RP ListsNormative alignment
Scope and limitations
This specification is intended for interoperability testing in the WE BUILD ITB+ environment only, not for production deployment. EBW authentication may be simulated in MVP scope; full OID4VP-based authentication is required for MVP+ conformance.
Requested feedback
registrar-api-01challenge design (§5.3, §7.8)