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
4 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)