Cs 06 conformance spec rpac rprc v0.3 - #196
Conversation
jillesvo
changed the title
|
Thank you very much for this impressive proposal, @jillesvo! I realised that the CS template does not have a Author field in the beginning, I will add that to the template. In the approved ones 01, 02, 03 there is a list of Authors / Contributors in the beginning. Could you please add the other involved authors in the top of the CS? I suggest @webuild-consortium/blueprint-coordination-group reviews this. |
|
This PR proposes the ACME protocol + authentication-via-POA-presentation for the automation of WRPAC/WRPRC generation. The ACME protocol seems a good fit for the problem and the extensions are reasonable (e.g., a new challenge "prove you are the RP by putting this token in the RP list"). Some questions:
Also, I think CLAUDE.md can be left out; people may have already their own uncommitted similar file. |
|
We already have EBWOID, we can use that instead of the POA credential to authenticate. |
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>
Thanks @gfour for the questions and input 1. Who implements the ACME client / must the EBW become one? It's left as an implementation choice on purpose, and the client sits on the WRP side (not in the ITB+). §4 maps the ACME Client to "User + EBW" and is explicit that the EBW plays two separable roles:
Two valid topologies:
On "is the ACME client an RP that EBWs present to?" - no. The EBW presents to the RA (the ACME Server's RA function / TSP portal) in the pre-ACME phase; the RA then issues EAB credentials (Key ID + HMAC key), and the ACME client merely carries those into the protocol. The chain is EBW → presents to RA → RA issues EAB → ACME client consumes EAB; the ACME client is never a relying party in the EUDI sense. 2. The X-Y relationship (POA for X, registering wrp-id=Y) You're right that this is the WRP unique identifier / WRP legal name linkage, and we're going to make it explicit and direct by authenticating with the EBWOID attestation (rb-ebwoid) rather than a POA. EBWOID carries the organisation's id and the official name. So the binding becomes a straightforward, testable equality the RA enforces:
We'll update the proposal accordingly. |
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>
jillesvo
changed the title
|
Better to continue in #287; see rationale at the top. |
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
| 6. Include a certificate policy OID (Annex IV). | ||
| 7. Include certification path information (URI). | ||
| 8. Include a SAN extension (DNS name or URI). | ||
| 9. Include registration information per Annex I points 1, 2, and 8. |
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"
| 2. Include an `instanceId` in orders for multi-instance deployments. | ||
| 3. Clean up `acme-challenge` entries from the RP List after successful issuance or upon authorization failure. | ||
|
|
||
| ## 7.4 Certificate Profile |
There was a problem hiding this comment.
Reference to "national wallet-relying party register in which the relying party is registered" is missing according to new CIR 2026/1730, Annex II 2(b) adding to Annex IV 3k (b) in CIR 2025/848
| 5. Contain at least one unique WRP identifier (Annex I point 3), selected from EUID, LEI, EORI, national business 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 (DNS name or URI). |
There was a problem hiding this comment.
not required according to Annex IV i CIR 2025/848
|
|
||
| **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: | ||
|
|
||
| * The ACME Server MUST verify that the `instanceId` is distinct from all other currently valid WRPACs issued to the same `wrp-id`. |
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?
| 2. **[MVP+]** The RA initiates an OID4VP request to the EBW, requesting the organisation's EBWOID (EAA). **[MVP]** This step MAY be performed out-of-band. | ||
| 3. The EBW presents the EBWOID. | ||
| 4. The RA validates the EBWOID and verifies the organisation's identity. | ||
| 5. Optionally (Blueprint step 4): the RA requests additional attributes for WRPRC production. |
There was a problem hiding this comment.
Not optional anymore - see ARF 3.0.0 Reg_10c.
|
|
||
| 1. The ACME Client generates a certificate key pair and CSR. Per §7.3 item 4, the ACME Client MUST generate a distinct key pair for each Relying Party Instance. | ||
| 2. The ACME Client sends the CSR to the `finalize` URL. | ||
| 3. The ACME Server (RA) validates; the ACME Server (CA) generates WRPAC (and optionally WRPRC). |
There was a problem hiding this comment.
Not optional anymore - see ARF 3.0.0 Reg_10c.
| 2. The ACME Client sends the CSR to the `finalize` URL. | ||
| 3. The ACME Server (RA) validates; the ACME Server (CA) generates WRPAC (and optionally WRPRC). | ||
| 4. The CA submits to CT logs and obtains SCTs. | ||
| 5. The order transitions to `valid` with a `certificate` URL (and optionally `registrationCertificate` URL). |
There was a problem hiding this comment.
Not optional anymore - see ARF 3.0.0 Reg_10c.
| 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?
6 participants
WE BUILD Conformance Specification: Issuance of Relying Party Access and Registration Certificates (v0.2)
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)