User recovery and redress

Introduction

The idea that users should have access to any data held about them in the cloud, and to correct data that is wrong, has reached the status of dogma, or accepted truth. This paper tries to understand the user experience associated with achieving these goals in the face of competing desires to limit the amount of data that a user must provide about themselves. The result of this study is meant to provide internet application site designers and developers with the information they need to balance these competing objectives.

Context

The commercial context includes a number of large Identity Providers like Microsoft, Google, Yahoo and Facebook each of which maintains a large email repository and allows unrelated digital entities to avail themselves of authentication services for each identifier in their data base. All except Facebook allow pseudonymous users. All have developed extensive fraud detection and correction procedures based on user's providing more than one means of authentication to their account.

The standards context include those enterprises that have established a repertory of regulations and guidelines that focus on privacy and seek to achieve two sets of goals that create tension amoung designers and developers. These two sets are:

1. Users need to be asked for the minimum amount of data to achieve their goals.
2. Users have the right to learn what data is held about them and correct (or remove) errors.

• An additional concern is false data or behaviors that are attributed (or attributable) to a real human. It is unclear what redress means in that case.
• Another concern of users is that they do not lose access to accounts that contains data to which they posses some sort of access rights, like books or pictures.

The reality for entities trying to conduct their business on the internet is that they are faced with these challenges.

1. Meeting the regulatory requirements imposed by governments, which has become more complex with the introduction of the GDPR and the CCPA.
2. Relying Parties need to reduce their risk of default when providing services to users.
3. Customer Relationship Management (CRM) systems have been deployed in enterprises for decades, most have not be updated to face the reality of the internet.
4. Changing a business model within an enterprise is a hugely expensive proposition. They need to see the business value before they make a change.

This paper is based on the challenges of an enterprise that has already decided to separate the functions of IdP (Identity Provider) and RP (Relying Party). Even if the enterprise decides to host both the IdP and the RP, they have decided to do so in separate functions that require user permission for access to User Private Information in one or more RPs under their control.

Problem

There are a variety of use cases that most of us experience on a steady basis that need to establish as user's ownership of data held within an digital entity:

1. The user loses access to their email account through forgetfulness or hacking.
2. The user starts to create an account and gets a request for more information than they are will to release.
3. The user wants to cancel an account, stop billing for it, and remove all data held about them.
4. The user has signed up for a online account and supplied a credit card. To stop monthly payments the merchant requires a faxed signature form.
5. I called Comcast to cancel my account the other night. They asked for the last 4 of my SSN. They could not cancel the account over the phone without it. So I said that was unacceptable because it violates my threat model. They are likely using Experian to validate this authn authz transaction, I may have to drive out to a service depot.
6. The user wants unauthorized digital entities to neither have access to their personal information nor change their personal information in ways that are detrimental to them.
7. I tried to erase a small error on one (of the three) credit reports. I needed a full SSN and other proof before I could even make that small change.
8. When policy blocks the use of strong internet user identifiers, then the IP address, MAC address or SSN are used to create an identifier that will allow the provisioning of service to a user. This is just a business trying to reduce their risk of default by the user.
9. As federated social signins become increasing popular as serve as authentication for access to an increasingly wide range of activities, loss of access to authentication by the social signin becomes increasingly unpalatable to the user. In fact they become quite irate when access is blocked for even a short period.
10. A pseudonym is created with a real human's physical address and used to send salacious material to the real human. Is it even possible for the real human to force a change to the data associated with that pseudonym?

Designers and developers are uncertain how to build systems that meet different use cases and different user expectations. This is a problem we will need to address if we actually mean what we say about redress and the ability to change information that is held about a user. There seems to be no comprehensive review of the problem. That said, the big IdPs (Microsoft, et al.) do have a fraud units that are accustomed to solving the problem is a practical way when you lose access to your account. It remains to be seem if existing solutions meet the minimum disclosure principle of the IDESG.

Traditional Customer Relationship Managers (CRM)

The solutions that have been built in the past were focused on internet service providers with their own CRM because that is the traditional way that businesses have tried to maintain customer loyalty. Repeat business has always been the way to grow a business and remains so today. The challenge for users is well known, too many passwords and user account names become an unmanageable chore so that business that are not visited on a frequent basis wind up at a serious disadvantage. The move to federated identity from social networks is now at the flood and most businesses that have only occasional usage are likely to offer one or more signins from Yahoo, Google, Facebook, or other common user signin sites.

There are two categories of consumer business that continue to offer their own signins. First are the large online retailers that have been able to keep customers returning sufficiently frequently that the customer accepts the need for a signin that is local to that retailer. Second are the communications oriented providers like cable and phone companies that still are working to maintain customers with email accounts that they manage. While they may work well for users of their email services, the other customers are severely disadvantaged. Since the communications companies are typically monopolies, they are not incentivized to be customer friendly.

The typical pattern of one of these sites is to convince you to sign up for their services, sometimes online, and then make it extremely difficult to cancel the service. Some sites even require a signed cancelation letter by fax or postal service delivery. These communications and other companies that depend on maintaining customer through coercion, like dating and cosmetic sites, are likely to continue to be a thorn in the side of users until regulation changes their behavior patterns. All the IDESG can do is to ensure that our requirement would prevent one of them from acquiring membership in a trusted framework.

This is an old solution that has now become a part of the problem in the sense that changing such a deeply embedded procedure in any enterprise is expensive and fraught with risk of failure.

Solution

There are two broad categories of user access that are sufficiently different to look at them as separate cases: first in the IdP and second in the RP.

IdP Access Solutions

Even in the IdP there are two broad categories that have different characteristics. For convenience they are categorized as: first social signins and second legally binding signins.

Social Signins

The key characteristic of the social signin is user choice. If you don't like your current social network, just create another one, or two and use them in different contexts, perhaps even with different avatars. These typically come with low levels of assurance, but recent addition of FIDO is raising the bar. Since these service are typically provided at no or low cast to the user, the recovery and redress functions are usually highly automated with manned support available only after a purposely difficult preliminary user self-service function. It is the automated process which is addressed here.

Legally Binding Signins

Legally Binding Signins are characterized by lack of user choice. The user must use the proffered service if they want a service which in some cases may be a matter of professional livelihood, or even of life and death. These typically come with higher level of assurance and many require strong identity proofing. because of the legally binding nature of these signins, there is typically a help desk support function to assure continued access and quick denial of access in case of fraud. The capability of the help desk for recovery and redress is typically fully described in formal procedures. In an increasing number of cases a trust framework is established which contains those formal procedures.

The canonical binding signin is enterprise employees who have typically already agreed to sign away their rights. Slowly those right are being restored to employees and other professionals. Future work is needed to flesh out this category as the legal situation becomes clearer.

RP Access Solutions

There are many fine gradations of relying party sites, some the user must chose, other are entirely voluntary, but there is no clear separation that works in all of the many distinctive cases, so they are all lumped in one solution. It is also the case that one relying party may support a multitude of distinct user roles with greatly different levels of assurance as in describe in the Trust Elevation Use Case.

References and Coordination

The description of redress in the Best Practices page has addition information about the use of redress in a real-world system.

There are factors which are pragmatic, and some, if one uses the Internet as the framework introduce all sorts of possible models. The fact is, however, while the Internet protocols and ISO standards allow these things to be done reasonably simply in some countries, the US is an exception. And as a result we pay more than we should.

I really don't care about this but it illustrates hidden costs in delivering at scale services. The benefits are also there, if I add an email address to my account within Comcast it gets provisioned instantly; anywhere in their system. That's why provisioning was the first killer app within the enterprise for directory and identity management.