User Private Information

From IDESG Wiki
Revision as of 17:52, 14 February 2017 by Mary Hodder (talk | contribs) (→‎Introduction: added title)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 so will exhibit the status of authentication from the view of the information that the user needs to provide for the session to be authorized to achieve the users 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.