Mutual Identification and Consent Hand-Shake ...

[flo0x]

Mutual Identification and Consent Hand-Shake
Draft 0.1

[wfolkendt]

An EBW Owner in the Holder role stores highly confidential data in his EBW (e.g. UBO, Control Structure,...) that need to treated confidential and securely. Therefore a EBW Relying Party request for confidential data will be answered by the holder EBW only after the requesters identity and authorization and also the requesting software authenticity and validity (e.g. based on the EBW Wallet Instance Attestation abbreviated as BWIA, if the request is made by an EBW) was validated by the Holders EBW.

[benhansson]

Wouldn't the validity check be on BWUA, not WUA?

[wfolkendt]

I have replaced WUA with BWIA

[benhansson]

Same comment about BWUA over WUA.

[wfolkendt]

The wallet instance attestations therefore increases trust in the integrity of the requesting software and significantly reduces the risk of impersonation of the requesting Relying Party. The wallet instance attestation revocation status also shows that the wallet is not revoked (e.g. due to compromise, ...)

[wfolkendt]

From an holder security, confidentiality and legal perspective the requesters identification should be based on the EBWOID and the requesting software authenticity and components validity should be based on the BWIA. Currently an EBWOID and a BWIA are issued only to EBWs. Therefore a request made by a software component that is not part of the EBW like for example an "EUDI Wallet Relying Party Component" or an “EBW Relying Party Component" requesting confidential attestations will be ignored by EBW owners due to confidentiality, security and legal concerns. A Relying Party software component is less secure than an EBW.

[benhansson]

But just like WUA, the BWUA will be made up of BWIA and SKA.

[wfolkendt]

I have replaced the term WUA with BWIA.

[wfolkendt]

Wallet providers may be interested to offer verification services based o a software component that has no Holder functionality and does not contain attestations like the EBWOID and the BWIA. Therefore they may be interested that identification of the verification component can be done also based on x.509 certificates comparable to the Access Certificate. However such a certificate is not a wallet bound issued certificate and therefore less secure from holder perspective and does not has the same legal value as the EBWOID. It also requires a EBW Relying Party registration that creates additional administrative burden for EBW holders.

[wfolkendt]

We need a new verifierInfo type that includes at least the EBWOID and the BWIA. This verifierInfo object SHOULD be used to request attestations that contain non-public data that are treated as confidential data by the holder. The Relying Party needs to be aware that requests for non-public data will not be answered by the holder without verifying the EBWOID of the relying party and comparing the EUID included in the EBWOID with the legal entity internal whitelist for accepted requesters.

[wfolkendt]

delete

[wfolkendt]

delete

[wfolkendt]

The rulebook for mutual identification and consent handshake referencing also the rulebook for basic attestation verification describes the proposed solution: [https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/holder-authorization-handshake.md]

[wfolkendt]

1. A new verifierInfo type will be defined [Where?]. The new verifierInfo type MUST contain an EBWOID and a BWIA attestations. The verifierInfo parameter in an authorization request MUST be provided by the relying party for each request for non-public data.

[wfolkendt]

An attestation request for non-public attestations from a Relying Party software MAY be answered or denied by the EBW owner based on his internal policies and a relying party unique identifier included in the EBWOID.

[wfolkendt]

delete

[wfolkendt]

1. EBW owner will accept to present requested attestations with non-public data if the request is received from an EBW wallet with the new verfierInfo object. Requesting Relying Parties can avoid unexpected denied requests made via a Relying Party software.

[wfolkendt]

1. Legal entities that use a Relying Party component will not be able to create the new verifierInfo object because they do not have the EBWOID, the BWIA and also no wallet bound attestations. As a consequence several Holder EBW will deny requests for confidential data made through the Relying Party software due to confidentiality, security and legal concerns (e.g. impersonation risk). The same EBW owner probably will answer a request made through an EBW by the same legal entity.

[wfolkendt]

2. Without a common understanding between use case participants in different roles at least the BU1 and PA3 use cases can not be scaled. Also other use cases that require exchange of non public data will not scale.

[wfolkendt]

• The “EBW Relying Party component” is enabled by their providers to receive and store “EBW Relying Party component “ bound attestations like EBWOID and WIA and therefore able to create the verifierInfo object during a request for confidential data. That can be implemented by providing also the holder component to a verifier service, even if the customer of the Wallet Provider uses only the RP component.

[wfolkendt]

delete

[wfolkendt]

delete

[wfolkendt]

ok

[leifj]

I have a problem with the choice of extension mechanism. OpenID4VP explicitly calls verifierInfo a MAY which means that cmpliant wallets can (and will) just ignore it. Turning a MAY into a SHOULD or even MUST in a profile is problematic imo.

