Mobile: +61 (0) 414 488 851
Email: swilson@lockstep.com.au

Designing out identification uncertainty

A few of us have been debating Levels of Assurance on Twitter. It seems crucial that we look at authentication at enrolment or registration time separately from authentication at transaction time, as Jim Fenton touched on in his comment at http://lockstep.com.au/blog/2011/03/11/nstic-and-banking#comments.

A big problem in the discourse is that the process of checking identity at enrollment/registration time and at transaction time are both called "authentication" .

I contend that using quaternary LOAs to gauge someone we’re about to transact with is a very big change from the way we do routine business today, and that any major change to business liability arrangements, even if it is worthwhile, introduces such legal complexities that it can kill federated identity initiatives. Interestingly, lots of others also say LOAs are a big change but for different reasons! Paul Madsen @paulmadsen and Phil Hunt @independentid argue that trust in the real world is analogue, that it is determined on a continuum, and that we are never 100% sure of who some really is.

That’s true, and it’s crucial to consider the uncertainty when authenticating someone at enrollment time. But I think it’s a moot point when we authenticate a counter-party at transaction time. During a great many routine transactions, the counter-party is either authorised to deal or they are not. The question becomes binary, not analogue and not even quaternary! When a pharmacist processes a prescription, they want to know if it was signed by a doctor, or not. When I withdraw money at the bank, the teller checks if I am account holder, or not. The authority to sign purchase orders, tax returns, audit reports, legal advice, radiology reports, insurance loss estimates, survey reports etc. etc. is always binary. When the Relying Parties to any of these sorts of transactions process them, I do not believe that they spend any time at all pondering the analogue trustworthiness of the sender, or the percentage probability that the sender is not really who they say they are.

So what’s going on here? I admit there is uncertainty at the time of registration, but where has it gone by the time RPs make their real time binary decisions to accept or not? The answer is that uncertainty and its consequences are calculated in advance at design time and factored into enrollment protocols and other systemic risk management mechanisms, in such a way that during routine transactions, the RP need not worry.

In detail, consider doctors’ registration. The process for credentialing doctors is not perfect; let’s say 0.1% of doctors out there are frauds of some sort, carrying an authority that is not true. I contend that all those relying on a doctor’s credentials for routine transactions (these are pharmacists, pathologists, other doctors, hospital administrators, health insurers etc.) authenticate the doctor on a binary basis, by checking if they seem to hold a valid credential. If the doctor holds a credential, the RP simply assumes it’s genuine (naturally the RP will need to check for revocation, and tampering, but if the credential is mechanically valid, then the RP assumes it’s genuine). This 'blind' assumption by the RP results in a finite system-wide error rate in prescriptions, insurance claims and so on. There are system-wide quality control mechanisms that in effect monitor this error rate and initiates corrections when it gets too high (or when the odd spectacular screw up occurs like a fraudulent doctor kills a patient).

So there is a cascade of identification risk decisions being made at different points in the identity life cycle:

  • 1. At design time, health system managers, policy makers and regulators work out what the averaged consequences are of misidentifying doctors, and create processes and rules to manage the risk. These include up front credentialing procedures, as well as downstream safety nets, and ongoing monitoring and review of the rules.
  • 2. At registration time (when they get through college), candidate doctors are evaluated against those rules. Many different inputs will be involved; some, like reference checks, might be near-analogue. The process will be judgement based, and usually iterative, to deal with exceptions like overseas trained doctors, and may take time to execute. Yet it results in an authority to practice that is black-and-white [actually doctors typically carry a portfolio of specific b&w authorisations, pertaining to e.g. writing a prescription, writing a prescription for narcotics, carrying out certain operations, filing a public health insurance claim, admitting rights to a given private hospital, signing a pathology report etc.]
  • 3. At transaction time, when a doctor asserts their claim to be a doctor, the RP will make a go/no go decision, usually entirely automatically. If the RP follows all the rules of the transaction system they will generally bear no liability if a mis-identification has occurred upstream. RPs really want transaction-time authentication to be a highly mechanical process, with as little human intervention as possible; pharmacists for example don’t ever want to be in a position of having to make a fresh judgement on each and every routine prescription about the trustworthiness of the doctor.

