Identity Management & Roles Based Access Control
Friday, September 02, 2005
  Transient Identity

2 September: This is a work in progress, so please ignore typos or blank bits :)
Update 6 September: It seems other people are travelling down this path: Check out this paper from midentity, as well as this post (part 1) and this post by Stephen Downes.


I've been thinking about this for a while. Posts by Kim Cameron and more recently by Bob Blakley talking about digital identity lead me to the topic of this post: Transient Identity.

In my previous entry I talked about data retention and privacy have led me further along this path. Coupled with initiatives like OpenID and Shibboleth, the concept of transient identity comes in to play when the ownership of personal identity is transferred back to the individual.

At the moment I have personal details about myself stored in hundreds of places on the web such as web shops (I won't mention them - wouldn't want anyone going trawling!) and other organisations I have an involvement with. Each one of these companies holds a copy of information about me, that I provided at the time.

This information, which is used to identify me to them, is fixed at a single point in time - the last time I edited the information they store about me (or the last time they edited information about me without my knowledge...) In the worst case scenario (as mentioned in this Wired article), the information stored about you may be entirely inaccurate. And all of this information, most of which you have no control over, is used by other people to make decisions about you, or to identify you.

So what do I think is "transient identity"? At its most effective, it is a situation where my chosen identity provider loses all my information and cannot restore it if they have a system, crash. Nothing is stored in long-term storage, nothing is backed up to tape, disk or other storage medium. When companies I deal with request my identity, they receive only that which they need to use for the individual transaction, and this information is requested from my chosen identity provider, not recorded locally.

Shibboleth espouses the idea of attributes for authorisation rather than credential sharing, leaving the actual authorisation process to a single trusted provider. For example, say you're dealing with Amazon. When you want to buy something, you don't log in to Amazon, you log in to your own chosen identity provider, who tells Amazon that you have successfully authenticated against their known information.

When you come to buy something, Amazon asks your identity provider for your current postal address (a release of identity information transaction you have necessarily authorised), which Amazon then uses to send you your parcel.

However, given that the information provided is transient, there is no benefit for Amazon to retain this address information for later use - as you may have moved, or changed where you want parcels delivered.

This can even be extended as far as purchasing. The payment for your book could be processed remotely. As a buyer you could authorise Amazon to request a payment from your account. Your identity provider would then initiate the payment (which you would then authorise separately from Amazon itself, or automatically if you chose to accept all payment requests from Amazon), then your identity provider returns confirmation of payment to Amazon.

You get your book delivered where you want, Amazon gets it's money, and you keep control of your personal information.

Sticking with payments for a moment, have you ever stopped to wonder how interesting the breakdown of credit card usage on a site like Amazon could be to marketing companies - or even the credit card providers themselves? They wouldn't even need to know who has them or where, but simple breakdowns of 'x number of Visa cards are used in this state as opposed to y number of Mastercards' could be used by providers to plan wide spread marketing campaigns.

So back to transient identity, and let's map them against the Laws of Identity.
1. User Control and Consent:
Well, the whole point of transient identity is that the owner of the identity is in complete control, not only of what data is held, but what data is released and how it is used.

2. Limited Disclosure for Limited Use
See the Amazon example above. Using an attributes-based system like Shibboleth means that you only provide the minimum amount of information needed to complete the identity transaction.

3. The Law of Fewest Parties
See the Amazon example above. All identity comes from a single place.

4. Directed Identity
By integrating a Shibboleth-style attributes delivery service, the identity owner can define up front which information or attributes can be requested or used by anyone without authorisation, and which are private and can therefore only be used with explicit permission.

5. Pluralism of Operators and Technologies:
Well, this is a challenge for companies who want to be digital identity providers. For transient identity systems to work, there needs to be an agreement between identity providers and identity consumers that the information shared is trusted. But there's no reason to specify what sort of identity storage system is used by an identity provider and what sort of processing systems are used by an identity consumer.

6. Human Integration:
Well.... the whole point of transient identity is that the human who's identity is being defined is in complete control of all the information stored and revealed about them.

