User Consent

Introduction

The page describes some ways how identity ecosystems might enable and track user consent for compliant sites in a manner that the average user might be able to understand and tolerate.

The Context

The working assumption is that users would like to have more control over how their User Private Information is handled than was possible prior to 2019.

Users are represented on the Internet by User Agents that communicate with relying parties and a variety of Identifier or Attribute providers.

While this example only considers user attributes that are provided by the user or by some Identifier or Attribute Provider, other sources are likely to occur in real-world scenarios.

Expectations of a Good User Consent Experience

1. The user understands exactly what legal entity (and possibly which brand) is represented by the web site.
2. The user gets to select which of their identifiers they which to use with the web site.
3. The user understands what User Private Information is requested by the web site and which specific items are required to do transactions with the web site.
4. The user gets to select which pieces of User Private Information they are willing to share and for what purposes.
5. The user can terminate the relationship with the web site at will and no User Private Information will be used for any new sharing or transactions after the termination.

The Problem

• Users are already operating at, or over, the threshold for cognitive overload and so have only a small amount of attention to allocate to controlling the way that their User Private Information is handled.
• Regulatory and commercial pressures on Web Site to increase user privacy are mounting.
• The economic model of the internet relies on the acquisition of user information in exchange for free services. This fact has worked to block previous efforts at protecting user privacy.

The Solution

A means for capturing and presenting user consent to web sites in a manner that permits the web site to provide proof that user consented to the release of their User Private Information for the purpose is be being used. Alternately the web site can negotiate with the user on the terms and provide the user with a Consent Receipt stating stipulations at that point in time. The current state of the web is recognized as use case 6, Contract of Adhesion.

User recovery and redress is the process by which the user gains access and requests changes to User Private Information held by the Relying Party including the current consent terms. The following are the artifacts that can be collected by a relying party as evidence that user has expressed their intent to provide consent for the relying party to acquire and maintain data about them. In all cases signed artifacts are stronger evidence. These artifacts are here called Stipulations or Claims that are collected in a User Object that is maintained in a store in the Relying Party. The distinction, which is only important to the Relying Party is that Claims are processible into attributes by the Relying Party while Stipulations need not be.

1. Authorization codes to acquire user attributes (claims) for a strictly limited time frame that might expire in minutes or in years. These may be provided by either the user or some Identifier or Attribute provider.
2. Claims are collections of attributes. These may be provided by either the user or some Identifier or Attribute provider.
3. Consent Receipts provided by the Relying Party as evidence of the user's acceptance of a negotiated list of attributes for a specified period of time. These receipts may be overridden or modified by users at any time resulting in an updated or replacement receipt.
4. Notifications from the Relying Party of changes to the status of User Private Information that is not subject to negotiation. This could be the result of other user actions, or of legal actions against the information.

Use Cases for User Consent

These use cases present current states as well as proposed solution which are currently in development.

No	Use Case	Artifact from User	Receipt from RP	Example
1	Get evidence of consent from user	Stipulation created by user	optionally provided by RP	Stipulation has non-repudiation
2	Third Party (like IdP) gets consent from user	AuthZ code and claims created by third party	none	OpenID Connect
3	Direct negotiation between user and RP	none	Required from RP	Kantara Consent Receipt
4	Renegotiate Consent	none	Required from RP	Update or replacement receipt
5	Notify User of Change	none	Required change of status Notification	Some event beyond control of RP
6	Contract of Adhesion	No opt out by user in normal user process flow	RP must give user ability to opt-out	Terms of Use, Privacy Statement

In Case 1 the user receives a request from the RP and creates a stipulation which they sign. That stipulation is sent to the RP for storage. Unlike the Contract of Adhesion (number 6) this could allow the RP proof that the user accepted the request, possibly with additions as included in the stipulation. If helpful the RP could send a receipt accepting the user's stipulation.

In Case 2 the RP provides the user with a list of IdPs that cant be used to authentication the user. (In the case of a trusted framework the RP might accept any IdP which is also part of the framework.) The IdP authenticates the user and provides an authorization code for User Private Information that the RP has requested and the user consented to release. An Attribute Provide will pass that information to the RP as a collections of claims.