My experience is that a great many economically important transactions can be accepted /rejected based on a very small number of assertions (usually just one) that the Subject can present directly to the RP. There need not be any real time Q&A back and forth between the RP and the Subject's IdP at transaction time. For example, a doctor’s Provider Number can be baked into a digital certificate issued by a recognised authority and asserted for each transaction via digital signature; RPs don’t need to know anything else about a doctor in order to accept or reject the vast majority of e-health communications. If a revocation check is necessary, it should be done at the medical credential issuer; an independent IdP adds no value here. Anyone remember a company called Valicert? They tried to inter-mediate status checks for digital certificates, but they failed to deliver any real value; RPs found they were better off going direct to a CA to check if a certificate was valid.

Posted in Trust, Security, Identity

Speaking of identity

The Identity movement is in crisis. Or at least, it should be.

Recent weeks have seen Microsoft shelve Cardspace and more or less pull out of the digital identity space. OpenID is being abandoned by important players. I would have expected quick and forceful semi-official responses from Kantara and the OIX Foundation but they seem mute. OpenID and Cardspace are the only two technologies explicitly mentioned in the (technology neutral) OIX Framework; they are the conceptual forebears of the National Strategy for Trusted Identities in Cyberspace. How can their struggles not signal deep deep troubles ahead for NSTIC and federated identity in general?

I see a paradox. In normal life, we are totally at ease with the concept of identity, its complexity and shades. We understand the different flavours of personal identity, national identity and corporate identity. We talk naturally, nay instinctively, about “identifying with” friends, communities, sporting teams, suburbs, cities, countries, causes, and companies. In multiculturalism we know about co-existing identities. Multiple personality syndrome makes sense to lay people. Identity is not absolute. It seems clear to me that we switch identities unconsciously, when for example we wear a uniform to work, or our team’s colours to a footy game. Most of us know how it feels at a school re-union to no longer identify with the way we once were.

But when it comes to digital identity — that is, knowing and showing who we are online — we make a total mess of it. The conceptual framework inherited mainly from computer science has led to arbitrary formulations around identity that are reasonable to technicians but don’t actually jive with the human condition. For example, “authentication” and “authorization” are not cleanly separable; further, to enforce an academic separation leads to tough problems. IT ideas like Single Sign On under one identity have no parallel in the real world.

Words are vitally important. If we can adopt plain language for describing identity online then we might see better progress and reach more stable positions.

So I offer here some fragments of simpler ways of talking about digital identity.

Let’s begin not with a formal definition but a form of words. What is identity? My identity is how I am known in a circle I move in.

I move in various circles: of colleagues, customers, users, members, professionals, friends and so on.

An identifier is a proxy for my identity in a given circle. An identifier represents me in a circle.

Identity is context dependent. An identifier is usually meaningless outside its circle. For example, if I tell you my “account number” is 56236741, it’s probably meaningless without giving the BSB as well (and that’s assuming it’s a bank account).

Identity usually goes with a set of rules. In any given circle, my identity confers certain rights and privileges. It is understood by everyone in the circle that there are rules governing belonging to that circle and having an identity within it.

People join different circles in different ways. Some circles have strict admission rules, some are also regulated (e.g. banks, chartered professional bodies). For the circles of most interest in the digital economy, there is usually an application process and an agreement to abide by the rules of the circle.

People obviously belong to many circles at once. Identities within circles do not usually “interoperate”. Quite often, circles are entirely separate, and it's essential for practical privacy that I control to a great extent how any of my circles overlap.

