Propose EBWOID carrier independence - #286
Conversation
Names rb-ebwoid v1.0.0's existing SD-JWT VC/W3C VCDM encoding as a carrier, registers a new ebwoid+wrprc carrier for the Relying-Party direction (reusing ETSI TS 119 475 WRPRC/WRPAC) to cover PR #205's mutual-identification requirement, and flags the EBWOID/BWUA composition question between this rulebook and bwua-ts3-attestation.md for WP4 to resolve explicitly.
sander
left a comment
sander
left a comment
There was a problem hiding this comment.
I like the idea of reusing WRPAC/WRPRC formats for EBW acting as EAA Provider or EAA RP to another EBW.
A potentially simpler alternative approach would be to keep the EBWOID (EAA) and WRPAC/WRPRC (not EAA) distinct, and to modify #287 such that it is easy to obtain WRPAC/WRPRC over ACME with the same EUID/name as in EBWOID.
| Treat EBWOID as the claim set rb-ebwoid v1.0.0 §2 already defines, with one or more named, registered carriers, rather than as a single fixed credential type: | ||
|
|
||
| 1. Name the SD-JWT VC encoding rb-ebwoid v1.0.0 §3.2 already defines as carrier `ebwoid+sdjwtvc`, and the W3C VCDM encoding it already permits as `ebwoid+w3cvcdm`. Neither changes. | ||
| 2. Register a new carrier, `ebwoid+wrprc`, for the Relying-Party-side direction: the EBWOID `id` and `legal_name` carried or referenced within an ETSI TS 119 475 WRPRC/WRPAC, issued and revoked through that certificate's existing lifecycle rather than a new one. This gives PR #205's mutual-identification requirement a concrete mechanism without a new attestation type, and without depending on OID4VP's `verifier_info` parameter, which the base specification defines as optional and ignorable by the Wallet. |
There was a problem hiding this comment.
In this case, we may to register multiple carriers:
- WRPAC as X.509
- WRPRC as JWT
- WRPRC as CWT
There was a problem hiding this comment.
no I don't think so. Its basically the other way around. My proposal is that EBWOID is embeeded into existing trust carrier solutions.
There was a problem hiding this comment.
This will decrease decoupling and i'm not sure I see the benefits. If embedding the EBWOID in another credential we have added the dependencies from authentic source to EBWOID provider to also include WRPAC Issuer. I would prefer an architecure that decouples credentials, not couples them as is will lead to revocation chains.
EBWOID and WRPAC also have different purposes, one is to validate the EBW and authenticate the EBW owner, the the other is to attest to the EBW owner acting as RP. They also have different Issuers, why connect them?
Co-authored-by: Sander Dijkhuis <mail@sanderdijkhuis.nl>
|
First of all, ACME is about how you get an EBWOID while this proposal is about how you present an EBWOID. You're talking about the issuing side of EBWOID but this spec - and PR 205 is about the presentation side. Having said that, the problem with the ACME approach is that it assumes that there is a way to proove ownership of the name (ebcore in this case) independently of the cert itself. In the case of X509 (DC binding) this is reasonable since organizations control their domains and that can be used to issue a cert that attests to the control over the domain. In the case of EBWOID however there is no ubiquitiously available way to control access to the ebcore name. The existing pepol network (it has been pointed out to us) doesn't reach enough last mile to have the same standing as the DNS has for X509. In fact I think you could argue that EBWOID is a greenfield attempt to attest to ebcore ownership which means that it would be hard to apply an acme approach in practice. |
|
My suggestion was to issue WRPAC to the EBW upon EAA presentation of the EBWOID over ACME, so that the EBW can use the WRPAC whenever interacting with an EUDIW or EBW. This way, WRPAC and EBWOID remain functionally separate, but both provide the same assurance about the EUID of their holder. Instead, the current proposal seems to have the EBWOID issuer function as both an EAA Provider as well as an WRPAC Provider. While that would technically work, both roles are regulated quite differently, potentially making actual implementation harder. |
|
As a foreword I want to precise that the WRPC specification is written in a certificate issuance perspective. EBWOID is here an authoritative source for the TSP issuing RPAC. And if it is not the standard source for identification of the EBW owner, it would complexify the RPAC registration process with interactions between every RPAC and every Business registration authority. Then WRPAC issuance process would lose the benefit of wallet ecosystem. Additionally, in my opinion, using WRPAC as an EBWOID is a source of disruption: either it applies to any EBW owner, but in that case, it would mean that RP registrars should become EBW registrars, and that any EBW owner should request an WRPAC, which seems far beyond the regulation, or it applies only to RP that would mean RP's EBWOID would be different from non-RP EBWOID. |
|
|
||
| [rb-ebwoid v1.0.0](https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-ebwoid/README.md) defines EBWOID's claims (§2), its SD-JWT VC / W3C VCDM encoding (§3), its eIDAS Trust List trust model (§5), and its Token Status List revocation mechanism (§6). All of it is written for one direction of use: a Wallet User presenting their own EBWOID to an Issuer or Relying Party, e.g. during onboarding or wallet activation (rb-ebwoid v1.0.0 §4.1). | ||
|
|
||
| It does not address the direction [PR #205](https://github.com/webuild-consortium/wp4-architecture/pull/205) needs: an EBW acting as Relying Party presenting its own EBWOID to another EBW's Wallet User, as part of a mutual-identification handshake for non-interactive, backend-to-backend requests for non-public data. That PR proposes a new `verifierInfo`-carried attestation for this purpose. This introduces a second, undefined attestation-carrying mechanism for something the EU has already standardised: [ETSI TS 119 475](https://www.etsi.org/deliver/etsi_ts/119400_119499/119475/01.01.01_60/ts_119475v010101p.pdf) defines Wallet-Relying-Party Registration and Access Certificates (WRPRC/WRPAC) specifically for a Relying Party to prove its authorisations, entitlements, and intended purposes to a wallet. |
There was a problem hiding this comment.
@leifj :
I assume and I am convinced that Wallet-Relying-Party Registration and Access Certificates will be used by EBW owners only if they need to interact with EUDI Wallets for natural persons. When they interact with other EBW owners they interact in the new role defined in the EU Business Wallet Regulation "EBW Relying Party" and not "Relying Party". The Relying Party registration step to access attestations from another EBW owner (e.g. supplier adress data via EUCC) is an administrative burden for an EBW owner and the national registrars will not be able to judge if the legal entity should be allowed to request specific data or not. Therefore, there is no benefit of an Access Certificate for an EBW owner and his EBW Relying Party business partners.
My conclusion is that the already standardised [ETSI TS 119 475] does not helps EBW owners in interactions with other EBW owners. and therefore "verifierInfo' is not a second carrier mechanism. I agree that a verifier Info based solution has other disadvantages.
| It does not address the direction [PR #205](https://github.com/webuild-consortium/wp4-architecture/pull/205) needs: an EBW acting as Relying Party presenting its own EBWOID to another EBW's Wallet User, as part of a mutual-identification handshake for non-interactive, backend-to-backend requests for non-public data. That PR proposes a new `verifierInfo`-carried attestation for this purpose. This introduces a second, undefined attestation-carrying mechanism for something the EU has already standardised: [ETSI TS 119 475](https://www.etsi.org/deliver/etsi_ts/119400_119499/119475/01.01.01_60/ts_119475v010101p.pdf) defines Wallet-Relying-Party Registration and Access Certificates (WRPRC/WRPAC) specifically for a Relying Party to prove its authorisations, entitlements, and intended purposes to a wallet. | ||
|
|
||
| Separately, [bwua-ts3-attestation.md](bwua-ts3-attestation.md) records that Business Wallet Unit Attestation (BWUA)'s organisational identity dimension has "EBWOID carried as a claim." Read next to rb-ebwoid v1.0.0 §4.1, which documents EBWOID as presented atomically and standalone, and referenced by `id` from other attestations rather than duplicated into them, it is unclear whether EBWOID's claims are meant to be embedded inside BWUA or only referenced by it. If both readings are implemented, `legal_name` (which can change) risks holding two independent, potentially diverging copies. | ||
|
|
||
| ## Decision | ||
|
|
||
| Treat EBWOID as the claim set rb-ebwoid v1.0.0 §2 already defines, with one or more named, registered carriers, rather than as a single fixed credential type: | ||
|
|
||
| 1. Name the SD-JWT VC encoding rb-ebwoid v1.0.0 §3.2 already defines as carrier `ebwoid+sdjwtvc`, and the W3C VCDM encoding it already permits as `ebwoid+w3cvcdm`. Neither changes. | ||
| 2. Register a new carrier, `ebwoid+wrprc`, for the Relying-Party-side direction: the EBWOID `id` and `legal_name` carried or referenced within an ETSI TS 119 475 WRPRC/WRPAC, issued and revoked through that certificate's existing lifecycle rather than a new one. This gives PR #205's mutual-identification requirement a concrete mechanism without a new attestation type, and without depending on OID4VP's `verifier_info` parameter, which the base specification defines as optional and ignorable by the Wallet. | ||
| 3. Ask WP4 to explicitly resolve the composition question raised above: either EBWOID remains standalone and BWUA references it by `id` only, or BWUA embeds EBWOID's current claims and rb-ebwoid v1.0.0 §4.1 is amended to document BWUA as a valid carrier. This ADR does not choose between them — only that one should be chosen and stated, rather than left to differ by which document an implementer reads. | ||
| 4. Reserve, but do not require, a carrier identifier `ebwoid+federation` for a possible future OpenID Federation-based carrier, should EBW trust infrastructure adopt Federation separately. No such infrastructure exists today, and this ADR does not propose building it. | ||
|
|
||
| ## Consequences | ||
|
|
||
| What becomes easier? | ||
|
|
||
| 1. PR #205's mutual-identification requirement gets a concrete mechanism, reusing an ETSI standard already designed for a Relying Party proving itself to a wallet, instead of an underspecified new attestation object. | ||
| 2. rb-ebwoid v1.0.0's claims, encoding, trust model, and revocation mechanism require no changes to support this. | ||
| 3. Additional carriers can be registered later, if the ecosystem's trust infrastructure changes, without revisiting this decision or rb-ebwoid v1.0.0. | ||
|
|
||
| What becomes more difficult? | ||
|
|
||
| 1. Implementers need to know which carrier(s) a given interaction expects, rather than assuming EBWOID always arrives as an SD-JWT VC. | ||
| 2. WP4 must explicitly resolve the EBWOID/BWUA composition question rather than leaving it to differ between rb-ebwoid v1.0.0 and bwua-ts3-attestation.md. | ||
| 3. EBW owners may not be able to hide whether they internally use an EBW or another WRP component. |
There was a problem hiding this comment.
@leifj :
An EBW owners confidentiality protecting requirement is "A Holder EBW can verify that a presentation request was generated by a secure EBW rather than a generic, potentially less-secure EUDI Relying Party Component."
I don't think that the solution considers this requirement.
I do not understand "3. EBW owners may not be able to hide whether they internally use an EBW or another WRP component."
From a holder's security perspective, the real issue is the exact opposite:
Under a traditional X.509 certificate model, an insecure, generic Relying Party component can easily hide its true nature. Because traditional certificates lack the active, hardware-enclave-backed runtime attestation provided by a BWUA, a holder’s EBW cannot cryptographically distinguish a request coming from a certified, secure Business Wallet unit from a request coming from a vulnerable, generic server using a copied certificate.
6 participants
Summary
rb-ebwoid v1.0.0 defines EBWOID's claims, encoding, trust model, and revocation only for the Wallet-User-presents-to-Issuer direction. This ADR proposes treating EBWOID as a claim set with named, registered carriers rather than a single fixed credential type, so that:
ebwoid+sdjwtvc/ebwoid+w3cvcdm) — no change to rb-ebwoid v1.0.0.ebwoid+wrprc, covers the Relying-Party-side direction Mutual Identification and Consent Hand-Shake ... #205 needs, by reusing ETSI TS 119 475's existing WRPRC/WRPAC certificates instead of a new attestation type.Related