That was the EIC16 that was

Each year, the German security consultancy firm KuppingerCole in Munich is organizing a multi-day conference on the theme of identity and access management.

The KC conference was well organized. Nice location for both sessions and the inevitable vendor marketplace. Lovely brochures, event app, fine catering and a lot of famous people. We'll get back to that later. KC is a large company, has many expert analysts and these are actively present. They moderate panels, are chairing different tracks and give presentations.

The conference lasts three days, long days ... the first keynote generally starts at half past eight and the day closing somewhere between 19 and 20. But that's not all, there are also pre- and post-conference workshops. I decided to join a preconf day this year, namely the workshop on the theme blockchain. I cannot give a full overview of the conference, but I will point to a few highlights.

The hype of this moment is Blockchain. The pre-conference workshop lasted a whole day and treated the backgrounds and ideas around Blockchain and also bitcoin. Also on the third day there was extensive attention given to blockchain in one of the four parallel tracks. Briefly: Blockchain is a promising technology (immutable storage of transactions, transparent, fast and cheap), but so far it’s little used (not really an anonymous platform, ‘bitcoin image’ is not very positive). But biggest problem is the issue of trust. Can you trust the blockchain, do you trust the longevity and continuity? But the advice is: go play with it, within a year or three there are business cases and apps to make use of blockchain technology.

Second hype: CIAM, customer Identity & Access Management. And yet, actually not quite a hype, we have already know,  implement and use it. More importantly is the underlying mechanism, namely federation.

More or less the same applies to IoT and Big Data. These developments also look at federated solutions to preserve both the business benefits and guarantees regarding privacy.

Federation was not only reflected in many presentations. There was a separate track in which the OpenID Foundation presented the many developments. Of course there was OpenID Connect (yes, we really should implement this as often and as broad as possible) and OIX (OpenId Exchange, it so looks like the implementation of what I wished for in my old blogs - http://id-use.blogspot.com/2008/06/trust-model-for-identity-providers.html ), but also a number of working groups on the themes of health (the OpenID Heart working group led by Eve Maler of Forgerock) and the Financial Services API WG.

But not everything topic at EIC16 was about IAM technology, unquestionable the most impressive presentation was by Mia Harbitz of the World Bank. She described identity management in a world where a birth certificate is already a challenge. Children with a birth certificate get a vaccination three times as often as children without a birth certificate. She had more shocking numbers of people without a formal identity, without access to life saving services because of it.

Providing an identity to refugees is also a hot topic (especially in Germany, with 800,000 refugees in the past year). This was discussed in a separate track with an interesting panel discussion. It soon turned out that we give refugees an identity because we want to avoid them actually abusing the services paid by us. Not because we want to offer our refugees just enough identity to survive. Sad really ...

An interesting development was an initiative by Ian Glazer (Salesforce). He and Kantara (for example known for User Managed Access – we should make this a default way of customer access control) took the initiative to investigate whether the Identity professionals can unite. The "Keepers of Identity" are increasingly more import, cooperation is essential. More info: https://kantarainitiative.org/digital_identity_professional/

And for those of us who are in despair… there are still use cases for on premise use of Active Directory. Kim Cameron (Microsoft) sees a shift to Azure AD, but an on premise AD will still remain for the coming years.

These were intense days. I finally met with many digital friends. And I advise you to look up the hashtag #eic16 on twitter. Lots of nice tweets, many photos and video’s and links to interesting articles.

And do yourself a pleasure and visit the blog of my good friend Alessandro Festa...

No business case for Identity Providers (part 3)

Would I like to be an identity provider?
Well, of course. I would make sure that my identities were very reliable and reusable. My identities must be trusted in order to make them reusable by different service providers, the government, banks and other websites. This, of course, requires the use of open standards and an auditable governance and trust framework. To achieve this, I need a business model, because someone has to pay for all this. In my opinion there are several models:

• The citizen/customer pays for his digital identity
• The citizen/customer gets a digital identity for free, no costs
• We license a trust framework

$Identity

Anyone requiring a digital identity by a trustworhy Identity Provider needs to pay for the use of the digital identity. The question is if I, as a consumer, would be willing to pay for a digital identity. If I can't use the identity, I don't want to pay for it: 'What's in it for me?'. This model requires a convincing story: as a consumer I need the assurance of the reuse potential.

If I were an identity provider, would you pay for my digital identity if I could guarantee reuse? If so, how much? That's difficult to calculate. There are many costs attached to running a trustworthy identity management system. Most of theses costs are fixed costs. The more identities I can sell, the lower the management and security costs per identity and thus the lower the price of a digital identity. How about $20 for every identity? And with a periodic renewal every 2 years? Because identities erode.

Zero$ identities

There are different variants of this model.

1) Like I mentioned in an earlier post, the Dutch DigiD is an example of a trustworthy free identity. The identity is free, the costs of the identity are made up for by the identity provider. Because of the use of DigiD, Dutch citizens can perform a lot of G-C transactions online, data entry is moved from the civil service to the citizen. The disadvantage of this model is that the reuse potential is low. The identity can only be used at a fw service provider within the trust framework, like local government and a limited number of legally appointed third parties.