7. Consistent Experience Across Contexts:
Perhaps the least understood of the 7 laws, transient identity has the ability to provide a consistent experience across contexts - since the identity owner defines what is provided in each context, however the decision on how to present the experience of using the identity at a consumer/customer level is down to the Identity Consumer (Amazon from the example I've been using).

I guess what I need now is a definition of 'Identity Provider', 'Identity Owner' and 'Identity Consumer'? Because strictly speaking, an 'Identity Provider' can (and perhaps should?) also be an 'Identity Consumer', consuming identity information released by the 'Identity Owner' that it retrieves from itself.

Just quickly:
Identity Provider: An organisation or company that provides a secure way of assuring provided credentials are correct, and providing selected subsets of authorised attribute information about an Identity. Also asserts that the Identity information stored and provided has been entered by an asserted Identity Owner.

Identity Consumer: An organisation that makes use of provided Identity information in whatever form is needed or delivered.

Identity Owner: An individual, responsible for providing self-asserted Identity information to an Identity Provider.

Problems
No type of identity system is without problems, and the problems with transient identity are the obvious ones: data retention, data quality, trust between provider/consumer, identity theft, data loss

Interestingly, some of these are easily overcome. Taking on the role of Identity Provider comes with a lot of potential problems, technical and otherwise. However the actual implementation of the service is a purely technical and process issue, and is not actually related to identity at all. For example, setting up to be a primary provider of someone’s digital identity requires that the provider know who the individual is. This is not a digital identity issue, this is a personal identity issue and can be dealt with the same as any other secure identity issue: Get the person to provide non-digital identity information, and require it for every change. Banks do this every day.

Once you're over this hurdle, providing secure access to the services to make changes to provided information is simple, and again is something done every day using SSL certificates or strong authentication. Setting the service up to handle changes in a secure way is also fairly simple, and examples can be an exercise for the reader :) (However, don't take the example of my business banking provider: They require I use a username and password as well as a security certificate to access online banking. Once logged in, I can do lots of things, including clearing out the account. But I can't change my postal address for statements. My personal banking service requires a username, password and security code. And I can change my postal address online. I'm still gob smacked that the stronger authentication process provides me with less options to change data...)

So let's hit some of the other problems on the head:
Data Quality
Well, the owner of the identity information is entirely responsible for the quality of the data used by everyone else, so data quality problems should not exist - unless the identity owner chooses to give false information. Which then becomes a law enforcement issue if false information is deliberately provided, and not an identity issue.

Data Retention
We don't want data retention. We want our data to be lost if there's a system crash. We don't want old data inadvertently used without our knowledge - or deliberately.

The only other real issue here is with legislative requirements. In the UK information must be stored for up to 7 years, so there could be some legislative issues around whether or not an identity provider could exist if they didn't back up their data. After all, in the strictest sense the identity provider itself would be a consumer of identity information about their own customers - there would not need to be a separate 'customer database' of people who purchased identity storage.

Perhaps a re-drafting of data protection & retention legislation is required?

Data Loss
Data loss will always be an issue, but if you are in complete control of all the information stored about you, data loss is not actually a problem, it's a benefit, since you know that all the information stored about you has been provided by you, rather than derived from other organisations or from old data.

Identity Theft
Identity Theft is always going to be a problem. After all, it's it's been around for centuries. How it's dealt with is not an identity issue, it's a functional or operational issue. However if all your identity is provided by a single trusted provider, then you control how that information is used, even to the point of where it can be used. If you want to protect your identity details, disallow changes to certain types of information online, and disallow certain transactions.

Trust between Identity Provider/Identity Consumer
This is not an identity issue, this is a marketing/business development issue. And there is great incentive for an identity provision company to provide secure services, accurate services that other companies trust, as this is their primary market. If you can't do a deal with Amazon, then you're unlikely to get many customers...

The Amazon Example
The above image illustrates the information flow in the Amazon example I gave earlier. The interesting thing about this diagram is there is no relationship at all between Amazon and the consumer, and there is no relationship between Amazon and the credit card provider. The entire transaction is carried out using attributes or assertions about the customer, not by the customer providing details to Amazon.

A small side effect of this is that it makes it very hard to conduct credit card fraud through online stores - since there's no actual relationship between the online store and the credit card itself, simply assertions made between the two parties by a trusted intermediary.
 
Comments:
Hi i am totally blown away with the blogs people have created its so much fun to read alot of good info and you have also one of the best blogs !! Have some time check my link of protection against identity theft.
 
Hey, you have a great blog here! I'm definitely going to bookmark you!

I have a credit cards for bad credit site/blog. It pretty much covers credit cards for bad credit related stuff.

Come and check it out if you get time :-)
 
Post a Comment

<< Home

About
Tom speaks on Identity and identity Management.

Links
UoS IdM PoC
Kim Cameron's Identity Blog
Digital ID World
(more coming soon...)

Archive
June 2005 / July 2005 / September 2005 /


Powered by Blogger