User-centricity, Trust: Technology or Practice?

There has been a lot of buzz about user-centric identity but too often it seems to assume that user-centricity is completely dictated by technology. From my perspective as an IT architect, the practices and procedures implemented for a deployment have as much, if not more, influence on how user-centric a solution is and how trusted a solution is.

The term "user centricity" is often used for login and single signon types of systems if the system allows the user to be 'in control' of their identity information and which aspects of their identity are released to other relying party applications. (See my previous post for a few thoughts on when user-centricity is appropriate and when it's not.)

OpenID was designed with user-centricity in mind, and there are some existing OpenID deployments that are user-centric, but there is nothing about the technology itself that forces user-centricity. It would be very easy to deploy an OpenID provider in an organization-centric manner. A corporation could deploy an OpenID provider for its employees for use in authenticating to OpenID-compliant systems. The corporation could pre-create the accounts for users, assign user ids, and populate the user account attributes such as phone number or email address, from a corporate HR source. The OpenID confirmation page, in which a user can alter the user attributes supplied to a particular relying party, could be set to not allow the end user to change the values of their attributes. This would be a very un-user-centric deployment and might be done to prevent users from impersonating another user or claiming undeserved entitlements. So the user-centricity of an OpenID provider depends in large part on the practices and procedures around the OpenID account creation and authentication process.

On the other hand, while there are many organization-centric SAML-based solutions in production around the world, a SAML-based identity provider could easily be deployed in a user-centric fashion if desired. Any organization, or even an individual, could set up a SAML-based identity provider that allowed users to self-register for accounts and self-specify their user attributes and specify which attributes to share with service providers. So a SAML-compliant solution can be set up that is very user-centric. It all depends on the practices and procedures established by the identity provider.

So, how to decide what you need? First, you should decide whether user-centricity is appropriate for your needs, and then you should consider trust.

User-centricity is appropriate for situations where the user is the authoritative source for information - for example whether they're vegetarian. (See previous post) User-centricity is often not appropriate where some organization (such as a corporation or university or government entity) is the authoritative source of information for some of the user's attributes, such as the user's job level within a company, physician status within a hospital, affiliation with a university, or perhaps creditworthiness.

This brings us around to the question of trust. OpenID does not require any contact or setup between a relying party website and an OpenID provider, prior to the time a user logs in. The OpenID model assumes that the relying party is willing to trust any random entity on the internet (chosen by the user) to authenticate the user. This effectively means that the relying party website doesn't particularly care about what practices the OpenID provider
follows in handing out accounts, how reliable the OpenID provider is etc. So this type of scheme is going to be appropriate primarily for low-risk and non-critical sites such as blogs or social networking or sharing photos.

On the other hand, the SAML model assumes some contact between a relying service provider and an identity provider to exchange, out of band, information about the servers at each end of the communication. This means that parties in a SAML environment have some say about who they trust. An office supply website might want to insist that a user making corporate purchases with a P.O. is authenticated by the corporation and not a random identity provider of the user's choice. A medical lab might want to insist that a doctor is authenticated by his or her hospital's identity provider service, and not a random identity service that no one has ever heard of. A university library might want to insist that a visiting scholar is authenticated by the scholar's home university and not a random identity service of the user's choice. The SAML model gives a relying party a way to choose the identity providers they consider trustworthy. It gives an opportunity for the relying parties to ask
the identity provider questions about their practices in setting up accounts, whether they vet any of the user attributes, uptime and reliability etc.

I suppose that someone could customize an OpenID environment to implement a white-list of relying parties that are allowed to use the service and a relying party could implement customization to only allow use of certain OpenID providers. It would also be possible to customize a SAML deployment to allow a relying service provider and an identity provider to automatically register with each other without any human involvement or vetting. (In fact, we did a POC on this for a customer.) Which brings me back to my original point: practices and procedures influence the user-centricity and trustedness of any deployment.

So you should choose between user-centricity and organization-centricity based on whether the user or some organization is an appropriate source for authoritative/trusted information.
The technology choice should be a separate decision and should be based on how much trust is needed for the situation.


This is a good article for learning about the considerations for choosing the identity provider model.

Pondering the alerting systems of HLS (health, emergency response, etc)., there is the problem of volunteer registration. Partner registrations are most likely SAML models. The members organizations (say hospitals) are authoritative over the credentialed contacts provided. Volunteers fall into the middle ground. They are vetted with respect to operational credentials (a doctor must be an MD) but otherwise, the identity credentials they provide on login may or may not be checked. Further, volunteer pages are managed by volunteer teams. The identification rules are murkier here. OpenID providers may be sufficient as long as the information provided is non-secure. This is the nut of the choice: trust depends on the consequences afforded by the norm of identity checking given the information provided to the person logging in.

In long chain systems (think of HLS as real-time services coming on line as needed given a scaling situation), these mixed systems can become unpredictable.

Much to ponder...

Posted by Len Bullard on October 01, 2007 at 12:13 AM PDT #

Post a Comment:
Comments are closed for this entry.

Thoughts on identity management


« July 2016