An important aspect of identity management that often gets mangled is the difference between (a) authenticating yourself in real time, when accessing a secure service, and (b) authenticating a transaction or document in your name, so that your involvement is evident to third parties at a later time. These are different use case scenarios, and may demand different technologies.

Some linguistic formality might help. Digital identity can be described in ...

First Person Present Tense “I am Acme employee 99” i.e. Access Control
Second Person Present Tense “You are www.anz.com.au i.e. “Mutual Authentication”
Third Person Present Tense “He is bob.pip.verisignlabs.com” e.g. Web SSO by OpenID
Third Person Past Tense “She was Dr Smith Prov. 123456” e.g. Digital Signature.

Posted in Language, Identity

NSTIC and banking don't speak the same language

I first blogged about this over at Finextra in January, asking if banks and their Know Your Customer regulations are compatible with the "Levels of Assurance" of federated identity and NSTIC especially? It seems to me that NSTIC and the finance sector don't speak the same language when it comes to identifying customers.

NSTIC adopts the now orthodox idea of “trust levels” or “Levels of Assurance” (LOA) from federated identity. The US National Institute of Standards and Technology has settled on a four point LOA standard. The idea is that different transactions carry different risks and need to be matched to the right LOA: Low, Medium, High and Very High (or words to that effect). And if different business domains can settle on a common language for describing risk and trust, then their identities should be able to interoperate. It’s intuitively attractive, but in practice difficult to apply, especially in banking, where there are strict regulated protocols for identifying customers.

I myself believe that pigeonholing risk into one of four boxes isn't helpful. Ironically, the parties to most business transactions make a binary decision as the authorisation of each other: Alice either has a bank account with Bob's bank, or she does not.

But I digress. If we accept the quaternary LOA scheme, is it compatible with KYC rules in the banking sector?

To take one example: KYC in Australia is regulated by our federal Financial Transactions Reports Act (1988) and by more recent anti-money laundering (AML) laws. We have a legislated proof-of-identity regime where various scheduled identification documents (passport, driver licence, bank cards, Medicare card, birth certificate, utilities bills) are each accorded a number of points reflecting their reliability. To open a new bank account, a customer has to furnish a total of 100 points worth of original documentation, including photo ID. The new AML rules allow for online origination of non-credit instruments by electronic proof of ID, usually mediated by online government services.

Identity federation will necessitate a change to this legislation. KYC rules will first need to adopt the language of LOAs, and the industry will have to map the existing points schema onto the four levels. This will be hard work in a what is an obviously conservative regulatory environment.

A few years ago, a major FS sector federation initiative here failed to proceed, largely because a clear business case for sharing IDM processes & infrastructure never emerged from the morass of legal, corporate and operational complexities. Empricially, we must face the fact that the cost/benefit of federating banking identities is difficult to demonstrate. I'm afrid this stark reality must undermine any impetus to drive what will be difficult changes to banking legislation.

In short, would the time and money invested in changing banking laws be worth it?

Posted in Language, Identity, Federated Identity, Security

Identity Evolves [AusCERT Conference Presentation Abstract]

This is the abstract for my paper that has been accepted in the main program at the AusCERT 2011 Conference.

Why Federated Identity is easier said than done

AusCERT2011 | "Overexposed" | 15th-20th May 2011
Royal Pines Resort | Gold Coast, Australia


Why does digital identity turn out to be such a hard problem? People are social animals with deep seated intuitions and conventions around identity, but exercising our identities online has been hugely problematic.

In response to cyber fraud and the password plague, there has been a near universal acceptance of the idea of Federated Identity. All federated identity models start with the intuitively appealing premise that if an individual has already been identified by one service provider, then that identification should be made available to other services, to save time, streamline registration, reduce costs, and open up new business channels. It’s a potent mix of supposed benefits, and yet strangely unachievable. True, we can now enjoy the convenience of logging onto multiple blogs and social networks with an OpenID or an unverified Twitter account. But higher risk services like banking, e-health and e-government have steadfastly resisted federation, maintaining their own identifiers and sovereign registration processes.