In Case 3 the RP provides a web page to the user to negotiate the terms of use of their [[User Private Information by an RP. Once the negotiation is complete the RP will provide the user with a Consent Receipt that details the terms agreed to during the negotiation.

In Case 4 the RP shows or the user navigates to a web page that allows the users to modify the terms that apply to the User Private Information based on new requirements of either the RP or the user.

In Case 5 the RP provides notification that some change to the handling of the User Private Information has occurred as the result of some other action by either the user or some regulatory action.

In Case 6 the RP has a web page with terms of use and with a privacy statement that are claimed by the RP to be in effect whenever their services are used. The level of notification to user varies from RP to RP depending on their sensitivity to privacy concerns. In some cases the user is required to scroll through the terms, particularly when they are considered to be a software license. For the most privacy aware RP the user is expected to acknowledge that they have read and agreed to the terms. The RP may then record internally that the user has accepted the terms and the date that the acceptance was made. It is rare for the RP to save the exact document with the user record, but it is possible that they save a hash tag of the document in the User Object. This use case represents the state of the art on September 1, 2017.

Complexities

No solution will provide all of the features needed for all use cases. The following are some considerations that should be considered by designers and developers of sites that deal with User Private Information.

Delegation

In many cases the user wishes, or courts mandate, that one user act on behalf of another user. In that case several conditions must be met.

1. The guardian (or other agent) must be strongly identifiable, which exposes some of their User Private Information.
2. The subject user may wish to stipulate which information, source or decisions are delegated and for what time period.
3. Some delegations may by their very identification, expose information about the subject. For example if the results of test from a HIV/AIDS clinic are made available by delegation, several paths are opened up for that information to be exposed.

User Experience

Users are accustomed to several options today which should serve as paradigms for future solutions to avoid unexpected user experiences.

• Terms of Service and Privacy Statements are shown on user sites and occasionally positive user acquiescence to them is demanded prior to allowing user access.
• Release of User Private Information by the Relying Party to related entities or third parties is controlled and will likely result is a list of choices for users to pick from. Regulation requires that users have access to change these choices over time.
• Licenses for software or access to resources often requires the user to opt into acceptance of the license and often demand that the user scroll through the license.
• Legal requirements for user notification exist, for example for data breaches or due to other contact or legal events that requirement collection and retention of User Private Information.
• Organizations, such as financial institutions, offer a service to give user notification of specific status changes, which the user is typically able to control.
• Mail sites typically require some sort of user authentication process to change subscription information, which is right, but do not require authentication to unsubscribe, which could block user notification of some actions, but is generally appreciated by users.
• Nearly all web sites provide information to the user when some attribute of their account changes. This gives the user notice and the ability to reject changes that they did not initiate.
• Authentication protocols, such as OpenID Connect, require user consent before any information is released to relying parties. This method improves user security and is becoming increasingly common.
• From a user experience perspective, perhaps the most successful user consent process is provided by the cell phone operating systems that have created categories of access that seem to have just the right level of specificity that they are both understood by the user and effective in limiting access to User Private Information. The phone operating systems are also reasonable about giving the users control to change these permissions for the cell phone apps. While most users are unaware of their ability to change the accesses, at least they do exist.

References and Coordination

Health Care Specific

Emergency Override is required by health care workers in Emergency Rooms or Ambulances that need specific information to save the subject's life.

General References

1. "Consent-Informed Attribute Release (CAR): Serving SAML and OIDC/Oauth" is a slide deck from Ken Klingensmith
2. "Consent-Informed Attribute Release for SAML/OIDC at Scale is a set of notes from a meeting about CAR Tuesday May 2, 2017
3. "Informed Consent APIs is a page linking to a yaml depiction for those who can handle yaml.
4. "Click here to consent forever: Expiry dates for informed consent describes some of the legal issues about informed consent in social media.
5. GDPR Definition: consent of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;