23 October 2014

Stephen Wilson in Lockstep

Stephen Wilson - Lockstep Group

34 | posts 114,191 | views 166 | comments

Online Banking

This community is for discussion of developments in the e-banking world, including mobile banking. This can include all the functional, business, technical, marketing, web site design, security and other related topics of Internet Banking segment, including public websites of the banks and financial institutions across the globe.

Why is Federated Identity so hard?

06 May 2008  |  3643 views  |  1

Perhaps because it's just not natural!

Federated Identity is certainly one of the hotter topics in e-business and security circles currently.  It promises to improve cost, efficiency and convenience of identity management -- an intuitively compelling package. But the impact on security is far from clear, and the legal complexities have been badly under-estimated. 

Buzzwords and easy metaphors fly around identity management and federation like no other field. A great deal depends on what is meant by “federation”, and indeed by “identity” and “authentication”. 

So what are we talking about?  The Liberty Alliance is a big consortium working on federated identity standards and methods. Liberty defines Federated Identity as something that “allows users to link identity information between accounts without centrally storing personal information”. They add that “in practice, this means that users can be authenticated by one company or web site and be recognized and delivered personalised content and services in other locations without having to re-authenticate, or sign on with a separate username and password”.

Yet authorisation can be more important than authentication: we need to assert not only who we are, but what we are; e.g. bank customer number so-and-so, officer of registered business such-and-such, policy holder number X-Y-Z.  In the real world we act in various capacities depending on what business we’re trying to conduct.  That is, we make a number of different assertions about ourselves (or “claims” as they are called in the Laws of Identity). 

It is here that security purists insist on separating authentication (proving who you are, aka your identity) from authorisation (telling which capacity you are asserting).  Moreover, purists claim that authentication has primacy over authorisation.  But this is really splitting hairs. In the real world, authorisation is sometimes bound so closely to authentication that it’s unhelpful to tease them apart.  We can actually behave according to truly separate identities.  Here’s an example. 

I am an authorised signatory to my company’s corporate bank account; I happen to hold my personal bank account at the same bank, which naturally has given me two different key cards.  When I bank on behalf of my company, I exercise a different identity compared with when I bank on my own behalf, even if I am in the same branch or at the same ATM.  There is no “federation” between my corporate and personal identities; it is not even sensible to think in terms of my personal identity plus my corporate attributes when I am conducting business banking.  After all, so much corporate law is all about separating the identity of a company’s officers and the company itself.

Now, authorisation turns out to be fiendishly difficult to federate.  There have been a few bold attempts to share identity management infrastructure between banks but to my knowledge, not one has succeeded. The idea sounds great at first but in practice, breaking down silos between businesses is really tough; witness the struggles of the Trust Centre in Australia. 

What's going on here?  I think a big problem is that while we think we're talking about "identity" (which seems like an absolute, something with no competitive advantage) what's really involved is relationships, and these are not so easily shared.  Consider if I have an account with Bank A; what does it matter to Bank B?  My relationship with Bank A might help bootstrap a new account with B; for instance B might be interested in my credit history with A, and of course my 100 point check with A might carry over to B.  But once I am up and running with B, then I will have a fresh account, a new key card, different account numbers and different relationships. 

These relationships go hand-in-glove with legal agreements and terms & conditions that closely bind customer and institution.  In all the federation schemes I have ever seen, a crucial missing ingredient is a legal framework in which the Ts&Cs crafted and siloed between one bank and its customers can be carried over to another bank.  What bank in its right mind would wish to be contractually joined to the dealings between its customer and a competitor?  

The word "silo" is almost a term of abuse in business nowadays; we're encouraged to break them down, almost indiscriminately.  But "silos" have good connotations too. The silos that safeguard our banking relationships, just like grain silos, are strong, elegant, secure, and resistant to the elements.  They're cemented by mature and well tested legal arrangements which, unsurprisiingly, are not so easily deconstructed and put back together again across otherwise totally separate organisations. 

 

TagsSecurityOnline banking

Comments: (1)

Dean Procter - Transinteract - Sydney | 06 May, 2008, 08:18

Nicely put Stephen. It certainly isn't simple.

I've always had difficulty accepting federated identity or Single Sign On etc.

My major issue with it is that there is a requirement to trust everyone in the 'federation'. 

Authentication and identity verification can be one and the same. For example: We can use the same 'act' to do either, such as, when we are involved in a transaction we can confirm our identity 'as an act of authorisation', so long as we are the only one who can do so.

With federated identity there are parties who identify the person (usually via their device and route, in addition to other factors etc) and issue credentials, albeit temporary ones, and the person can move from one domain to another in the 'federation' without the requirement to authenticate each time.

Therein lays the problem, how do you 'carry' digital identity between sites on the world wild web, without it being compromised? Do you trust the original issuer or some other third party, especially if it is a competitor?

Federated identity requires a federation of identity issuers and accepters in order to work properly. Federations are very difficult to get together and keep together. They are fragile.

They are also each an individual target, each individual entity in the federation.

In the art of war in the transaction space there are already too many targets. Very few entities are able to defend themselves. A better approach is to have a single target which is not involved in the outcome of interactions or transactions - except for the identity/authentication process.

Not a single point of failure (multiple facilities) but a single point of attack/defence.

That is - in order to attack any of the participant entities an attacker is forced to attack and overcome the central identity/authentication process first. And they need to succeed before they have any chance of going on and and successfully attacking an individual participant.

That is my idea of federated identity - we all come together to create a single entity and we all act to defend it continually, and don't have us much need to defend an infinite number of 'identities' flying around the world wild web and EFTPOS net etc. 

When we need to know someone's identity (even without actually knowing) we just refer to the central identity/authentication provider - a trusted third party. In most cases we only need to know that there is an identity, rather than their intimate details.

So long as all participants use the right means to interact with the trusted identity provider, and are enrolled properly in the first instance, we don't require as much defense of the rest of the network, particularly if we stop sending as much personally identifiable data around too.

In looking at the internet I see that a combination of both models might be argued to  prevail with two separate 'types' of identity - transparent to the user but in the background and each with different security or risk qualities. The question there is what is low risk, because even age is a risk issue with Pandora's box or the  wild world web. At what point do we elevate the security by referring to the strongest process? Every time.

In the end I come back to the same model every time - a single trusted third party.

I am very willing to listen to other ideas and be enlightened, but all I can say at the moment is 'I have a humdinger of an idea for you', but I'll just have to show you.

There are some things that you just have to see for yourself.

Am I smiling?
I probably would be if it weren't for the plight of the people of Myanmar and the Midwest, and the Chinese folks with EV71 etc, some people are really having a tough time of it at the moment, and not just paying their mortgages.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)
Log in to receive notifications when someone posts a comment

Latest posts from Stephen

Now is not the time to go soft

03 August 2012  |  3005 views  |  2  |  Recommends 0 TagsSecurityPayments

How much worse can CNP fraud get?

17 July 2012  |  2340 views  |  1  |  Recommends 0 TagsSecurityPayments

Credit card numbers are like nitroglycerine

13 January 2012  |  3879 views  |  0  |  Recommends 0 TagsSecurityPayments

Banks really know their customers

13 December 2011  |  2563 views  |  1  |  Recommends 1

Taking full advantage of Chip

02 June 2011  |  3676 views  |  6  |  Recommends 0
name

Stephen Wilson

job title

Managing Director

company name

Lockstep Group

member since

2008

location

Sydney

Summary profile See full profile »
I specialise in digital identity, privacy, smart technologies and fraud prevention. I run the Lo...

Stephen's expertise

Who is commenting on Stephen's posts