We have a better option and that is to introduce a client_id prefix for "mutually authenticated EBWOID-identified RP" and define the semantics of that client_id prefix. In fact you could implement this by crafting a "ebw-instance" openid federation trust mark and using the (less deployed but valid) opendid_federation: client id prefix. That gets you everything you want plus other useful properties "for free" imo.

[leifj]

There are other ways to approach this too but that is by far the easiest.

[wfolkendt]

@leifj
I agree that we will have a problem if wallets will ignore the verifierInfo object!
However an EBW owner will never use a wallet that does not identifies an unknown requester based on his EBWOID who requests highly confidential data. How does the Wallet Provider want to sale such a wallet?
I assume that EUDI wallet also must verify the optional verifierInfo objects containing the Access and Registration certificate to protect privacy of natural persons.

I don't know what is required to introduce "a client_id prefix for "mutually authenticated EBWOID-identified RP" and define the semantics of that client_id prefix."

Therefore, I formulate mandatory solution constraints:

1. The holder EBW needs to verify the requesting relying party EBWOID and BWIA to a) implement his verification obligations (=> reduced liability) and b) to protect confidential data
2. The holder (e.g. a small enterprise) should not be forced to procure an additional X509 certificate. The Holder EBW uses an EBW SaaS and has procured an identity attestation the EBWOID. (Assumption: This seems to be required if "client_id=x509_san_dns:...." is used instead of "client_id=openid_federation:...")
3. The use of an OpenID Federation based trust infrastructure should not be mandatory. It should also work with the identity chaining trust mechanism. (Remark: I hope that both infrastructures will be usable in parallel)

The OpenID4VP specification defines another standard Client Identifier Prefix that may be suited for wallets: did (Decentralized Identifier) or verifier_attestation. Do you plan to use these clientID prefixes?
Does your solution considers the above constraints?
Can you explain more about your solution?

[leifj]

I've been working on this during the day and I am going to create a PR with a (partial) solution proposal to this based on a mechanism for using the EBWOID in multiple different trust frameworks. This would allow exactly the type of policy control that you're looking for - and which btw I agree is absolutely necessary

[wfolkendt]

Lal has proposed the following text for the ADR:

Mutual identification for European Business Wallet presentation requests

Authors/Contributors:

• Florin Coptil, Bosch, Germany
• Werner Folkendt, Bosch, Germany
• Lal Chandran, iGrant.io, Sweden
• George J Padayatti, iGrant.io, Sweden
• <Please add more .. >

Obsoletes: N/A

Context

An EBW in the Holder role stores attestations that its owner treats as confidential, such as ultimate beneficial ownership and control structure. In the BU use cases, requests arrive backend to backend with no person present. The Holder EBW must decide alone, so it needs three answers a machine can check:

1. Which legal entity is asking?
2. Is the requesting software a real wallet unit, and is it still valid?
3. Does the owner's policy allow this entity to receive this attestation?

The proposed Regulation on the establishment of European Business Wallets, COM(2025) 838 final of 19 November 2025, addresses this in its Annex. Point 14(2)(b) states that "where Business Wallet owners use their Business Wallets unit to interact with competent national authorities and providers of electronic attestations of attributes, Wallet units shall enable authentication and validation of the Wallet unit components by presenting the Wallet unit attestations to those competent national authorities and providers upon their request".

Point 14 covers the issuance direction, and CS-01 already implements it. The proposal places no equivalent obligation on a party that requests attestations from a Wallet unit. That gap is what this decision fills.

We already solve this for issuance. In CS-01, a Wallet Unit proves what it is before an Issuer releases anything:

• it authenticates with an attestation, the WIA, per OpenID4VCI Appendix E, sent with its Proof-of-Possession (CS-01 section 7.4)
• the attestation is bound to the key used in the transaction, through cnf (CS-01 section 7.4)
• client_id equals the sub claim of the attestation (CS-01 sections 7.3 and 7.4)
• the attestation is checked against the Trusted List for Wallet Providers (CS-01 section 7.4)
• revocation is checked, and re-checked later (CS-01 section 7.5, CS-04 section 7.2)

In presentation, this rule applies in one direction only. CS-02 section 7.2, item 6 requires the Verifier to validate the Holder's Wallet Unit Attestation. Nothing requires the Verifier to prove the same about itself. Today it is identified only as the party that signed the request (CS-02 sections 5 and 8.2). The request carries no EBWOID and no BWUA.