2) Another instance of this model is a company that pays for the costs of identity management and provisioning for it's own customers. Just like the mentioned Digid case, but with a larger reuse objective. All parties in the trust framework abide by the rules of the trust framework and guarantee the conformance to the rules. This means that there should be auditable quality and trust criteria, resulting in some kind of a seal of approval... It looks a lot like the OpenID+ model I wrote about in a previous post.

An identity that can be used often, has a higher value that an identity without reuse potential, hence an identity provider with high reuse value identities will have a better reputation and may be willing to invest in this identity provisioning service. What will this cost? The trust framework will be expensive, so the costs of such an identity will be higher than the costs of the first model, let's say $50 per identity. Investments with a positive Return on Investment, even more if the service will result in frequent customer contact as well, for instance because of periodic renewal of the identity.

Commercial providers of free identities like Facebook, Twitter and LinkedIn, implement this model in some way. The reuse potential of this model is moderate to low, because of the lack of a Trust Framework. Only service providers within the trust framework of the identity provider (think of Blogspot, that enables you to use your Gmail account to logon) offer the reuse potential. Other SP's, who don't require trust, but who just rely on the identification and authentication of a customer, may allow the use of a free account.

What is the business case for identity provisioning for these commercial IdP's? They offer a free digital ID, but who is paying for it? Because when using it, by logging in using open protocols like Oauth, there is no transaction fee for authentication. This is an interesting question. These IdP's seem to gain a lot of money by managing your digital ID in a different way. Managing and securing identities is costly, but their business model has an enormous ROI because of the services they offer by analysing the value of your identity, your profile. Your behavior is valuable…

Is such an identity a good match for all purposes? Obviously not. there is no trust in your digital ID, because, no matter what 'real name' policy, the IdP doesn't really know you, it only knows your profile. And the provider knows every service provider you use, based on your logon.

You could upgrade the value of an untrusted digital ID, by using a third party verification schema. For instance upgrade your twitter account by having it validated by another trust framwork. This of course creates a larger reuse potential (in the other trust framework) with your simple logon feature. But of course, someone will have to pay for the added trust by verification in a third party trust framework. There's no free lunch...

3) The third instance of this model is that an identity provider gives out free identities, but makes service providers, who trust the identity, pay the fee. That could be based on a per per use fee, or in a subscription kind of fee. This creates a high reuse potential, within this trust framework. In this way the service provider doesn't have to pay all costs for identity provisioning, thereby saving a lot of money and limiting compliance risks – if you don't manage identity data, you can't lose them… How much should this cost? Hard to say, but I think that $0.10 per reliable authentication could well be feasible. Or a subscription fee of, let's say, $10 per customer per year?

For IdP's there is a real incentive to create as much reuse potential as possible. The more often an identity is used, the higher the profit. But reuse potential is a result of reliability and reputation, Identity Provisioning is an expensive business model. And if a digital identity is not used often enough, this will result in a financial loss.

Last model...

Let's just create a trust framework and have anyone use it. Both identity providers and service providers pay a license fee and can start using it. The trust framework guarantees reuse and every party can decide their own business model (I wrote about this long ago...). But the trust framework has to be developed, managed and monitored, according to open standards and governed by legal standards. But someone has to pay for this model too. And there is an example, OIXby the Open Identity Foundation.

Lingering business case problems...

There are some other problems for identity providers and service providers. From the business case the main driver for profit is the reuse potential of digital identities. Only if there is any reuse capability, operating an IdP can be affordable. When not, there is no business case. If an identity cannot be reused, it may well be too expensive for the customer, the IdP or the SP.

