Behavior centric identity management

What's the problem with people knowing my identity attributes, my personal data? Okay, not all data are public, but why should I hide my identity? What personal data should I protect?

I have been thinking about this privacy thing a lot lately. Partly because we have to protect privacy stuff by law. But we protect all information, you might say that all privacy data are protected implicitly if we live by our security policy, right?

The reasoning behind my thoughts is that there are several initiatives to use authentication services like OpenID. And I hesitate. And you know, the problem is that I want to keep my behavior private. That's it, I don't mind third parties knowing me, or part of me, but what I do, that's my business. What I do may lead to some status change of my identity, and that may be publicly known, but my behavior is mine.

We have been exploring some identity aspects and perhaps that we will be able to classify security requirements based on identity aspects.
We learned about Identity DNA, fixed attributes, like name, sexe, date of birth, even Social Security Number. The data elements will (almost) never change. It is so fixed, that it is even public, so why protect the confidentiality aspect?
Next you might talk about Identity Status, information that will change. Like an address, phone number, relationships (even commercial relations, like "customer of", the data that is to be protected because of privacy laws?). Protecting confidentiality might not be needed for all identities by default, but it may be economic to do so.
And then there must be something like Identity Behavior. This must be the most sensitive part of identity data. This is the knowledge part. That's why voting machines are no go right now. That's why financial and medical information are valuable. I want to protect this information. I don't care about my identity DNA, can't change that, but the acts of my identity are personal. Publishing my identity status is my responsibility (I can move, or not, get a new job or not), it's public within the context of my identity, but what I do whit it is my business.

So much for now, perhaps this is way to academic. But at least I got it off my chest.

Community effort

I just like to point to the ibpedia.nl community project, that aims to be a research portal for information security professionals.
The project was started by a few Dutch enthusiasts, who (in vain) tried to use wikipedia for knowledge sharing. Due to the fact that a lot of knowledge was still in research phase, wikipedia could not host the items, so a new wiki was started.

ibpedia got its name form the ib abbreviation: Informatie Beveiliging, Information Security for those who are not familiar with the Dutch language. But, there's also a lot of content in English.

The content of ibpedia is published under a creative commons license, so free to share and add to. Don't hesitate to join the community.

Results from Ian's identity Management survey

Ian Yip posted the results from his earlier survey. Lots of interesting pictures and I am curious about any further analysis.
You can find the results over here.

An IdM survey

For those interested, there's a survey on outsourcing Identity Management. You can find it over here.

RBAC limitations in SOA

For a few years we have been working within a SOA environment and we implemented some form of the RBAC security paradigm. But since a few iterations of our SOA we feel that we arrive at the limits of RBAC. RBAC is fine within a single security domain, like an application, but as soon as you cross your security borders, like you will do in a SOA, you run against problems.

Some RBAC limitations in SOA

• In RBAC you still have to manage every user account and bind these accounts to roles. Unknown accounts can only be linked to a default role, like guest or customer. But users coming in through the Internet channel are not only guests or customers, but they can also be employees, partners, external service providers, you name it. There may be plenty accounts you don't want to manage, because they don’t belong to your security domain. Unless you manage different portals for different roles and have some form of identity management within the portal environment in place, RBAC is of no use.
  Federation could be a solution, but that only limits interaction possibilities to trusted partners you federate with. Besides, most federeation solutions use shadow accounts within the security domains, thereby creating a new identity management problem because all duiplication. Silly, but if you want RBAC, you pay for it…


• RBAC has a problem with the concept of context. If someone has a role, then he will get the permissions associated with that role. Automatically. There is no restriction in place based on the concept of context. A context could be the channel used (internet, lan), time of day, legal entity etc. An account using a wireless home PC might not deserve the same permissions as the same account in an office using a centrally managed workplace. But such a concept does not exist in RBAC terms (unless you define lots of extra roles). RBAC must always be complemented with a rule-based access control function.


• Another big objection (but that is not specifically SOA) is that there is no possibility for user profiling. Meaning authorisation based on the skills of an employees instead of the single fact that the user is connected to a role. RBAC doesn’t know the difference between junior or senior employees within the same role. Unless you define separate roles. And creating duplicate roles is not why you implement RBAC.