This paper shows that Federated Identity is in fact a radical and deeply problematic departure from the way we do business. It complicates long standing business arrangements and exposes customers and service providers alike to brand new risks which existing contracts are unable to deal with. Federated identity naively fails to understand that identities are proxies for relationships we have in different contexts. Business relationships don’t easily “interoperate”. They can’t be arbitrarily tweaked to suit different contexts, because each relationship has evolved to fit a particular niche. While the term identity “ecosystem” is fashionable, genuine ecological thinking has been lacking. The alternative presented here is to faithfully conserve business contexts and replicate existing trusted identities when we go from real world to digital, without massively re-engineering proven business rules and risk management strategies.

A still unproven idea

The past decade is littered with earnest identity initiatives that failed to get off the ground (including at least three in Australia alone) and security industry consortia that over-promised and under-delivered. We’ve endured endless deconstructions of “trust” and theoretical dissertations on “identity” but none of this work has led to the sort of breakthrough that’s desperately needed. Online identity fraud continues to grow. The direct cost is hundreds of billions of dollars globally; the indirect cost includes a malaise inhibiting such truly transformative initiatives as e-health.

In spite of its conspicuous failures and the revolving door of technical working groups, Federated Identity has become an orthodoxy. The US federal government’s proposed National Strategy for Trust Identities in Cyberspace (NSTIC) takes federation as a given. Its central tenets such as the pigeonholing of identification risk into four generic “trust levels” have been standardised in SAML and productised, but not yet realised.

Hidden complexities

If we take a closer look, we can see that nothing like Federated Identity has ever been done before. The proposition that banks, telcos, universities and governments should act in the open as “Identity Providers” is not something these institutions have contemplated outside their own closed business contexts.

Most federation initiatives hold out self-evidently noble objectives like “interoperability”, “openness” and the eradication of “silos”. Yet these feel-good words don’t stand up to scrutiny. Federation implies widespread changes to business rules and risk management arrangements, which lawyers and legislators have yet to come to grips with. Consider that banks have long established (and highly regulated) protocols for identifying customers. Introducing new third party identity providers and new enrolment pathways is a true paradigm shift, demanding untold revision of conventions, contracts and legislation.

The benefits of decentralisation claimed of Federated Identity are largely illusory. It is good for privacy and security that federation generally deprecates any one master ID, but it introduces legally novel intermediaries and new aggregations of personal information. For instance, in order to provide for “verified anonymity”, Federated Identity has customers enrol with brand new Identity Providers, handing over bulk personal information to them, only so that it may be withheld from service providers.

A simpler way forward

It is often said that identity management is “not a technology issue”. The statement is both right and wrong. The biggest challenges in federated identity are certainly not technological; rather, they relate to risk allocation in an unprecedented joined-up matrix which changes the legal fundamentals of how we do business. On the other hand, the pressing problems of ID theft and fraud really are technologically straightforward.

We all agree that identities are context dependent; the deeper truth is that identities are proxies for complex relationships that have evolved to fit distinct niches in the identity ecosystem. As with real life ecology, characteristics that bestow fitness in one niche can work against the organism in another. Thus the derided identity “silos” are a natural and inevitable consequence of how business rules are matched to particular contexts.

We need to avoid complicated generalisations about identity, and instead focus on simplifying assumptions. The password plague is only a problem because traditional access control was devised for technicians; consumer authentication simply needs better human-machine interfaces.

The real problem lies not in existing identity issuance processes; it’s to do with the way perfectly good identities once issued are taken ‘naked’ online where they’re vulnerable to takeover and counterfeiting. If we focussed on conserving context and replicating existing real world identities in non-replayable forms, most routine transactions could take place safely online, without the incalculable cost of re-engineering proven business arrangements.

Posted in Smartcards, Security, Privacy, Internet, Identity, Fraud, Culture