Multiple business wallets for one business wallet owne

[wfolkendt]

As a holder and EBW owner
I want to use multiple business wallets, each containing one EBW-OID per wallet that will be used to proof that the wallet is owned by the legal entity
so I can operate additional wallets required to manage different types of attestations or representing assets owned by me (site wallet, smart object wallets, software services (e.g. DPP systems))

[eklaver]

Agree, but is this really an issue for the architecture group? Different wallet providers provide several solutions to implement this. In our Business Wallet, you can easily switch between different wallet instances that you can operate. Other wallet providers just provide you with different domain names for different wallet instances.

[sander]

I agree this is an important requirement to take into account. Possibly one organisation even uses various wallet providers – one specialised in eFTI, another in fiscal data. It is cross-cutting in the sense that the WE BUILD Digital Directory and the QERDS might need support.

Is there a concrete use case from which we can elicit more detailed requirements? For example, do others need to know which EBW to contact for which procedure?

[Ssiieerrdd]

I think it should be possible to have multiple EBW's but as Sander mentioned how does a sender know which EBW to address. How would this work in the directory for businesses.
I think for all the other use cases it shouldn't be an issue as long as its taken into account from day one :-)

[wfolkendt]

Agree, but is this really an issue for the architecture group? Different wallet providers provide several solutions to implement this. In our Business Wallet, you can easily switch between different wallet instances that you can operate. Other wallet providers just provide you with different domain names for different wallet instances.

From my perspective it is an architecture group issue. A EBWOID provider must be willing to issue more than one EBWOID instances to the same EBWOID owner. The EU Digital Directory operator must accept more than one entry per legal entity.

[eklaver]

Ok, agreed. For wallet-initiated issuance flow this shouldn't be a problem, since the wallet itself will specify the credential offer endpoint to issue to. For (automated) issuer-initiated issuance flow, an attestation provider needs some way to choose the right wallet instance.

[Saramandus]

I believe this should be clarified in the Business Wallet Definition and confirmed with the PID/EBWOID group as well as include wallet providers then?

@miguelaguilar-bv @malinnorlander @SarahGraefer - what is your take on an EBWOID provider being willing to issue more than one EBWOID instances to the same EBWOID owner?

@michelleludovici-ai @lalc @rkxx might - any views on this topic from a EWB perspective?

[miluDIGG]

In my opinion it should be no problem to issue an EBWOID to different EBW instances and solutions. I will bring it to the next PID/EBWOID meeting next week thursday!

[malinnorlander]

There is no limitiation on how many EBW instances/units an economic operator can own, it's up to each EO to decide depending on the scale and needs of their business. Every EBW unit/instance will need an EBWOID, so one issued EBWOID per EBW instance/unit is expected.

By technical means, there might be batch issuance of EBWOIDs as well, so in reality one EBW unit/instance can hold several instances of one EBWOID. What's important is that EBWOIDs with differing idenities can't be issued to the same EBW unit/instance.

[wfolkendt]

@malinnorlander ; @michelleludovici-ai ; @Saramandus
I really appreciate the fact that one legal entity can use multiple wallets and we may also have the requirement that we need multiple EBWOID instances in one EBW instance.
Let us assume that the PID/EBWOID group agrees to the requirement that and EBWOID also confirms the ownership of a wallet created public/private key pair, by including the public key or a key identifier (e.g. did:ebsi) in the payload as an additional attribute.
During the EWC we have discussed the fact that an EAA provider needs multiple EBWOID attestations within one EBW instance depending which trust infrastructure he is forced to use.
If he needs to use EBSI for his customers he needs an EBWOID that confirms the binding of his did:ebsi to his legal entity EUID.
If he is forced to use did:web for his customers he needs EBWOID that confirms the binding of his did:web to the EUID
If he needs to use chaining the EBWOID needs to include the EBW wallet generated public key and therefore confirms the binding. (see adr: [https://github.com//pull/168])

• What do you think about the need to have different EBWOIDs (or additional "issuing attestations" with the same attributes name ,euid, key respective key_identifier) issued with the same trustable issuing process by the EBWOID QTSP provider?
• How could we include representants from the PID/EBWOID group in the discussion related this topic that currently is conducted mainly in the architecture group based on the above ADR?

[malinnorlander]

@malinnorlander ; @michelleludovici-ai ; @Saramandus I really appreciate the fact that one legal entity can use multiple wallets and we may also have the requirement that we need multiple EBWOID instances in one EBW instance. Let us assume that the PID/EBWOID group agrees to the requirement that and EBWOID also confirms the ownership of a wallet created public/private key pair, by including the public key or a key identifier (e.g. did:ebsi) in the payload as an additional attribute. During the EWC we have discussed the fact that an EAA provider needs multiple EBWOID attestations within one EBW instance depending which trust infrastructure he is forced to use. If he needs to use EBSI for his customers he needs an EBWOID that confirms the binding of his did:ebsi to his legal entity EUID. If he is forced to use did:web for his customers he needs EBWOID that confirms the binding of his did:web to the EUID If he needs to use chaining the EBWOID needs to include the EBW wallet generated public key and therefore confirms the binding. (see adr: [https://github.com//pull/168])

• What do you think about the need to have different EBWOIDs (or additional "issuing attestations" with the same attributes name ,euid, key respective key_identifier) issued with the same trustable issuing process by the EBWOID QTSP provider?
• How could we include representants from the PID/EBWOID group in the discussion related this topic that currently is conducted mainly in the architecture group based on the above ADR?

There should be no conflict to have valid EBWOIDS of differing formats (SD JWT VC/mdoc) in one EBW unit/instance as long as the attested attributes (EUID and name) in the differing EBWOIDs are identical. I.e if I own two companies I can't hold EBWOIDs for both companies in one EBW unit/instance. Inavlid EBWOIDs will also remian in the EBW unit/instance until deleted by owner.

For EBWOID issuers to attest to did.web/did:ebsi I'm a bit sceptical, and nothing hinders that those attributes are separate attestations.

I am a part of PID/EWOID group as well so I can represent that group in these discussions.

[Saramandus]

@wfolkendt Do you feel that this question has been answered and it is ok to close this issue? Many things have happened and new discussions have arisen and we know more a lot more about the usecase scenarios and their different needs now, and also have a sense of what needs to be on a use case level and on a consortium-wide level. Please update if needed, or close if you do not believe it is relevant anymore.

[wfolkendt]

@sarah: @malinnorlander
I agree with the answers. I have re-read the ebwoid rulebook with the expectation that the corresponding statements/rules are added in chapter "4. Attestation usage" especially under "4.1 Issuer Obligations". The subchapters have been removed and I could not find anything. So my questions is:

• Where do we document that an EBW owner can own multiple EBWs each with more than one EBWOID in one wallet "as long as the attested attributes (EUID and name) in the differing EBWOIDs are identical."

The mandatory use case requirement to also have an additional attribute that confirms the ownership of a EBW key pair by including the public key is also still open. I propose to handle this topic that enables EAA signing in a new issue after we have decided related attestation chaining #168 and mutual authentication #205.

If the corresponding rulebook update is performed we can close the issue.