US: user needs to be able to access the registered justification of the relying party

[npdoty]

Description

A user will be presented with a request from a relying party for access to some attributes managed by the digital wallet. The relying party should have already registered (with the Trusted List provider and with the local Data Protection Authority) to indicate for what legitimate purpose and under what conditions it would request attributes from the wallet.

How can the user confirm that the relying party registered? How can the user access the registration in order to understand the justification and conditions under which attributes would be requested?

The ARF draft shows no connection between the Trusted List provider and the wallet.

User Story

User: any user who receives a request from a relying party Goal: the user should be able to confirm that the relying party registered their request and should be able to access that justification before deciding whether to release attributes from the wallet Reason: users will not be able to understand the need for and protection of their data when being asked for attributes. Accountability of relying parties will be very limited if there's no way for a user to access the registration at the time of the request.

[stefan2904]

Is this what Section 7.5 of the ARF is talking about? E.g., the Relying Party Instance certificate discussed in Section 7.5.8.2.

I agree that the justification for the legitimate purpose should be there.

Also, the "technical [RP authorization] measures in the Wallet Instance" mentioned in Section 7.6 are currently not specified.

[stefan2904]

I have two more nitpicking thoughts on this:

• is displaying the registration (RP certificate) to the user enough, or does this end up in the same issues we had with EV certificates in the Web PKI? (For example, an entity's legal name is not enough to be sure that the entity is the one the user assumes, as legal names can be cleverly crafted, etc.). But at least this enables liability in case of misbehaving RPs.
  • is displaying the purpose/justification enough? This cannot ensure whether the respective attributes are legitimately needed in the present use case (an RP might serve multiple use cases with different attribute needs). Obviously, it cannot ensure that the attributes are actually processed in the way stated in the justification (but I guess that would be illegal then).