Blueprint EBWOID issuance

[Saramandus]

Process on EBWOID issuing received from the PID/EBWOID capability group.

[Saramandus]

I believe this might be interesting for @eklaver @georgepadayatti @Benhan11 @lalc @michelleludovici-ai @malinnorlander @rkxx @thodoris @joostd to review since it concerns EBW as well as EBWOID.

[lalc]

I believe this might be interesting for @eklaver @georgepadayatti @Benhan11 @lalc @michelleludovici-ai @malinnorlander @rkxx @thodoris @joostd to review since it concerns EBW as well as EBWOID.

Will check and revert during the week. Yes, this is very interesting for us. :)

[malinnorlander]

This is how we drafted the GENERAL process for EBWOID issuance. Every Issuer will issue according to national regulations, what's important are the verifications that each issuer MUST do. The order of verifications is not important.

sequenceDiagram
  autonumber
  actor Rep as Representative
  participant Issuer as EBWOID Issuer
  participant AS as Authentic Source
  participant IW as Issuer Business Wallet
  participant HW as Holder Business Wallet
  %%participant Reg as Revocation / Directory Services

  rect rgb(245,245,245)
    Note left of Rep: Initiate request
    Rep->>Issuer: Visit eService
    Rep->>Issuer: Provide user credentials (LoA Substantial)
    Issuer-->>Issuer: Verify user credentials
    Rep->>Issuer: Initiate EBWOID request
    Rep->>Issuer: Provide economic operator identifier
    Rep->>Issuer: Provide EBW endpoint
  end

  rect rgb(235,245,255)
    Note left of Issuer: Verify eligibility
      Issuer->>AS: Request economic operator information
      AS-->>Issuer: Provide economic operator information
      Issuer->>Issuer: Verify economic operator status
      Issuer->>AS: Request user powers
      AS-->>Issuer: Provide user powers information
      Issuer->>Issuer: Verify user powers
  end
  
  rect rgb(235,245,255)
    Note left of Issuer: Issue EBWOID attestation
    Issuer->>AS: Request EBWOID information
    AS-->>Issuer: Provide EBWOID information
    Issuer->>IW: Request EBWOID issuance
    IW->>IW: Construct EBWOID



    rect rgb(255,245,255)
    Note left of Issuer: Verify Wallet
    IW->>HW: Request proof of state operational
    HW-->>IW: Provide proof
    IW->>IW: Verify wallet status
end
    IW->>HW: Issue EBWOID
    HW->>HW: Store EBWOID
    IW-->>Issuer: Notify of issuance
    
    rect rgb(245,345,355)
    Note left of Issuer: Publish revocation information for longlived EBWOID
    Issuer->>Issuer: Publish revocation information
end
    Issuer-->>Rep: Notify representative (and economic operator)
 
  end

Loading

[miguelaguilar-bv]

Please see an updated version, which the group agrees is the minimum for a generic onboarding process.

It is important to note that the order of implementation of controls may differ between Member States. This process description should not be seen as presenting all national implementation, but rather a common baseline allowing EBWOID issuers to implement the process and create trust.

The user may initiate the process by different channels(the term eService includes both accessing directly a Webpage at the issuer or being redirected from a Wallet).

Some terms being used in the process that may need semantic explanation to facilitate understanding and we will do that once this version is delivered. A summary and a description of the controls.

Certain assumptions have been made, such as LoA high credentials exists already and that the user in this process has a verified representation, has signatory rights or otherwise fulfills the relevant requirements in the Member State (either previously registered or as a separate process).

An Endpoint refers to a Business Wallet or if any available, other means to offer the credential to issue.

We use the term "Issuer Business Wallet / component" as it is not yet clear to everyone if they will issue through a Wallet or a component to issue the credential. This is a Member State or organisation decision.

It is impossible to cover all deviations or national variations, and this is not the interion of this process diagram.

code in mermaid

[leifj]

I propose a slight change to the generic model: replace the word "provide endpoint information" with "discover wallet endpoint" and draw that arrow from the euoid issuer to the representative (reversed). This covers both the cases when the representative visits the e-service via a redirect from a wallet (bringing endpoint information along) and the case when there is a discovery service for eu wallets that can be used.

[leifj]

I propose using the generic model provided by @miguelaguilar-bv with the change I proposed in a comment.

[Saramandus]

