...
Number | Section, if applicable (overall comments also welcome) | Current Text if applicable (overall comments also welcome) | Proposed Text / Query / Suggestion | Proposer | +1 (add your name here if you agree with the proposal) | ||
|---|---|---|---|---|---|---|---|
| 1 | 9.3 in 63C | Data Minimization | Providing insufficient attributes may impact the functionality of the application. If the RP can identify which attributes are needed for which functions, it will help a user determine what to release. | Ken Klingenstein | |||
| 2 | 9.3 in 63C | Data minimization for portals is particularly vexing. Guidance on how to do this would be helpful. | Ken Klingenstein | Brett Bieber | |||
| 3 | 10.1.1 in 63C | Provide users means to delete their identities completely, removing all information about the user, to include transaction history. | There are often legal or audit reasons to not delete transaction histories. | Ken Klingenstein | Brett Bieber | ||
| 4 | 10.2.1 in 63C and 9 in 63A | Neither section appears to offer guidance on the translation of technical attribute names and values into user-friendly language. | Ken Klingenstein | ||||
| 5 | 10.1 | It might help to qualify what is meant by minimizing user actions. While I think this is a worthy goal overall, we have struggled on CAR with a temptation to minimize user actions in ways that allow important concepts and information to be glossed over. Happy to show examples where we chose not to minimize user actions if it would help foster a discussion. The link to Account Chooser isn't formatted so as to be clickable. I did navigate to http://openid.net/wg/ac/ but didn't get very far because the title of the page (and working group) uses the word "login" incorrectly, which (especially in the IAM space) I find very distracting. Used as a verb, it should be "you only log in once", not "you only login once". | Mary McKee, Duke | ||||
| 6 | 10.1.1 | The suggestion to "provide users with the ability to easily verify, view and update attributes" is (perhaps deliberately) ambiguous about whether this function needs to be part of the context in which the attributes are being shown and/or released.
For CAR, we've determined that it's counter to the primary goal of facilitating authentication to invite submissions of updated values at the time of an attribute release decision. | Expanding the range of decisions from simple "yes/no" or "permit/deny" from current values to anything a user might choose to release (especially when the user may be an acceptable authority for values of some attributes but not others) adds (in our determination) an unacceptable amount of cognitive load on the user during a time-sensitive transaction.
"Provide users means to delete their identities completely, removing all information about the user, to include transaction history." - I'm not sure if I disagree with this from a philosophical standpoint, but it's hard to even consider given how unlikely it is that we could support this at Duke as written. Audit requirements will make this a non-starter in many areas, and I hate to think that "we can't do this fully" might translate to "we can't improve the status quo".
Speaking for CAR: I would personally advocate for the ability to deactivate undesired policies in CAR. The ability to completely remove a policy is something we should discuss and form a position on - is auditing more important than user privacy?
Speaking for Duke as a resource holder: I think we could improve by giving users more visibility into our (deliberately short) history retention policies, but I would not advocate for the ability for a user to be able to wipe his/her history within that window. I would also support users having visibility into what parts of his/her identity could be redacted, but would not support user-initiated deletion of an identity. Credentials are another story - personally, I'm of the opinion that users should have complete latitude to destroy those if undesired (though based on some InCommon expectations like EPPN not being re-usable, we'd still have to track of the fact that some electronic credentials existed). 7
| Mary McKee, Duke | |||
| 7 | 10.1.3 | Just another grammar nitpick: in the penultimate sentence in last bullet point, "logout" is used as a verb. The use of "logout" in the last sentence is fine. | Mary McKee, Duke | ||||
| 8 |
See also