WICG
Cross-origin mitigations can't be enforced at the wallet layer when multiple wallets are used
For example, if Credential A is held in Wallet X and Credential B is held in Wallet Y then Wallet X and Wallet Y do not have knowledge of the requests and responses that have been granted by the other wallets facilitating requests to detect and help mitigate cross origin tracking or oversharing under the current design.
Right now, the expectation is on the User to understand what information is gathered, how it can be correlated with other information, and how long it's being retained for by each relying party site that requests the information. This is because the Wallets do not work in coordination to solve this issue.
Wallets need some way to coordinate in order to mitigate this issue, or the OS or Browser needs to provide these mitigations instead of the wallets in order to prevent oversharing of information. Otherwise, at least some non-zero number of Users will overshare their information via over-requesting of information.
This is an interesting hypothetical situation, but I don't know any OS or system supports selecting credentials across multiple wallets? That would make for a pretty challenging user experience.
Is this something you've seen in the wild?
Not at this point, but it is an experience I expect to occur even with just mDLs. For example, I expect to maintain my Iowa drivers license for driving in the US. For that I'll need the Iowa Mobile ID App. However, while I'm here in New Zealand I'd need the NZ specific wallet. This is just one case where I'd expect it to occur for mDLs specifically. Might the same issue occur if the user moves from one US state to another as well?
The only expected mitigation I can see to this is to use cross compatible apps like Apple Wallet or Google Wallet which would privilege them above other wallets as the only wallets that can support multiple mDLs.
Additionally, when it comes to other forms of credentials beyond state issued credentials which this API is being designed for, then it's more likely to occur as well.
I'll just add that this is a discussion that has been happening in the DCP working group. I don't think this is in scope for the web platform API.
What is the DCP working group, so I can go read how this is being mitigated by them. If it's not being mitigated by the OS or Wallets working in coordination, it seems the browser would have to be involved. In that case wouldn't it be a responsibility of the API?
What is the DCP working group
https://openid.net/wg/digital-credentials-protocols/
It is not entirely clear what specifically you're trying to mitigate. Is it that you don't want two credential managers to be able to talk to each other? Receive the same request? etc
However, while I'm here in New Zealand I'd need the NZ specific wallet.
is this because you have multiple licenses? Even so, you would only ever present one, right? I've only ever presented the my Australian one, and if living in foreign country one (usually) has to surrender the foreign one after a while... in Canada, it was 6 months. I imagine it's the same if you move from one state to another... one generally doesn't have two or there ins't a valid case, unless one is doing something shady, to present multiple drivers licenses.
Responses for @timcappalli
It is not entirely clear what specifically you're trying to mitigate.
It's outlined fairly well here: https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md#unlinkable-presentations
Wallet A is unable to assist with this if it's not aware Wallet B exists and it has a separate credential.
Responses for @marcoscaceres
is this because you have multiple licenses? Even so, you would only ever present one, right?
In different contexts yes, I would present different credentials, however they would be linkable in nature based on the contents of the claims.
I've only ever presented the my Australian one, and if living in foreign country one (usually) has to surrender the foreign one after a while... in Canada, it was 6 months.
This hasn't been the case for me in NZ and Iowa. In fact, I need to maintain both to be legally allowed to drive within both countries. When I'm in NZ, my Iowa license was only considered legal within the first year. Beyond that point, I needed to go in and get issued a second NZ license so that I could legally drive here. This is just one case where this is valid too and it's focused only on mDLs. This problem applies more broadly though beyond just mDLs or OIDC4VP. In which case it raises the question are we only building this API for particular credentials and particular protocols or is it designed in a credential and protocol agnostic way?
I imagine it's the same if you move from one state to another... one generally doesn't have two or there ins't a valid case, unless one is doing something shady, to present multiple drivers licenses.
This seems like it's making assumptions that don't hold for my case. I just want to be legally able to drive in both countries. In this case, I have legitimate reason for maintaining both. So, then the question comes back to how is the wallet assisting me to make sure the presentations aren't being linked based on the claims?
Sorry, I was not clear. It’s of course perfectly valid to have multiple drivers licenses, as one can have multiple passports (I have two). However, it’s a rare the case where you would present both at the same time.
In those rare cases, one would need to make multiple API calls to retrieve each drivers license or passport. That would solve for not having to present multiple wallets or mixed together for these very exceptional cases (and the origin would be shown as normal, no cross wallet interaction etc.).
I think you're missing my point here though by focusing too much on the solution for a single use case through a careful threading of scope. The reason I generically stated that it's "Wallet X" and "Wallet Y" with "Credential A" and "Credential B" is because this API is not issuer or presentation specific. It's not mDL specific. It's not credential format specific. It's not protocol specific. Therefore, framing this under the assumption that we're designing this API for a limited set of credential formats, or limited sets of wallets or single protocol doesn't solve the problem. If we overly focus on the use case, we lose sight of the forest by focusing on a single tree.
So I guess that leaves me with 2 questions to determine if this problem should be in scope or out of scope:
- Is this API solving for the generic case or only for mDLs with OIDC4VP?
- Do you disagree that this problem persists in the generic case?
If we reference the charter in section 2.1 we specifically stated that "Design and discussion regarding individual credential and assertion formats" is out of scope. Therefore, I think 1 is invalid, so the question comes down to 2 on whether this is in scope or out of scope IMO.
Similarly for point 2, stating that this is solved at a different layer is out of scope as stated in "Interactions with identity wallets". So, I think this has to be solved at the API layer by the browser, or we need to consider rechartering to establish that relying on "integrations of identity wallets" for these mitigations are in scope or structure this Charter around mDLs specifically using OIDC4VP.
EDIT:
Re-reading the charter, it looks like I was citing the old version of the charter. For some reason that's not clear in the commit message, an issue, or the PR it was updated in this commit where that statement of "integration of identity wallets" was removed. I didn't realize that when the council overruled the objection it also brought in modifications to the charter at that time too.
Also, in case you're wondering what types of credentials might be used for presentations outside mDLs, ZkTLS protocols have been designed for issuance of Web Proofs[1][2]. Then the presentation of those credentials can be used for various methods. One such example is to assert in Zero Knowledge a confirmation screen of a payment was sent by a web page over the TLS channel so a user can present proof of the Web Proof to receive cryptocurrency such as a stablecoin in a P2P exchange over the Web.
One such example where a site relies on credentials issued from Web Proofs is with https://zkp2p.xyz. If the payment is split across two credentials (e.g. half sent via Wise and half via Revolut) these would then need to be generated as separate credentials and it's not clear how issuance would force them into the same wallet such that the wallet mitigates this during presentation.