I have updated the file with the latest suggestion from the EBWOID group. I support Leifs suggestion - if @miguelaguilar-bv think it is OK I will add that change as well to this PR. If not I will it as it is since we need to close this PR for Blueprint v1.0. We have the rest of the project to decide on the details. :)

[miguelaguilar-bv]

I propose using the generic model provided by @miguelaguilar-bv with the change I proposed in a comment.

Agree with @leifj . We have had the same discussion in the group but didn't reach a final agreement. Since we are including Wallet holder, Wallet issuer as actors, it would be clearer to refer it as "discover wallet endpoint".

Thank you @Saramandus for making the changes.

We will provide textual descriptions to support the understanding of the diagram.

[sander]

Why should the Blueprint contain a dedicated specification of EBWOID issuance, if EBWOID is just a PuB-EAA or QEAA?

Just like other PuB-EAA and QEAA in WE BUILD, various interaction patterns are possible, and we should align on those interaction patterns. See #114.

If there is a justification for having a dedicated specification of EBWOID issuance, this justification should be added to the introduction of this section.

[Saramandus]

I agree that a more descriptive introduction would be good and I believe that @miguelaguilar-bv also has a plan for description of some of the steps (those that need describing, I don't see a reason to add descriptions to every action).

[oliver-fro]

Why should the Blueprint contain a dedicated specification of EBWOID issuance, if EBWOID is just a PuB-EAA or QEAA?

Just like other PuB-EAA and QEAA in WE BUILD, various interaction patterns are possible, and we should align on those interaction patterns. See #114.

If there is a justification for having a dedicated specification of EBWOID issuance, this justification should be added to the introduction of this section.

You are right that the EBWOID (and the PID) share many characteristics with (Q-/Pub-)EAA. However, at the beginning of WE BUILD it seems that this two were considered special. And more over a wallet instance without one of those two is not complete. Any other EAA may be absent without any effect for the status of the wallet instance. Now we have a special task (WP 4, Task 3) for the issuing of the PID and EBWOID. All this justifies a special treatment in the blue print for me.

Requested changes has been added to the latest sequence diagram.

[rkxx]

I agree with @sander. Issuing EBWOID should follow the defined interaction patterns. It should not define its own flow.

Remarks on the defined interaction patterns:

The interaction patterns dictate that the issuer should request the user's consent before issuing the credential. Why is this extra step needed? The user has already explicitly requested the credential.

The authentication step in the interaction patterns needs to be clarified. It isn't authentication. Instead, it is identity proofing, or more generally, prerequisite proofing. For example, issuing an EBWOID requires proof of the identity of the requester. The issuer can choose from various identity proofing mechanisms.

• eID (eIDAS1)
• PID (eIDAS2)
• VideoIdent
• Natural person credential (enhanced EBW)
• other certified methods of suitable IAL

This brings us to two flavors of issuing credentials:

1. basic EBW

The basic EBW doesn't hold the identity of the natural persons acting on behalf the legal person. Therefore, the EBW cannot be used to proof the identity of the requester. Instead, a separate identity proofing process is required to proof the identity of the requester, e.g.:

• wallet dance with EUDI
• video call with VideoIdent System
• eID

sequenceDiagram
user ->> ebw : select credential type
ebw ->> issuer : request credential
create participant identityProofingService
issuer ->> identityProofingService : request identity proofing
note over user, identityProofingService : identity proofing (eID, PID, VideoIdent, ...)
destroy identityProofingService
identityProofingService ->> issuer : proofed identity
issuer ->> issuer : verifies scopeOfAuthorization
issuer ->> ebw : issues credential 

Loading

2. enhanced EWB

The enhanced EBW holds the identities of legal persons and natural persons acting on their behalf. The above interaction pattern is used to retrieve the identity credentials of the natural persons. These identities can then be used to prove the requester's identity for any kind of credential issuance, including EBWOID, EUCC, KYC, KYS and others.

sequenceDiagram
user ->> ebw : select credential type
ebw ->> issuer : request credential
issuer ->> ebw : request presentation
ebw ->> issuer : present credential 
issuer ->> issuer : verifies scopeOfAuthorization
issuer ->> ebw : issues credential 

Loading

[oliver-fro]

I agree with @sander. Issuing EBWOID should follow the defined interaction patterns. It should not define its own flow.

Remarks on the defined interaction patterns:

The interaction patterns dictate that the issuer should request the user's consent before issuing the credential. Why is this extra step needed? The user has already explicitly requested the credential.

I agree.

The authentication step in the interaction patterns needs to be clarified. It isn't authentication. Instead, it is identity proofing, or more generally, prerequisite proofing. For example, issuing an EBWOID requires proof of the identity of the requester.

What's the difference between identity proofing and authentication?

This brings us to two flavors of issuing credentials:

1. basic EBW

The basic EBW doesn't hold the identity of the natural persons acting on behalf the legal person. Therefore, the EBW cannot be used to proof the identity of the requester. Instead, a separate identity proofing process is required to proof the identity of the requester, e.g.:

I think the EBW can never be used to proof the identiy of a natural person. And only a natural person can be the requester.

2. enhanced EWB

The enhanced EBW holds the identities of legal persons and natural persons acting on their behalf. The above interaction pattern is used to retrieve the identity credentials of the natural persons. These identities can then be used to prove the requester's identity for any kind of credential issuance, including EBWOID, EUCC, KYC, KYS and others.

How can an EBW hold all this information without an EBWOID? And how can the identity be proven? The requester can only prove that he has de facto the ability to use the EBW. If there are two managers of a company and both can use the EBW independently, no identity is proven by using the EBW. Or am I mistaken?

I think for the issuing process of the EBWOID we always need a speical identity proofing/authentication method for the natural person beside the EBW.

`

[Saramandus]

I have updated the chapter with an introduction hopefully clarifion why adding this section is justified, or what do you think @sander?

I believe the EBWOID (and also PID) issuance is something we need to discuss between the PID-Wallet-Architecture Group in order to agree on a more detailed process that works. Issue #62 raise this. The Blueprint is a living document and will be continuously updated as we learn - the question for now is if this PR can be added for v1.0 (final DL tomorrow morning) or if we should skip it for now.

[Saramandus]

The first version of the Blueprint has now been delivered to the Management board. Next formal update is in August/September but this is much needed for the online version anyway and I believe it is a good discussion and important that we agree on the details.

[rkxx]

What's the difference between identity proofing and authentication?

Identity proofing is about establishing who someone is in the first place (Checking Id-Card, VideoIdent, ...). Authentication is about confirming that the person or entity trying to access a system is the same one that was already enrolled (user name, password, MFA , ...).
A more formal definition can be found here:
https://pages.nist.gov/800-63-3/sp800-63-3.html

I think the EBW can never be used to proof the identity of a natural person. And only a natural person can be the requester.

Of course, the EBW can be used to verify the identity of a natural person. It just needs to hold the credential of the natural person, which is bound to cryptographic key material under the sole control of that person.

How can an EBW hold all this information without an EBWOID? And how can the identity be proven? The requester can only prove that he has de facto the ability to use the EBW. If there are two managers of a company and both can use the EBW independently, no identity is proven by using the EBW. Or am I mistaken?

This is true of basic wallets, which cannot hold private key material for individual users. However, an advanced wallet with enhanced user management can store private keys for each user. This allows issuers to link natural person credentials to users. Users of an advanced wallet can present natural person credentials and apply authentication proofs (such as key binding tokens or data integrity proofs) to these presentations. Furthermore, legal person credentials (e.g. an EUCC) can be bound to legal representatives, enabling users to prove their authorisation to represent the legal person.

[benhansson]

Update the EBWOID rulebook link to:
https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/tree/main/rulebooks/rb-ebw-oid

[Saramandus]

@oliver-fro @miguelaguilar-bv @malinnorlander

Could you please respond to the comments and update the flow, if needed, accordingly? I would very much like to see this in the Blueprint within a week or so, I believe it has just been forgotten now that the DL has passes. :)

[flo0x]

Questions:

1. Why is EBW-OID part of the Blueprint scope?
   From a responsibility perspective, should EBW-OID be covered under Chapter 4.1 – Issuer Responsibilities over ebwoid-rulebook, as it mainly relates to issuance, lifecycle management, and issuer obligations?

2. Offer Acceptance
   For business attestations exchange (e.g., IBAN Ownership Attestation, Invoice Attestation,etc), we alignment on how the offer acceptance process should work in a business context.
   Should this be:

• Managed by the user and wallet functionality, or
• Standardized as part of the business wallet interaction model?

Currently, the following approaches are supported:

• Manual acceptance - Offer via QR code or URI -> User decides when and where to accept
• Automated issuance flow - Public endpoint supporting OpenID4VCI -> Wallet retrieves and processes the offer automatically based on the internal rules.
• Wallet provider integration -> Direct integration between wallet provider and issuer/service provider

[Saramandus]

Thank you for your questions @flo0x! These are my 50 cents. =)

1. Why is EBW-OID part of the Blueprint scope?
   From a responsibility perspective, should EBW-OID be covered under Chapter 4.1 – Issuer Responsibilities over ebwoid-rulebook, as it mainly relates to issuance, lifecycle management, and issuer obligations?

My reasoning is that EBWOID belongs in the Blueprint scope because it is the foundational architectural anchor for the entire ecosystem, not just a data schema.

• Lifecycle transition trigger: It is the mechanism that transitions a wallet from a purely technical "OPERATIONAL" state to a legally recognized "VALID" state
• Trust dependency enforcement: The architecture defines a mandatory dependency where Identity Trust (EBW-OID) must rest upon Structural Trust (BWUA)
• It requires cryptographic binding to the specific wallet unit, which is a core technical requirement for wallet providers, not just a business rule for issuers
• Standardizes the Identity Anchor across use cases

While the Rulebook defines the data fields, the Blueprint defines the logic and trust layers that make the Business Wallet functional. Leaving it out would (in my opinion) detach the ecosystem's primary identity anchor from the lifecycle and security mechanisms that define it.

2. Offer Acceptance

I believe the offer acceptance must be described (e.g. via #206) to fulfilll the mandate for automated M2M interaction (art 6?). This ensures a Credential Offer is processed consistently across all wallet providers whether triggered manually or via a policy-driven M2M flow.

I hope that @oliver-fro @miguelaguilar-bv @malinnorlander will update this and also respond to the comments and questions you have.

[oliver-fro]

Of course, the EBW can be used to verify the identity of a natural person. It just needs to hold the credential of the natural person, which is bound to cryptographic key material under the sole control of that person.

A company with 3 directors has one EBW but three people using the EBW. Or has this changed?

This is true of basic wallets, which cannot hold private key material for individual users. However, an advanced wallet with enhanced user management can store private keys for each user. This allows issuers to link natural person credentials to users. Users of an advanced wallet can present natural person credentials and apply authentication proofs (such as key binding tokens or data integrity proofs) to these presentations. Furthermore, legal person credentials (e.g. an EUCC) can be bound to legal representatives, enabling users to prove their authorisation to represent the legal person.

So there are user credentials in an EBW which are not issued by the competent authority but by the company itself. Why not use the official PID or any other method of identifying a person?

[malinnorlander]

Of course, the EBW can be used to verify the identity of a natural person. It just needs to hold the credential of the natural person, which is bound to cryptographic key material under the sole control of that person.

A company with 3 directors has one EBW but three people using the EBW. Or has this changed?

This is true of basic wallets, which cannot hold private key material for individual users. However, an advanced wallet with enhanced user management can store private keys for each user. This allows issuers to link natural person credentials to users. Users of an advanced wallet can present natural person credentials and apply authentication proofs (such as key binding tokens or data integrity proofs) to these presentations. Furthermore, legal person credentials (e.g. an EUCC) can be bound to legal representatives, enabling users to prove their authorisation to represent the legal person.

So there are user credentials in an EBW which are not issued by the competent authority but by the company itself. Why not use the official PID or any other method of identifying a person?

I don't think there is an "of course" on PIDs in an EBW. EBWs will hold only EBWOIDs, and only EBWOIDs representing the same economic operator. The owner of the EBW is the economic operator, there can only be one owner, but there can be many users. Users are not limited to CEOs or any other role within the economic operator, it is up to the EO to assign authority to use the EBW tho whom they see fit.

The EBWOID + WUA = valid EBW.

The EBWOID is used for authentication of the EO. The EBW is not a mean for authentication of a natural person.

[Saramandus]

@malinnorlander @miguelaguilar-bv @oliver-fro - The deadline to submit changes to the Blueprint for the one-year review is in one week. Could you please update the text and issuance sequence to the version that should go into the blueprint? Or is the current version the one to approve after the last discussion as well?