Privacy Considerations: Types of Wallets and trust in different Wallets

[johannhof]

Talking to @simoneonofri we noted that in practice there are different types of Wallets that may need to be considered differently from a browser / OS level. For example, a government Wallet may have the desire to authorize verifiers through its own mechanism, and there could be a reasonable argument to be made that the browser should either get out of the way of that, or provide some protocol to support this.

This same requirement may not work for other arbitrary Wallets, where the user agent may have less trust (but, conversely, whose use cases may also be less risky than sharing government-issued identity).

It's a complex space overall and this seems like an important consideration.

[npdoty]

I'm not sure I follow the argument for the browser to "get out of the way of that". Governments might not want browsers and other user-controlled software to analyze or control the requests that are made, but I don't see how the user would benefit.

If both wallets and browsers are user agents (which I believe is the common assumption, even if sometimes either might not be fully trusted by the user), then both would have an interest in helping the user understand the implications and make choices. User agents can collaborate with each other (passing through the relevant information so that another user agent can also help the user, for example), but I don't think we should recommend some set of situations where one user agent should abdicate responsibility to another.

[simoneonofri]

Hi Nick, I'll try to illustrate with a couple of hypothetical examples:

Scenario 1

1. The Verifier is a government-authorized gambling site required by law to check certain properties when users sign up. This is an issue I've seen in a pilot implementation in Europe, but on a different topic.
2. In this case, the Verifier knows that it will only accept credentials issued by the government that authorizes it, and the government Wallet knows that it will only provide credentials to authorized Verifiers (which will specify the origin in the presentation request).
3. When we put the Browser to mediate the request, since it is a different user agent, on the one hand, we can consider applying the Defense in Depth principle and therefore provide for some kind of verification at the Browser level. For example 3.1 Checking the user's request before it is forwarded to the Wallet (site X requests to see Y, is that OK?) to avoid exposing data to the Wallet and perhaps even after the credential has been selected (are you sure you want to do this?). 3.2 Checking whether the Verifier is authorized for that specific request. This check is currently (in the implementation I have seen) delegated to the Wallet. Alternatively, we could also consider having the Browser perform this check with double verification. This may mitigate one of the threats in FO?

Scenario 2 (not in the presentation, but still an interesting case)

1. I buy concert tickets, and the issuer (the concert website) wants to put them in my Wallet via the browser.
2. In this case, however, the issuer may not have its Wallet (and not a Gov Wallet), so it leverages the Wallets that the user has installed (which some concerts do, where you can put them in your phone's Wallet).
3. Therefore, here we have an arbitrary issuer and an arbitrary wallet, and so check 2 would not be feasible.

Concerning the Wallet instances type from the technological ponit of view (reference):

• Mobile Wallet Native Application
• Web Wallet Native Application
• Custodial Web Wallet
• Non-Custodial Web Wallet
• Progressive Web Application Wallet (PWAW)