User Private Information: Difference between revisions
Mary Hodder (talk | contribs) (→Introduction: added title) |
Mary Hodder (talk | contribs) (→Introduction: rewrote intention in introduction) |
||
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
Most of the discussion of user authentication is based on NIST Special Publication 800-63-2 and the Levels of Authentication (LOA). (This SP is currently under a review which proposes Identity Assurance Level (IAL) 1, 2 and 3. Both the LOA and IAL and listed below.) This page looks at user authentication from the point of view of the user and | Most of the discussion of user authentication is based on NIST Special Publication 800-63-2 and the Levels of Authentication (LOA). (This SP is currently under a review which proposes Identity Assurance Level (IAL) 1, 2 and 3. Both the LOA and IAL and listed below.) This page looks at user authentication from the point of view of the user and what they understand about their own exposure of personal information in a system. This could be shown through the exhibiting of a user's status through authentication from the user's need to provide the session with authorization to achieve the user's intentions. | ||
The only function of the internet is to move information from one point to another point. The internet protocols structure data and provide context that allows the systems communicating on the internet to infer meaning. It is the action that information has when it moves from one site to another that unlocks the full potential of the internet. This page address the visibility to the user as to the amount of information that a user needs to provide to a relying party (RP) web site to achieve their goals. | The only function of the internet is to move information from one point to another point. The internet protocols structure data and provide context that allows the systems communicating on the internet to infer meaning. It is the action that information has when it moves from one site to another that unlocks the full potential of the internet. This page address the visibility to the user as to the amount of information that a user needs to provide to a relying party (RP) web site to achieve their goals. | ||
Revision as of 17:59, 14 February 2017
Introduction
Most of the discussion of user authentication is based on NIST Special Publication 800-63-2 and the Levels of Authentication (LOA). (This SP is currently under a review which proposes Identity Assurance Level (IAL) 1, 2 and 3. Both the LOA and IAL and listed below.) This page looks at user authentication from the point of view of the user and what they understand about their own exposure of personal information in a system. This could be shown through the exhibiting of a user's status through authentication from the user's need to provide the session with authorization to achieve the user's intentions.
The only function of the internet is to move information from one point to another point. The internet protocols structure data and provide context that allows the systems communicating on the internet to infer meaning. It is the action that information has when it moves from one site to another that unlocks the full potential of the internet. This page address the visibility to the user as to the amount of information that a user needs to provide to a relying party (RP) web site to achieve their goals.
Note that risk status directly addresses the issues of the December 2016 Plenary on the acceptance by the IDESG of NIST SP 800-63-2 assurance levels 4 and 5. Specifically these levels of assurance are claimed to not meet the pseudonymity requirements of the IDEF, but are required for some secure web sites. The appearance of high levels of risk on the web page should help to address these concerns and still allow sites to be IDEF compliant.
Goal
Web sites are more easily transparent about what personal information from users the plan to use and reference.
The cognitive load on the user should be improved by this effort.
Status
This is a proposal to the UX committee on the way to display the current privacy context to the user.
The progress on this topic is tracked on this spreadsheet: "LOAs vs. User Understanding of their exposure to a system".
The Content
The Problem
Users move between privacy contexts on a single display device and are not sure what level of personal information they have agreed to share in the current context.
When to use this Solution
The user is on an internet connected display device using a browser or other HTML display screen. This solution is based on a display to the user by a Relying Party (RP). It is expected that the same values could be used by other entities, like an IdP.
User Identity Privacy Risk Levels
These levels are created specifically to give the user feedback on the risk to their private information.
0=Anonymous
The user provides no information and the RP does not try to link the user by placing cookies or other tracking methods.
Connection identifiers may be used, for example an HTTPS connection always creates an identifier.
1=Pseudonymous
The user provides or permits some identifier that can be reused over time to link a continued presence. The RP does not try to link the user to a human. The user implicitly intends to assert DO NOT TRACK.
IAL 1 = LOA 1 or 2 if provided by the user. Note that the identifier may be supplied by the RP.
2=Weakly Authenticated
The user provides or permits an identifier that may be linked from one site to another under limited conditions permitted by the user expressed intent.
IAL 1 = LOA 1 or 2 if provided by the user. Note that the identifier may be supplied by the RP.
3=Strongly Authenticated
The RP has some specific requirement to know the identity of the user, such a KYC regulations for a bank.
IAL 2 = LOA 3
4=User Identity Proofed in Person
The user has some legal obligation to be well-known to the system in order to be authorized to perform their duties. The user will have some physical authentication factor like a CAC or PIV card.
IAL 3 = LOA 4
References and Coordination
TFTM committee has indicated that privacy indication is not part of their current work effort, which is focused on the IDEF and supporting documents. As they begin to address other ecosystems in the future, this risk indicator may be helpful in reducing the number of ecosystems that are required to support user experiences.
Privacy committee is directly involved in this concept and their feedback should be solicited as soon as the UXC is comfortable soliciting outside feedback.