But there is a strange oxymoron… The better the reuse potential, the less I am inclined to use other identities, the one with the best reuse potential will be my preferred ID. This means that I don't need another IDP. And same is true for other consumers as well. This means that there is limited room for other IDP's. (I know, you may want to use more than one identity, but that's out of scope for this post :) )

Is there a business case for IdP's?

No trust framework, no reuse. No reuse no business case. No business case no digital identities. No digital identities, no trust framework. No trust framework, no reuse, no business case.

I may want to be an Identity Provider, but I don't believe that there is a business case, unless you manage to be  the same league as facebook and friends...



(based on my Dutch language post https://www.cqure.nl/kennisplatform/digidem-4-het-opbrengstenmodel)

Stork and other assurance frameworks

As I wrote earlier am involved in the Dutch OpenID.nl+ initiative to help grow the acceptance of OpenID (and to a lesser degree Information Card) in The Netherlands. Within the initiative Identity Providers and Relying Parties define an interoperability standard whereby Relying Parties can rely on digital identities from Identity Providers, based on the verification level of identity attributes by the participating Identity Providers. RP's can authorize users based on the verification information in the claims.

The Trust Framework is based on the assumption that trust derives from the reliability of the identity provider (including the reliability of the identity priovisioning process) and from the reliability of the use of a digital identity. Meaning that there are two parameters: trust in the identity as verified by the identity provider and trust in the use of an identity by the individual owning a digital identity (proof of posession). IdP's must adhere to a certification scheme to prove their reliability. The OpenID.nl+ initiative manages the white list with trusted IdP's.


International developments like STORK also define authentication assurance levels, but these levels are a combination of Identification (by the IdP) and the method of authentication (by the user, based on proof of identity). These assurance levels are the product of a mix of both parameters.


The strange issue is that for certain levels a low level of trust in the process can be compensated by using a strong form of authentication. So QAA2 can be the result of accepting an identity that's hardly verified by an identity provider, but requiring a one time password. Strangely, that would mean that the IdP may not fully know the individual who is issued a digital identity, but you know for sure that the user of the digital identity is the rightful owner of the identity. So someone logging in as Mickey Duck may not really be Mickey Duck, but he is the rightful owner of Mickey Duck's digital id.

In the OpenID.nl+ initiative the net effect may be the same, for most combinations, but the vision on trust is more distinct, the implementation offers a lot more granularity (because of the trust model), although implementing this granularity is not yet part of the roadmap.
In my opinion you shouldn't require a combined assurence level, but you should demand a certain level of trust in ownership of a digital identity and the use of a digital identity.

I will probably get this al wrong, since this model is widely accepted, but then again, maybe I'm not.

Open Trust Frameworks for Open Government

As I wrote earlier, the biggest problem in the identity 2.0 space is the absence of trustworthy public Identity Providers. I called for a trust framework that would enable differentiation in trust levels for identity providers. Of course that requires some major party to define the standards.
There is some great news about the development of a standard trust framework for identity providers. Initiated by the US Government the Open Trust Framework for Open Government was formed. In a White Paper the methods are described.

There are other initiatives, like the Dutch OpenIDPlus. Let's just hope that these initiatives will converge into an interoperable international standard.

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.

myOneLogin ad

I just read one big ad (dressed as an article) for the myOneLogin service. It is some kind of identity broker, directed at enterprises and SMB's, facilitating single sign-on for cloud applications. It's a $3/month per user service that might replace the use of OpenID for enterprises users. It also addresses strong authentication needs and can cope with SAML.

Anyway: this has got nothing to do with identity 2.0. It's not the end user that is in control of his identity. This may be fine for enterprise use, but why would a company pay fot sso in the cloud? Enterprise sso (esso) may be considered a security measure (it makes sharing accounts by end users difficult). And if you employed esso, cloud apps should be handled as well.

I'm a little bit concerned about such developments. The problem with services like this (as wel as with OpenID) is that a central authority gets to know my whereabouts. Can these authorities be trusted? How about international regulations? Any clue? How do they handle logging and log analysis? Or log retention (I hope Not).

I'm happy with this kind of development, because it propagates the use of open standards like SAML.

Still, not for me, though. I prefer an internal esso and besides, the password store in firefox and ie is capable enough. It is great, however, that using sso you are into green computing, in pandemic planning and fuel conservation and thus protecting the environment. I don't know how, but it's in their About statement (at least in today's version) :)

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.

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.