| IA Information
| Description
| Acceptable
| Not Acceptable
|
| Phishing defense
| IA must be able to detect whether this is first or subsequent visit to an RP.
| Signal to user on first visit must be distinguishable from what the user sees on subsequent visits. The object of the game here is to make the signal so blatant that the user will terminate the login process if the signal says first visit but she already has an account at the RP.
| What user sees is "very similar" between the first/subsequent visit cases. For instance, all they're shown is which cards match the claims policy of the RP.
|
| IA management
| (NI) Management of a user's information card storage for purposes of acquiring new ones, deleting undesired ones, auditing their usage, and so forth.
| Card management can be launched and performed without contacting a relying party. It's not even obvious the what the user interacts with to manage her cards would be the same as the identity selector that she sees when logging into a relying party.
| Relying party must be contacted to interact with IA.
|
| Information about intended RP
| (NI ?) In panel to select and send card, information about intended RP is shown to user.
| RP information (either text of logo) must be shown and must match what user asked for (typed in).
| RP information does not match what user typed in.
|
