OIDF-automation
commented
1 year ago Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt
A SIOP v2 implementation does not need to reveal a IDP identifier but only the keys managed on behalf of the user. There are circumstances where the verifier needs to know and validate the provider of the SIOP in order to establish trust into its ability to securely manage keys. The currently recommended way for doing so is by requesting a JARM protected response (which would need to include an identifier the verifier can use to resolve/match the key used to sign the response). In the setup you describe, that would result in a user specific, global identifier.
The obvious recommendation would be that the SIOP in the setup you describe does not support this feature. Another way to cope with the challenge would be the SIOP presenting ephemeral/pairwise credentials to proof whatever needs to be proven. We are thinking along those lines for wallet attestation towards credential issuers.
The same risk holds true for OID4VP, however the feature is not as important as in SIOP since trust can be established through the issuer of the credential.
I think the risk associated with this mode should be pointed out in the privacy considerations section of the respective specifications.
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1871
Original Reporter: Nat
In the case of cloud based wallet (aka IdP), not only k-anonymity but pairwise pseudonymity is lost if there is only one user. My IdP is like that.
It probably is worth analysing if similar risk exists for mobile wallets / SIOP.
Whether or not if the risk exists, it a summary of the analysis should go into the Privacy Consideration.
I have marked the component as SIOP but it may also have impacts on OIDC4VP.