Claims and white lists

Since there's no trust hierarchy for identity providers yet, some other mechanism should be developed to be able to trust third party identity providers. At least if we want to be able to use identity information within the digital identity, the digital passport, to act on. As long as a digital identity is used instead of userid and password, there is no problem. Any digital identity used on a site is as good as a self managed identity and password. But if a digital identity is used in a transactional way or if someone wants to access confdential information, some trust in the reliability of the digital identity of a user is needed to be able to control access.

As long as there's no structural solution for trust hierarchy in identity space, white listing is the answer. In a white list a service provider could state which identity provider's identities can be trusted. But that's just the first step.

The second step is that a service provider could allow the use of claims defined by the white listed identity provider. The service provider might accept specific claims issues by a specific identity provider.

In an earlier post I wrote that we would need only a few standard claims to be able to identify the value of a digital identity. What's needed is the level of verification of the identity by the identity provider and the authentication method. If these two claims would be standardised across identity providers and service providers, we would only have to whitelist an identity provider to be able to differentiate user authorizations based on the value of the digital identity.

Yesterday there was an interesting meeting of some potential Dutch OpenID relying parties and OpenID identity providers.
I will participate in a working group to explore the possibilities of standardising claims and trust level of identity providers. That second part is the tough one, it will require some form of accreditation. But if this works for OpenID, it will also work for Information Cards, of course.

Let's review too

Mike jones reported the availability of the Identity Metasystem Interoperability Version 1.0. This looks good news to me, progress being made, so all hands on deck for reviewing.

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.

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.