General feedback regarding the eAddress Concept / "discoverable capability"

[flo0x]

Here are some remarks regarding the eAddress based on the results of prototyping and testing for organizational wallets.

General:
• A personal wallet is a wallet where the PID is stored (NPID Wallet).
• An organizational wallet is a wallet where the LPID is stored (LPID Wallet).
It’s important that both credentials cannot reside in the same wallet instance.
Whether this is fully mobile, fully server-based or a combination (see Malin’s slides) should be left to the wallet provider and user acceptance. What’s crucial is that the WCC (Wallet Core Component) and Wallet Application can be deployed in different ecosystems.

Regarding the document:

1. Need for Wallet eAddress
   I believe the main need is not a server-based wallet.
   What is needed is a "discoverable capability"—meaning the wallet can be made discoverable and externally accessible. Where the Wallet Core Component (WCC) resides should remain flexible.
   Regarding the statement: "The eAddress is controlled by the wallet owner using its server-based wallet," I suggest changing it to: "The eAddress is controlled by the wallet owner."

2. Rule Requests for Discoverable Capability
   In the case of "discoverable capability," the "rule(s) requests" should also be available to decide on the acceptance/denial process (similar to what you mentioned in the document: public, private and protected).

3. Issuer Capabilities for Organizational Wallets
   Additionally, for organizational wallets, an "issuer capability" is sometimes required so that legal entities can issue attestations (EAA) in the future.
   This capability automatically implies a need for "discoverable capability," as the issuer needs to be contacted by the holder or relying party (RP) to attest the wallet issuer's ownership.

Why we need it: these conclusions are based on tests in the KYC and KYS processes (national and cross-border use cases):
• For small companies:
There is no need for an organizational wallet with "discoverable capability". All processes can be handled manually.
While there are some limitations, it mainly depends on the legal entity's acceptance in terms of cost, time, UI and availability to the RP.

• For mid-sized companies:
A "discoverable capability" is required due to significantly higher time and availability constraints. Sometimes, the "issuer capability" is also required.

• For larger companies:
The "issuer capability" is required, along with the "discoverable capability".

• For corporates:
The "issuer capability" is mandatory, and the "discoverable capability" is automatically required.
Additionally, fully automated "rules" must be supported.

[a-fox]

Thanks @flo0x, I agree in general that it's technically not something that should be restricted to server-based wallets. In the document we wanted to focus and scope it so, in order to avoid the "this can't be done for natural person wallets / mobile wallets" -comments. The RFC should be more agnostic to this.

Here's some more comments:

What is needed is a "discoverable capability"

I agree, but I also think there are two sides to the terminology. Endpoint discovery is the capability you refer to, but the other side of the coin is endpoint provisioning. Discovery of the wallet endpoint is the process where relying party discovers the endpoint and uses it to contact. Endpoint provisioning is the definition and configuration of the endpoint. eAddress is the a catchy term for all of this.

I propose that the RFC should contain the following chapters separated:

• Endpoint provisioning (defining how eAddress can be configured)
• Endpoint discovery (defining how eAddress can be presented and discovered by the RP)

Rule Requests for Discoverable Capability
In the case of "discoverable capability," the "rule(s) requests" should also be available to decide on the acceptance/denial process (similar to what you mentioned in the document: public, private and protected).

I agree that there should be a capability to have authorization rules, but I'm still unsure if or how it should be part of the spec. I think we could include some authorization parameters, like I mention in the Private/Protected distribution profiles. We should be very careful to include only necessary things, while allowing more advanced implementations. Let's think more on how the authorization rules should be included.

Issuer Capabilities for Organizational Wallets
Additionally, for organizational wallets, an "issuer capability" is sometimes required so that legal entities can issue attestations (EAA) in the future.
This capability automatically implies a need for "discoverable capability," as the issuer needs to be contacted by the holder or relying party (RP) to attest the wallet issuer's ownership.

I agree, makes sense. So in this case, this would be the issuance endpoint that can be shared using eAddress.