• Another problem (also not specifically SOA): role mining. Have you ever tried mining roles? How many roles have you identified? How many unique roles are absolutely necessary? Often mining is an useless excercise. But without mining roles it is hardly possible to define the necessary authorizations. Or is the role the object that you want to manage?

There are more issues, probably, but for us this was sufficient to declare RBAC ‘Old School’. We will continue to apply RBAC for some specific uses, but we will not implement RBAC as a dogma and certainly not within our SOA. We are studying new authorization paradigms, probably using the SAML Claims mechanism.
Identity management will be replaced by identity Provisioning and identity management will no longer be core business for most organizations. Access Control will stay core business, but no longer based on the user part and will also no longer be based on roles.

A Wordle picture of thousand words

Great idea, thanks Kalya:

DigitalMe on ubuntu

A few months ago I tried to get the ubuntu community interested in porting an infocard identity selector to ubuntu. No luck since.

By chance I found out that there is progress on the linux front. A month ago the bandit project published a .deb DigitalMe install package for Ubuntu. You can find it at the digitalme download site.
And yes, it works. The package delivers a painless install of the digitalme identity selector. The package adds a DigitalMe entry in the tools section of the applications menu. You can manage you infocards from within the identity selector.

On the digitalme site you can also find a digitalme firefox add-on.

Identity 2.0 developments

I just learned about the Liberty Identity Assurance Framework project. It seems that there are thoughts about the problem that I described earlier, see my remarks about a trust model for identity providers. The framework consists of an XML schema, that (in fact) describes several standard claims about the use of identity information. You might say, my proposed 'authlevel' and 'authmethod' claims. And the framework states that there is the need for a certification method for websites that deliver identity services.

Problem solved. Or is it? As far as I can see Liberty does mention the certification requirements for identity assurance functions, but I feel that this is not exactly what I wanted, IAF looks like a heavy, perhaps even overweight solution. Pity that there is so little expertise in The Netherlands, or I might have known earlier and perhaps reviewed stuff.

Mike Jones mentions a verified age certification service. This too looks like a promising development. But it demonstrates the problem that I described: who is IDology and what kind of assurance do they provide? Please don't see this as an attack on them, but their verification process is based on accessing public verification information, like name and address. But they don't know me, only the information that I provide, like an address. Unless I'm wrong, this is not enough. The idea of providing assurance for just a limited claimset seems ok, though.
Besides, why should I trust such a third party? It would mean that a service provider/relying party registers IDology on their own 'white list'.