The requester already holds both. An EBW is a single wallet unit that plays the Holder, Issuer, and Verifier roles (BWUA based on TS3, CS-02 chapter 4). Nothing new has to be issued to it. What is missing is an agreed way to present what it already holds.

Two places can carry this material.

	verifier_attestation Prefix, OpenID4VP 5.9.3 and 12	verifier_info, OpenID4VP 5.11
Link to the request	The attestation contains the Verifier's public key (cnf). The request signature proves the sender holds the matching private key, so the attestation cannot be copied into another party's request. This is the method CS-01 section 7.4 already uses	We must define this link ourselves. Without it, an entry can be copied into another party's request
Relation to CS-02	Already an allowed scheme, section 5	Not used today
Identity carriers per request	One	Two, checked alongside client_id

Legal entities that run an EUDI Relying Party component hold neither an EBWOID nor a BWUA. Making a parameter mandatory for all requests would exclude them from all traffic, including data that the KYC and PA3 use cases depend on and that is not confidential.

Decision

1. Apply the same rule in both directions, using the issuance method. WE BUILD defines the EBW Verifier Attestation, a profile of the OpenID4VP Verifier Attestation JWT (section 12), presented with the verifier_attestation Client Identifier Prefix (section 5.9.3), which CS-02 section 5 already allows. It MUST contain:

• the EBWOID of the legal entity operating the requesting wallet unit
• the BWUA of the requesting wallet unit, as defined in CS-05
• a cnf claim whose key signs the Presentation Request Object, so that the signature proves the sender holds that key
• sub equal to the client_id in the request object

Upon receiving a Presentation Request, the Holder EBW MUST verify the presented verifier_attestation (including the embedded EBWOID and BWUA) in strict accordance with the steps defined in the** We Build Base Verification Rulebook.

The following paragraphs were added by @wfolkendt :
The Presentation Request MAY include, alongside the standard verifier_attestation, one or more Authorization Attestations (e.g., a regulatory license like a banking license or a role-based credential) presented as sibling assertions in the request object (e.g., using client_assertion).

When present, the Holder EBW's automation policy engine SHOULD use these dynamic, verified attributes as inputs to automatically approve the release of confidential data. This removes the administrative burden of maintaining static, company-specific approval whitelists."

"By presenting these as sibling assertions, the Wallet Provider remains completely neutral (only issuing one generic verifier_attestation with the EBWOID and BWUA), while the requesting EBW can dynamically attach its sector-specific licenses directly to the transaction.iving a Presentation Request, the Holder EBW MUST verify the presented verifier_attestation (including the embedded EBWOID and BWUA) in strict accordance with the steps defined in the We Build Base Verification Rulebook._

The Presentation Request MAY include, alongside the standard verifier_attestation, one or more Authorization Attestations (e.g., a regulatory license like a banking license or a role-based credential) presented as sibling assertions in the request object (e.g., using client_assertion).**_

When present, the Holder EBW's automation policy engine SHOULD use these dynamic, verified attributes as inputs to automatically approve the release of confidential data. This removes the administrative burden of maintaining static, company-specific approval whitelists."

By presenting these as sibling assertions, the Wallet Provider remains completely neutral (only issuing one generic verifier_attestation with the EBWOID and BWUA), while the requesting EBW can dynamically attach its sector-specific licenses directly to the transaction."

2. An EBW acting as Verifier MUST include its EBW Verifier Attestation in every Presentation Request it sends. An EBW always holds an EBWOID and a BWUA, so it can always comply. An attestation rulebook MAY declare that a given attestation type MUST NOT be released unless the request carries a valid EBW Verifier Attestation, and an owner MAY apply stricter rules for its own wallet. A valid attestation does not by itself give a right to a response.

Verifiers that are not EBWs are not excluded. Their requests carry no EBW Verifier Attestation, and the Holder decides what to release under Decision 3, using the Client Identifier Schemes CS-02 section 5 already allows.

3. One place where policy is decided. The validated attestation is an input to the automatic approval list from EBW EAA exchange automation, not a second gate in front of it. Where the owner approved a requester and attestation combination in advance, that approval is the Holder's consent for CS-02 section 7.1, and the wallet unit MUST record the release and show it to the owner. Otherwise it MUST ask the owner or reject.

What this decision does not change

Area	Already decided in
Protocols	Baseline protocols
Signed requests, client_id, allowed schemes, nonce, audience, expiry	CS-02 sections 5, 6.1.1, 6.1.3, 8.2
Attestation structure, validity, revocation, binding	CS-04 for the WUA, CS-05 for the BWUA, both authoritative
Trust lists	Trusted lists, applied in CS-01 section 7.4
What a Verifier checks in a response	CS-02 section 7.2, item 6

