Privacy facilitated by User Agent Use Case

Title: Privacy facilitated by User Agent A User Agent can manage multiple identities or personas, personal data, user-submitted terms of use about the use of a user's data, and is located on something the user owns, such as a device -- phone, laptop, tablet -- or on a server or in a personal cloud. The User Agent belongs to the user.

Use Case Description: Establish an identity with a relying party that releases only information explicitly authorized by an individual user.

Use Case Category: Privacy, Trust/Assurance, Interoperability

Contributor: Tom Jones

Use Case Details

Actors:

• Relying party (RP) is typically a web service that requires user identity or attribute information to complete a digital transaction.
• Identity Provider (IdP) contains identities and attributes of users.
• User Agent (UA) is a process that assembles a collection of user identities and attributes to be transmitted to an RP in accordance with user intent.
• Registration Authority (RA) is a service that can register other actors.
• Individual user in this case is a carbon-based life form that wants to access a web site on the internet. We not consider the case of other user types in this document.
• Device is a gateway between an individual user and the internet. The simplest UA is just a device that transmits information from the user to the RP.

Goals:

1. Compliance with regulations for RPs and IdPs.
2. Common method for reliably describing and reporting an individual user’s intent.
3. High comfort level for users that they can selectively share information.

Assumptions:

1. The RP has a relatively clear privacy compliance regulation to follow.
2. It is possible for an RA to reliably report to an RP that a UA is trusted to reliable convey user identities and attributes only in accordance with user intent.

Requirements:

1. Individual users have access to a digital device upon which they can depend to reliably represent their intent in a common digital format.
2. Registration Authorities exist and have a common protocol and taxonomy to report on UAs to RPs.

Process Flow:

1. The user establishes an account with one or more IdPs. In this use case there is no need to distinguish between identity providers and other attribute providers.
2. The user access a web site which requires identity attributes of some sort to continue to process the user request. They then become a relying party.
3. The RP uses a standard protocol and taxonomy to request the information needed from the user.
4. This request for information is intercepted by an agent for the user that can:
   1. Determine if the information is available
   2. Determine if the user has already authorized release to this RP
   3. Display any remaining choices to the user to acquire more attributes or release those already available.
   4. Format the response in a way the RP can evaluate the data
   5. Send the response to the RP who has sole responsibility to determine if sufficient identity has been proved to provide the request access.
   6. Repeat these steps till the RP is satisfied or one side gives up.

Success Scenario:

1. Modern devices in common use for connecting users to the internet now come with a root of trust that can be used to report on the health of the device.
2. User agents are created on a user’s device or in the cloud that can be audited to assure that they report only identity and attribute information the user wishes to release.
3. A small common taxonomy of user private data is established so that RPs can request information, and users can understand what information has been requested. This model works now for smart phones releasing user data to the internet because a small taxonomy of user information is reported. If the list grows long, the user experience is known to suffer as the display becomes too long for users to quickly scan before they assent. In no case should a user ever be asked for more types of information than can be displayed on a single screen with the acceptance button.
4. The success metric should be that users are shown to be able to make intelligent choices and make informed determination.
5. User choices are collected by the user agent so that if the same information has been requested by the same RP in the past, the user is not continually bothered with the same questions.

Error Conditions:

1. User does not have the credentials required by the relying party. Mitigation: the relying party redirects the user to one or more sources of appropriate credentials.
2. The device or user agent loses the trust of the RA and hence of the RP. Mitigation: the user must be given actionable steps to get their agents back in compliance. It should never be the case that an “unauthorized” message be passed to the user with no remediation action indicated.

Relationships

• Extended by:
• Extension of: