Identity Management & Roles Based Access Control
Tuesday, September 13, 2005
  Everything's moved!

OK, I decided not to make use of Blogger's services and actually move everything back to my old blog, the one I've been running in one form or another since 1998. I'm still in the process of re-importing all the old posts (so bear with me!), but you can find all these articles and more over at I won't be posting here any more, so on the off-chance you have this bookmarked, please update.
Wednesday, September 07, 2005
  The Most Important Thing in Identity is Trust

After reading through Stephen Downe's opus on Identity, it got me thinking about what the most important part of identity is.

Personally, I think it is Trust.

trust Pronunciation Key (trst)
1. Firm reliance on the integrity, ability, or character of a person or thing.

I think this is the essence. If we take the example of transient identity I espoused in my last post, the key underlying factor that makes the system work is the trusted relationships between entities.

In Stepehen Downe's example (the one that made me think about this in the first place), the key again is trust.

Stephen Says:
To put it in slogan form: when you present your driver's license to the police officer, that's an identity claim. When the police officer compares the photo on the license with your face, that's authentication.
What he's saying is that the police officer places greater trust in the drivers license being accurate than he does in your verbal assertion of who you are.

This even fits with the discussion around claims and assertions of identity. There is no reason why the drivers license you present to the police officer has to be valid, correct, or even accurate - as long as the trust exists between the police officer and the facts contained within the document presented, then the authentication of your assertion will be accepted.

In a personal identity service, it is trust which is most critical.
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.

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.
Thursday, July 21, 2005
  Data Retention and Privacy

My previous post on distributed identity raised another thought, especially about the way Gamespy deal with personally identifiable information (thankfully I never registered my credit card details with them!)

By requiring organisations to record data and information for a lengthy period of time seems to be at odds with a desire for privacy. For example, I really do not want any association with Gamespy, so I requested that all my details be removed from their systems (a request they refused). I can see where a company may not be able to remove details stored on backup systems or stored data tapes, but why can't they delete or remove my details from live systems?

Of course, this issue only really came about because Gamespy was bought by IGN, who them promptly re-enabled my disabled account, allowing access to it again. I only found out by accident that my account had been re-enabled - and I could have theoretically been held responsible for misuse of an account I thought had been deleted.

I can now see the need for trusted identity providers to provide a service where personal information is kept live, but is never stored except for immediate backup purposes, where the nightly backup overwrites the previous night's backup.

I'm sure there's lots of good reasons to keep backups for long periods of time, but frankly I'm worried that my personal details (and credit card details, and home address) could be stored by a company long after I've ceased doing business with them, and that could potentially be used by someone else.

I would much rather my personal identity provider could wipe out my details on request. Maintaining the live data in a system like this would also encourage people to ensure the information is kept up to date.

I'm not even terribly worried about my identity provider's system's crashing or being wiped, since that serves a good purpose anyway in destroying any data about me, giving me the opportunity to correct, update or change the data as and when I need.

But there'd be no audit trail, no way of tracing changes to the account, no way of seeing who made the changes, the first few of which I like a lot, the last of which is a challenge for the service provider.
  Distributed Identity

I've just watched a video interview with Kim Cameron, identity architect at Microsoft. I've been reading his blog for a while (as you can see I have it linked on the right), following the discussion surrounding identity, identity systems, protocols and so on.

There's been a lot of discussion about ensuring that identity remains with the individual, whilst at the same time seemingly tying the source of identity to a device. Robert Scoble, the interviewer, at one point (without a single trace of irony) remarks that he'd like to 'store his personal identity information on Windows, where he knows it will be secure'.

A lot of the examples given revolve around storing identity profiles on a portable device (such as a mobile phone) and handing out different identities for different purposes as and when.

My immediate thought (well, not immediate as it's something I've been cogitating over for a long time now) is why does there need to be a personal relationship between the identity provider and the identity requester in the first place?

Current thinking, especially around federated identity, is that each organisation you do business with needs to hold some information about you, such as a username, password, credit card details, whatever. There are notable exceptions to this, such as the nascent PingID and OpenID, however my favourite is one espoused by Internet2, and being adopted by higher education - Shibboleth.

In essence the idea behind Shibboleth is that the organisation you are dealing with never knows who you are, or anything about you, except that which you release from a trusted identity store. The difference between this model and Microsoft's Infocards or the Liberty Alliance is that these schemes rely on sharing identity information between trusted sources - the federation part - so that your details are available directly to the organisation you are dealing with, whereas Shibboleth allows the individual to specify which identity source to use, which then only replies with specific, limited, non-personally identifying information.

In this scheme I can go to Amazon, attempt to buy something, and instead of logging in to Amazon, I would log in to my own selected trusted identity source (one that Amazon also trusts), which would then tell Amazon 'yes, I know who this person is'. I can then go about my shopping, select what I want, and when it comes time to pay, I can use the same system to select which payment provider to use, again without Amazon ever having to know who I am, having to record any information about me, or store my credit card details in their own servers.

The main reason for this type of system (called the WAYF - Where Are You From - system in Shibboleth) is that it lets me retain one (and only one) copy of personal data, and lets me select how much information to reveal (or how much not to reveal), or even to not reveal any information at all except a confirmation.

Think about it for a moment. If you've ever bought anything online, how many times and to how many different organisations have you given your credit card details? How many of these organisations also have your address so they can deliver your items to you? And how many of these also require you to log in? And have you set a reminder question so you can recover your password? Have you used the same question anywhere else?

Of course you can request your personal information be deleted, although some companies (Gamespy for one) point blank refuse to delete personal information or user accounts, and will only 'disable' the account. (I'm not entirely sure where this leaves issues of liability should the account details be hacked and/or stolen. Someone want to clarify for me?)

Personally I would rather select an identity provider that I trust (and that would delete my details on request) to provide attributed confirmation to remote sites than have to log in directly.
Thursday, June 09, 2005
  LDAP as IdM Core

I came across an interesting article at Security Park about implementing LDAP directories at the heart of an organisation.
Single sign-on (SSO) has long been a holy grail for security teams in large complex organisations. But the obstacles in the way of its universal deployment have so far proved to be too great - in particular the challenge of interfacing and synchronising data held in the various directories that larger companies typically deploy.
You can read the full article here.

Tom speaks on Identity and identity Management.

Kim Cameron's Identity Blog
Digital ID World
(more coming soon...)

June 2005 / July 2005 / September 2005 /

Powered by Blogger