I will look into both developments (there's a lot of information) and report my findings.

Trust model for Identity Providers

A few weeks ago I blogged about the problem of identifying the trust level of an identity provider. See my blogpost earlier. Since, I've been pondering about this problem and discussing it with a few experts.

In PKI the trust problem is solved. There are root-level CA's, who trust eachother by means of cross certification. And that is a heavily secured environment with underpinning contracts, certification schemes and more. Anyway, it means that a certificate holder of one CA, can trust a certificate holder from another CA, even though they don't know eachother.

We can reuse digital identities from one identity provider (be it an OpenId or an Infocard provider), but these digital identities only replace the proprietary userid/password identities at service providers/relying parties. A service provider cannot know if the identity presented is a real or a fake one. Even a 'managed' Infocard has no meaning, because there is no standard way of identifying the real identity. You can't even prove the trust level of an identity provider, leave alone the identities provided.
A service provider could use a white list of trusted IP's, but there goes the openness. Every SP should do it for himself. You could also use federation, but that means making trust agreements between IP's and SP's. But there goes the openness too.

What if we could verify the trust level of an identity provider that we don't know? In that case the identity provider might also provide the trust level of an identity. Was the digital identity proven by means of a official physical passport, or was it only provided through a web form and is the trust level of the digital identity low?

There should be a third party certifying the trust level of Identity Providers. Here's a scenario:

- A user supplies a digitalid to a service provider.
- The SP identifies the IP.
- If the IP is on a certified 'white list' of IP's with a certain trust level, then the digitalid 'inherits' the trustlevel of the IP.

And if the digitalid contains a claim by the IP that the digitalid was provided to a user after validation of an official passport, than you might conclude that the digitalid is correct. The authentication level could be considered High.

So:
- There should be a classification scheme with trust levels (trust high or low, or mayby only just high level IP's)
- There must be a public white list referring Identity providers (and mayby also their trust level)
- We need a 'white list' trust level-protocol that can be used to check the trust level of IP's from a white list provider
- The White list owner needs an accreditation scheme to certify IP trust level (and perhaps we also need an accreditation scheme to certify the 'white list' providers if there are more than just the one white list)
- There should be a standard claimtype that states the authentication level used by the IP (also something like low: no auth, medium: just passport number, high passport presented by subject and a copy archived by the IP).
- There might be a standard claimtype that states the authentication method of the digitalid (also a code like low: userid/password, medium: two factor, high: biometrics)

result:
digitalid by IP1 claims: authclass high, authmethod medium
Check trust level of IP1 (using the trust level protocol)
If the trust level of IP1 is high (it can be found using the trust level protocol), then the IP can be trusted and the digitalid provided by IP1 is valid and can be give the authorisation that belongs to the owner of digitalid.

If the trust level of IP1 is low, of unproven, then the digitalid cannot be trusted, the digitalid should be treated like any userid/password combination.

Perhaps this will mean that a trusted IP can provide several types of trusted digitalids with authlevel low-med-high and authmethod low-med-high at different costs. There must be a business model for this.


Well, I will just keep on dreaming :)
This might be a solution, but I fear that it may take some time and it will cost a lot of money. And perhaps this has already been taken care of. Please let me know.

Trusting cards

A lot of fuss about a claimed hack of Microsoft Cardspace by some German researchers. Microsoft acted quickly and they should, trust is vital. Users have to trust security measures before they use them. And they should understand why and how these measures work.
Glad that the matter of the hack is solved. But there is still the problem of users who are not aware of the why and how.

The Hague Declaration

Andy Updegrove just mentioned this initiative. So being a firm believer in Open Everything, I just signed this petition.

Have a look en feel free to add your name to the form too.

Trust level Identity Providers

I would like my company to use infocard with claims as an identification/authentication method for customers and personnel, even as an authorisation scheme. We are a relying party, mapping claims to user authorisations in our information systems. But what is the level of trust of an infocard that's presented by a user.

In order to verify an on line identity, a relying party will validate the supplied digital identity (infocard) and check claims.
A relying party can distinguish managed cards from self issued cards. That way an IP can identify trusted (managed) identities from untrusted (self issued) identities. These identities in fact obtain the same level of trust as userid's and passwords, very little trust.

But, can a relying party distinguish between identity providers that supply managed cards? I have not yet found information on this matter, still studying. Unless there is a standard 'Identity Provider trust level' definition, every 3rd party IP is alike. Every IP could give out the same claims. But some claims are more valuable than others. Some can be trusted, where others cannot.

If there were a standard 'Identity Provider trust level' definition, such a mechanism should be certified. An Identity Provider could than demand proof of the trust level of identity providers.
Besides there should be several standard claims about the authentication method used at issuing. Face to face, physical passport used, digital passport used. That way we can identify what rights we can assign to a user, based on the trust level of his digital identity and on the authentication method used for presenting the infocard.

We might even become an Identity Provider ourselves, issuing valuable digital identities (infocards of course). But in order to do that, we must know how to make our digital identities standard trusted identities, that cannot be mistaken for digital identities issued by less trusted Identity Providers.

Getting support

I'm trying to get support for adding infocard capabilities within ubuntu. Kim Cameron posts his tippingpoint indicator, showing the number of infocard aware systems (see http://www.identityblog.com/?p=869) and I'd like to add numerous workstations to that number.
Find my postings (user meneer) at http://tinyurl.com/23nrzm


It's hard fighting non believers :)

Online

Here I am, trying to find time to post my thoughts about Identity, internet, access control. Please don't wait for me to blog...