Consequences

What becomes easier?

A Holder EBW can identify the requesting entity and check that its wallet unit is sound and not revoked, using material the requester already holds and a verification path its implementation already runs for issuance. Owners can accept requests they refuse today.

Requests can be answered without a person present, which is a precondition for using the EBW inside internal systems. Consent is given once, by the owner, in a list the owner controls.

There is one identity carrier, one binding rule, one trust path and one revocation path, in both directions. Testing extends what exists instead of adding a second surface.

The following paragraphs were added by @wfolkendt :
"If you only verify the identity (EBWOID)and the EBW integrity (BWUA) of the requester, your Holder EBW's approval list must be managed on a per-company basis (e.g., “Allow Bank X, Allow Bank Y, Allow Supplier Z”). This creates a massive administrative burden because your company must manually maintain a whitelist of individual partners.
By adding an "Authorization Attestation" (a role-based or attribute-based credential, you shift from Identity-Based Access Control to Attribute-Based Access Control (ABAC. You trust the issuer of the authorization attestation (e.g., BaFin a banking supervising organization, who issues authorization attestation e.g. banking licenses). The holder EBW does not need to maintain a list of individual bank names he needs to know and trust authorization trust anchor organization.
mutual-identification_V3.docx"

What becomes more difficult?

Wallet Providers must issue an EBW Verifier Attestation for each wallet unit and keep its revocation status up to date. Where a customer runs only a Relying Party component, the provider must decide whether to give it EBW-bound material.

Owners must decide which attestations are confidential. Classification will vary until common practice develops.

Requesters without EBW-bound material will not receive confidential attestations. For KYC and PA3 this must be explained before participants design their integration.

How do we address the risks introduced by this change?

Wallet Providers can enable a Relying Party component to hold and present an EBW Verifier Attestation, for example by supplying the holder component with the verifier service.

The pre-flight specification should publish a default classification for the BU1 attestation types, so owners start from a common baseline.

If the Architecture Group decides that the Client Identifier layer cannot carry this material, the same requirements can be written in the verifier_info format. Decision 1 then changes, Decisions 2 to 4 stand, and the profile must additionally define the link between the entry and the request that section 12 provides by default.

Advice

Once merged, this is our consortium's decision. This does not mean all participants agree it is the best possible decision. In the decision-making process, we have heard the following advice.

• All authors / Contributors
• yyyy-mm-dd, Name, Affiliation, Country: OK or summary of advice

[wfolkendt]

Questions raised by Eelco:

Hi Werner, Lal, and others,

Thanks for updating the ADR. Although I do like the idea of using the verifier_attestation client id prefix, since it’s purpose is identification and authentication, I foresee a few issues with the ADR:
• The verifier_attestation client id prefix specifies that only one JWT needs to be placed in the jwt JOSE header. The ADR suggests to add both the EBWOID and the BWUA.

Lal's answer:
"Agreed, the current text is ambiguous. The intent is a single profiled JWT. We can update the ADR so that the BWUA is no longer carried within the attestation at all: the Wallet Provider instead asserts the EBWOID, the wallet unit identifier, and the status reference from CS-05 directly as claims in a single JWT, with cnf and sub per section 5.9.3. The BWUA artefact is neither embedded nor fetched."

• The main purpose of the verifier_attestation client prefix is to authenticate the relying party, e.g. when there is not trust chain that can be used. Who will sign the verifier_attestation in this case? Is it the EBWOID provider that needs to be trusted in this case?

Lal's answer:
"The Wallet Provider of the requesting wallet unit, validated against the Trusted List for Wallet Providers, as CS-01 section 7.4 does for the WIA. The Wallet Provider verifies the EBWOID binding at onboarding and asserts it; the EBWOID provider is not the trust anchor. This was missing and can be added to the Decision section."

• If the EBW is requesting data from an EUDI wallet, should it also use the verifier_attestation client id prefix, or should it than just use the x509_san_dns client id prefix? In the ADR it is stated that this should always be used when the RP is an EBW. This means all EUDI wallets need to support this verifier_attestation and trust the attestation provider.

Lal's answer:
"Agreed, the ADR should not say "every presentation request". The rule will apply only when an EBW sends a request to another EBW, or when the requested attestation type falls under an EBW rulebook. When an EBW requests data from an EUDI wallet, it follows that ecosystem's rules instead, in practice x509_san_dns. EUDI wallets do not need to support the verifier_attestation prefix or trust our attestation providers."

These issues don’t apply when the verifierInfo is used. In that case it is not used for authentication and may be ignored by Holder wallets. This makes it less intrusive and really up to the Holder to decide.