Lockstep

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

FIDO Alliance goes from strength to strength

With a bunch of exciting new members joining up on the eve of the RSA Conference, the FIDO Alliance is going from strength to strength. And they've just published the first public review drafts of their core "universal authentication" protocols.

An update to my Constellation Research report on FIDO is now available. Here's a preview.

The Go-To standards alliance in protocols for modern identity management

The FIDO Alliance – for Fast IDentity Online – is a fresh, fast growing consortium of security vendors and end users working out a new suite of protocols and standards to connect authentication endpoints to services. With an unusual degree of clarity in this field, FIDO envisages simply "doing for authentication what Ethernet did for networking".

Launched in early 2013, the FIDO Alliance has already grown to nearly 100 members, amongst which are heavyweights like Google, Lenovo, MasterCard, Microsoft and PayPal as well as a couple of dozen biometrics vendors, many of the leading Identity and Access Management solutions and service providers and several global players in the smartcard supply chain.

FIDO is different. The typical hackneyed elevator pitch in Identity and Access Management promises to "fix the password crisis" – usually by changing the way business is done. Most IDAM initiatives unwittingly convert clear-cut technology problems into open-ended business transformation problems. In contrast, FIDO's mission is refreshingly clear cut: it seeks to make strong authentication interoperable between devices and servers. When users have activated FIDO-compliant endpoints, reliable fine-grained information about their client environment becomes readily discoverable by any servers, which can then make access control decisions, each according to its own security policy.

With its focus, pragmatism and critical mass, FIDO is justifiably today's go-to authentication standards effort.

In February 2014, the FIDO Alliance announced the release of its first two protocol drafts, and a clutch of new members including powerful players in financial services, the cloud and e-commerce. Constellation notes in particular the addition to the board of security leader RSA and another major payments card, Discover. And FIDO continues to strengthen its vital “Relying Party” (service provider) representation with the appearance of Aetna, Goldman Sachs, Netflix and Salesforce.com.

It's time we fixed the Authentication plumbing

In my view, the best thing about FIDO is that it is not about federated identity but instead it operates one layer down in what we call the digital identity stack. This might seem to run against the IDAM tide, but it's refreshing, and it may help the FIDO Alliance sidestep the quagmire of identity policy mapping and legal complexities. FIDO is not really about the vexed general issue of "identity" at all! Instead, it's about low level authentication protocols; that is, the plumbing.

The FIDO Alliance sets out its mission as follows:

  • Change the nature of online authentication by:
    • Developing technical specifications that define an open, scalable, interoperable set of mechanisms that reduce the reliance on passwords to authenticate users.
    • Operating industry programs to help ensure successful worldwide adoption of the Specifications.
    • Submitting mature technical Specification(s) to recognized standards development organization(s) for formal standardization.

The engineering problem underlying Federated Identity is actually pretty simple: if we want to have a choice of high-grade physical, multi-factor "keys" used to access remote services, how do we convey reliable cues to those services about the type of key being used and the individual who's said to be using it? If we can solve that problem, then service providers and Relying Parties can sort out for themselves precisely what they need to know about the users, sufficient to identify and authenticate them.

All of these leaves the 'I' in the acronym "FIDO" a little contradictory. It's such a cute name (alluding of course to the Internet dog) that it's unlikely to change. Instead, I overheard that the acronym might go the way of "KFC" where eventually it is no longer spelled out and just becomes a word in and of itself.

FIDO Alliance Board Members

  • Blackberry
  • CrucialTec (manufactures innovative user input devices for mobiles)
  • Discover Card
  • Google
  • Lenovo
  • MasterCard
  • Microsoft
  • Nok Nok Labs (a specialist authentication server software company)
  • NXP Semiconductors (a global supplier of card chips, SIMs and Secure Elements)
  • Oberthur Technologies (a multinational smartcard and mobility solutions provider)
  • PayPal
  • RSA
  • Synaptics (fingerprint biometrics)
  • Yubico (the developer of the YubiKey PKI enabled 2FA token).

FIDO Alliance Board Sponsor Level Members

  • Aetna
  • ARM
  • AGNITiO
  • Dell
  • Discretix
  • Entersekt
  • EyeLock Inc.
  • Fingerprint Cards AB
  • FingerQ
  • Goldman Sachs
  • IdentityX
  • IDEX ASA
  • Infineon
  • Kili
  • Netflix
  • Next Biometrics Group
  • Oesterreichische Staatsdruckerei GmbH
  • Ping Identity
  • SafeNet
  • Salesforce
  • SecureKey
  • Sonavation
  • STMicroelectronics
  • Wave Systems

Stay tuned for the updated Constellation Research report.

Posted in Smartcards, Security, Identity, Federated Identity, Constellation Research, Biometrics

Attribute wallets

There's little debate now that attributes are at least as important as "identity" in making decisions about authorization online. This was a recurring theme at the recent Cloud Identity Summit and in subsequent discussions on Twitter, my blog site and Kuppinger Cole's. The attention to attributes might mean a return to basics, with a focus on what it is we really need to know about each other in business. It takes me back to the old APEC definition of authentication: the means by which the recipient of a transaction or message can make an assessment as to whether to accept or reject that transaction.

A few questions remain, like what is the best way for attributes to be made available? And where does all this leave the IdP? The default architecture in many peoples' minds is that attributes should be served up online by Attribute Providers in response to Relying Party's needing to know things about Subjects instantaneously. The various real time negotiations are threaded together by one or more Identity Providers. Here I want to present an alternative but complementary vision, in which attributes are presented to Relying Parties out of digital wallets controlled by the Subjects concerned, and with little or no involvement of Identity Providers as such.

Terminology: In this post and in most of my works I use the nouns attribute, claim and [identity] assertion interchangeably. What we're talking about are specific factoids about the first party to a transaction (the "Subject") that are interesting to the second party in the transaction (the "Relying Party" or Service Provider). In general, each attribute is vouched for by an authoritative third party referred to as an Attribute Provider. In some special cases, an RP can trust the Subject to assert certain things about themselves, but the more interesting general case is where the Relying Party needs external assurance that a given attribute is true for the Subject in question. I don't have much to say about self-asserted attributes.

The need to know

As much as we're all interested in identity and "trust" online, the currency of most transactions is context-specific attributes. The context of a transaction often determines (and determines completely) the attributes that determine whether a party is authorised. For example, if the Subject is a shopper, the RP a merchant and the transaction a credit card purchase, then the attributes of interest are the cardholder name, account number, billing address and maybe the card verification code. In the context of dispensing an electronic prescription, the only attribute might be the doctor's prescriber number (pharmacists of course don't care who the doctor 'really is'; notoriously they can't even read the doctor's handwriting). For authorising a purchase order on behalf of a company, the important attributes might be the employee position and staff ID. For opening a new bank account, Know-Your-Customer (KYC) rules in most jurisdictions will dictate that such attributes as legal name, address, date of birth and so on be presented in a prescribed form (typically by way of original government issued ID documents).

For most of the common attributes of interest in routine business, there are natural recognised Attribute Authorities. Some are literally authoritative over particular attributes. Professional bodies for instance issue registration numbers to accountants, doctors, engineers and so on; employees assign staff IDs; banks issue credit card numbers. In other cases, there are de facto authorities; most famously, driver licenses are relied on almost universally as proof of age around the world.

Sometimes rules are laid down that designate certain organisations to act as Attribute Providers - without necessarily using that term. Consider how KYC rules in effect designate Attribute Authorities. In Australia, the Financial Transaction Reports Act 1988 (FTRA) has long established an identity verification procedure called the "100 point check". FTRA regulations prescribe a number of points to various identification documents, and in order to open a bank account here, you need to present a total of 100 points worth of documents. Notable documents include:

  • Birth certificate: 70 points
  • Current passport: 70 points
  • Australian driver licence [bearing a photo]: 40 points
  • Foreign driver licence [not necessarily bearing a photo]: 25 points
  • Credit card: 25 points.

So in effect, the financial regulators in Australia have designated driver license bureaus and credit card issuers to be Attribute Providers for names (again, without actually using the label "AP"). Under legislated KYC rules, a bank creating a new customer account can rely on assertions made by other banks or even foreign driver license authorities about the customer's name, without needing to have any relationship with the "APs". Crucially, the bank need not investigate for itself nor understand the detailed identification processes of the "APs" listed in the KYC rules. Of course we can presume that KYC legislators took advice on the details of how various identity documents are put together, and in the event that an error is found somewhere in the production of an identity feeder document then forensic investigation would follow, but the important point is that routinely, the inner workings of all the various APs are opaque to most relying parties. The bank as RP does not need to know how a license bureau does its job.

And yet we do know that the recognised Attribute Providers continuously improve what they do. Consider driver licenses. In Australia up until the 1970s, driver licenses were issued on paper. Then plastic cards were introduced with photographs. Numerous anti-copying measures have been rolled out since then, such as holograms, and guilloche, optically variable and micro printing. Now the first chipped driver licenses are being issued, in which cryptographic technology not only makes counterfeiting difficult but also enables digitally signed cardholder details to be transmitted electronically (the same trick utilised in EMV to stop skimming and carding). Less obvious to users, biometric facial recognition is also used now during issuance and renewal to detect fraudsters. So over time the attributes conveyed by driver licenses have not changed at all - name, address and date of birth have always meant the same thing - but the reliability of these attributes when presented via licenses is better than ever.

Imposters are better detected during the issuance process, the medium has become steadily more secure, and, more subtly, the binding between each licence and its legitimate holder is stronger.

We are accustomed in traditional business to dealing with others on the basis of their official credentials alone, without needing to know much about who they 'really are'. When deciding if we can accept someone in a particular transaction context, we rely on recognised providers of relevant attributes. Hotel security checks a driver license for a patron's age; householders check the official ID badges of repair people and meter readers; a pathologist checks the medical credentials of an ordering doctor; an architect only deals with licensed surveyors and structural engineers; shareholders only need to know that a company's auditors are properly certified accountants. In none of these routine cases is the personal identity of the first party of any real interest. What matters is the attributes that authorise them to deal in each context.

Digital wallets

Now, in the online environment, what is the best way to access attributes? My vision is of digital wallets. I advocate that users be equipped to hold close any number of recognised attributes in machine readable formats, so they can present selected attributes as the need arises, directly to Relying Parties. This sort of approach is enabled by the fact that the majority of economically important transaction settings draw on a relatively small number of attributes, and we can define a useful attribute superset in advance. As discussed previously such a superset could include:

  • {Given name, Residential address, Postal address, Date of Birth, "Over 18", Residential status, Professional qualification(s), Association Membership(s), Social security number, Student number, Employee Number, Bank account number(s), Credit card number(s), Customer Reference Number(s), Medicare Number, Health Insurance No., Health Identifier(s), OSN Membership(s)}

Many of these attributes have just one natural authoritative provider each; others could be provided by a number of alternative organisations that happen to verify them as a matter of course and could stand ready to vouch for them. The decision to accept any AP's word for a given attribute is ultimately up to the Relying Party; each RP has its own standards for the required bona fides of the attributes it cares about.

There are a few obvious candidates for digital attribute wallets:


  • A smart phone could come pre-loaded with attributes that have been verified as a matter of course by the telephone company, like the credit card number associated with the account, or proof of age. A digital wallet on the phone could later be topped up with additional attributes, over the air or via some other more secure over-the-counter protocol.

  • A smart driver license could hold digital certificates signed by the licensing bureau, asserting name, address, date of birth, and/or simpler de-identified statements like "the older is over 18". Note that the assertions could be made separately or in useful combinations; for privacy, a proof of age certificate need not name the holder but simply specify that the assertion is carried on a particular type of chip, signed by the authoritative issuer.

  • When you receive a smart bank card, the issuer bank could load the chip with your name, address, date of birth, PANs and/or certified copies of identity documents presented to open the account. Such personal identity assertions could then be presented by the customer to other RPs like financial institutions or retailers to originate other accounts.

Do we need an "Identity Provider" to thread together these attributes? No. While it is important that RPs can trust that each attribute is in the right hands, the issuance process (including the provisioning of attribute carrying tokens like cards and mobile phones) is just one aspect of the Attribute Provider's job. If we can trust say a licensing bureau to verify the particulars of a license holder, then we can also trust them as part of that process to ensure that the license is in the hands of its rightful owner.

In contrast with the real time 'negotiated' attributes exchange architectures, the digital wallet approach has the following advantages:


  • Decentralised architecture: lower cost and quicker to deploy; we can start local and scale up as Attribute Providers gain ground;

  • Fast: digitally signed attributes presented from smart devices diret to Relying Parties can be cryptographically verified instantaneously, for higher performance, especially in bandwidth limited environments.

  • Intrinsically private: Direct presentation of attributes minimises the exposure of personal information to third parties.

  • ”Natural”: Digital wallets of attributes is congruent with the way we hold diverse pieces of personal documentation in regular wallets; unlike big federation model, no novel new intermediaries are involved.

  • Legally simpler: It is relatively simple matter for Attribute Authorities to warrant the accuracy of separate particulars like name, date of birth, account number, without any making any other broad representations of who the Subject 'really is'. There is none of the legal fine print that bedevilled Big PKI Certification Authorities in the past and which proved fatal in federation programs like the Internet Industry Association 2FA pilot.

Notes

  • On a case by case basis, as dictated by their risk management strategies, RPs can revert to an online AP to check the up-to-the-minute validity of an attribute. In practice this is not necessary in many cases; many of the common attributes in business are static, and once issued (or vouched for by a reputable body) do not change. If attributes are conveyed by digital certificates, then their validity can be efficiently checked online by OCSP and near-line by CRL.
  • The patient smartcards already widespread in Europe are an ideal carrier for a plurality of human services identifiers (such as public health insurance numbers, health record identifiers, medical social networking handles, and research tracking numbers; see also a previous presentation on anonymity and pseudonymity in e-research).
  • As other conventional plastic cards are progressively upgraded to chip - such as the proposed US Medicare card modernization - we have a natural opportunity to load them with secure digital assertions too.
  • In the medium to long term, digitally signed attributes could be made to chain through communities of CAs to a small number of globally recognised Root Authorities. For a model, refer to s4.4 "How to convey fitness for purpose" of my Public Key Superstructure presentation to the 2008 NIST IDTrust workshop.

Posted in Smartcards, Security, Identity, Federated Identity, Trust

The IdP is Dead!

"All Hail the Relyingpartyrati!"

I presented my ecological theory of identity to the Cloud Identity Summit last week.

The quote "The IdP is Dead! Hail the Relyingpartyrati" is from my conclusion (reflecting the running inside joke at CIS that something has to die each year). One of my ideas is that because identification is carried out by Relying Parties, it's more correct (and probably liberating) to think of identity as being created by the RP. The best option for what we call "Identity Providers" today may be to switch to providing more specific Attributes or identity assertions. In fact, the importance of attributes kept recurring throughout CIS; Andrew Nash for example said at one point that "attributes are at least as interesting if not more so than identities".

[Now it has emerged during the debates that people might use the word "attribute" in slightly different ways. I said at CIS that I treat 'attributes', 'assertions' and 'claims' interchangeably; I think we should focus functionally on reliable exchange of whatever factoids a Relying Party needs to know about a Subject in order to be able to transact. I'll blog in more detail about Attributes shortly.]

To summarise my CIS talk:

Federated Identity is easier said than done. In response, we should drop down a level, and instead of trading in abstract high level identities, let's instead federate concrete component attributes. We don't really need Identity Providers as such; we need a marketplace of Attribute Providers from which Relying Parties can get exactly the right information they need to identify their users.


  • identities evolve over time in response to risk factors in the natural business environment; we need to understand why authentication has got the way it is before we rush in to federate disparate methods
  • identities appear to be "memetic", composed of heritable traits relating to business rules and practices, conventions, standards, regulations, technologies, algorithms, cryptographic parameters, form factors and so on
  • the dreaded identity silos are actually ecological niches; taking an identity from the context in which it evolved and using it in another is like taking a salt water fish and dropping it into a fresh water tank
  • if identity is memetic then we should be able to sequence digital identities into their constituent memes, and thence re-engineer them more carefully to match desired new applications
  • it is an over-simplification to think of a (one dimensional) identity spectrum; instead each RP's "identification" requirements are multi-dimensional, and best visualised as a surface.

Posted in Identity, Federated Identity, Cloud

The devil is in the legals

Many of the identerati campaign on Twitter and on the blogosphere for a federated new order, where banks in particular should be able to deal with new customers based on those customer’s previous registrations with other banks. Why, they ask, should a bank put you through all that identity proofing palava when you must have already passed muster at any number of banks before? Why can’t your new bank pick up the fact that you’ve been identified already? The plea to federate makes a lot of sense, but as I’ve argued previously, the devil is in the legals.

Funnily enough, a clue as to the nature of this problem is contained in the disclaimers on many of the identerati’s blogs and Twitter accounts:

"These are personal opinions only and do not reflect the position of my employer".

Come on. We all know that’s bullshit.

The bloggers I’m talking about are thought leaders at their employers. Many of them have written the book on identity. They're chairing the think tanks. What they say goes! So their blogs do in fact reflect very closely what their employers think.

So why the disclaimer? It's a legal technicality. A company’s lawyers do not want the firm held liable for the consequences of a random reader following an opinion provided outside the very tightly controlled conditions of a consulting contract; the lawyers do not want any remarks in a blog to be taken as advice.

And it's the same with federated identity. Accepting another bank's identification of an individual is something that cannot be done casually. Regardless of the common sense embodied in federated identity, the banks’ lawyers are saying to all institutions, sure, we know you're all putting customers through the same identity proofing protocols, but unless there is a contract in place, you must not rely on another bank's process; you have to do it yourself.

Now, there is a way to chip away at the tall walls of legal habit. This is going to sound a bit semantic, but we are talking about legal technicalities here, and semantics is the name of the game. Instead of Bank X representing to Bank Y that X can provide the "Identity" of a new customer, Bank X could provide a digitally notarised copy of some of the elements of the identity proofing. Elements could be provided as digitally signed messages saying "Here's a copy of Steve’s gas bill" or "Here's a copy of Steve’s birth certificate which we have previously verified". We could all stop messing around with abstract identities (which in the fine print mean different things to different Relying Parties) and instead drop down a level and exchange information about verified claims, or "identity assertions". Individual RPs could then pull together the elements of identity they need, add them up to an identification fit for their own purpose, and avoid the implications of having third parties "provide identity". The semantics would be easier if we only sought to provide elements of identity. All IdPs could be simplified and streamlined as Attribute Providers.

See also An identity claims exchange bus and Identity is in the I of the beholder.

Posted in Trust, Internet, Federated Identity

An algebra of identity

In my recent post "Identity is in the eye of the beholder" I tried to unpack the language of "identity provision". I argued that IdPs do not and cannot "provide identity" because identification is carried out by Relying Parties. It may seem like a sterile view in these days of '"self narrated' and bring-you-own identities but I think the truth is that identity is actually determined by Relying Parties. The state of being "identified" may be assisted (to a very great extent) by information provided by others including so-called "Identity" Providers but ultimately it is the RP that identifies me.

I note that the long standing dramaturgical analysis of social identity of Erving Goffman actually says the same thing, albeit in a softer way. That school of thought holds that identity is an emergent property, formed by the way we think others see us. In a social setting there are in effect many Relying Parties, all impressing upon us their sense of who we are. We reach an equilibrium over time, after negotiating all the different interrelating roles in the play of life. And the equilibrium can be starkly disrupted in what I've called the "High School Reunion Effect". So we do not actually curate our own identities with complete self-determination, but rather we allow our identities to be moulded dynamically to fit the expectations of those around us.

Now, in the digital realm, things are so much simpler, you might even say more elegant in an engineering fashion. I'd like to think that the dramaturgical frame sets a precedent for having identities impressed upon us. We should not take offense at this, and we should temper what we mean by "user centric" identities: it need not mean freely expressing all of our identities.

For more precision, maybe it would be useful to get into the habit of specifying the context whenever we talk of a Digital Identity. So here's a bit of mathematical nomenclature, but don't worry, it's not strenuous!

Let's designate the identification performed by a Relying Party RP on a Subject S as IRP-S.

If the RP has drawn on information provided by an "Identity Provider" (running with the dominant language for now), then we can write the identification as a function of the IdP:

Identification = IRP-S(IdP)

But it is still true that the state of identification is reached by the RP and not the IdP.

We can generalise from this to imagine Relying Parties using more than one IdP in making the identification of a subject:

Identification = IRP-S(IdP1,IdP2)

And then we could take things one step further, to recognise that the distinction between "identity providers" and "attribute providers" is arbitrary. So the most general formulation would show identification being a function of a number of attributes verified by the RP either for itself or on its behalf by external attribute providers:

Identification = IRP-S(A1,A2,...,A2)

(where the source of the attribute information could be indicated in various ways).

The work we're trying to start in Australia on a Claims Verification ecosystem reflects this kind of thinking -- it may be more powerful and more practicable to have RPs assemble their knowledge of Subjects from a variety of sources.

Posted in Language, Identity, Federated Identity

An Authentication Claims Exchange Bus

Last week I had the very great pleasure of participating in the first MIT Legal Hackathon, organised by Dazza Greenwood and Thomas Hardjono for the MIT Media Lab, Kerberos Consortium and wwPass. I say first because they plan to hold a monthly hangout! I hope and expect that this will become a strong, dynamic new forum for multi-disciplined explorations of Digital Identity.

In Dazza's wrap-up of the event, he pondered the potential for "open public infrastructure for identity":

... like a big bus of some sort for essential claims from public or other sources, utilised foundationally for identity functions."

His idea builds out logically from a proposed system of claims verification services that I presented to the hackathon, and blogged about a few weeks ago. So for discussion, here's a further development of the schematic. A variety claims verification services would be made available over a common bus as Dazza suggested, and used by a Relying Party to assemble the particular fractions of information they decide will make up a Subject's identity in a given transaction context.

Lockstep Identity Claims Bus after Dazza Greenwood 130203

Something I really I like about this architecture is that it supports several different modes of identification. For one, it could be used in real time by an RP faced with a fresh user for the first time; the RP could in real time seek out 'attribute providers' in the OIX or Identity Metasystem way of working. Alternatively, for well-worn e-commerce transactions where the necessary claims are well known in advance, the Subject could put together a basket of claims in advance and carry them in an identity wallet to be presented directly to the RP.

The diagram also shows a visualisation of the claims of interest to the RP for the transaction at hand, and the necessary degree of confidence i each of them (i.e. 90% in name, residential address and date of birth). I discussed this way of looking at different claims sets as surfaces in another blog last year.

As we rethink identity orthodoxies in forums like the MIT Legal Hackathon, I propose we shift perspectives a little. For instance:


  • We should drop down a level, and focus on ways to exchange information about elements of identity, rather than rolled-up "identities" themselves; that is, we should fractionate identity into its important component parts, guided by transaction context.

  • When building identification services frameworks, we should avoid imposing particular business protocols on organisations, so they remain free to select which claims and combinations of claims they want Subjects to exhibit.

  • We can avoid technicalities like the difference between "authentication" and "authorization", and indeed we can remove ourselves from the philosophical debates over "identity"; the proposal simply provides uniform market-based mechanisms for parties to assert and test elemental claims as a precursor to doing business.

  • Life looks much simpler under the neutral definition of "authentication" adopted by the APEC eSecurity Task Group over a decade ago: the means by which a receiver of an electronic transaction or message makes a decision to accept or reject that transaction or message.

None of this is actually radical. We've always thought about claims and attributes, all the authentication protocols deal with attributes, the good old Laws of Identity were actually all about claims, and there is infrastructure to deal with claims.

I think we just need to shift focus. We technologists shouldn't be so preoccupied with identity per se; let businesses continue to sort out identities as they see fit, and just give them the means to deal digitally with component claims. Let's not put IdPs ahead of APs. It may turn out we don't need IdPs at all. It's all about the claims, and only about the claims.

Comments welcome!

Posted in Identity, Federated Identity

Identity is in the eye of the beholder

That is to say, identity is in the eye of the Relying Party.

The word "identity" seems increasingly problematic to me. It's full of contradictions. On the one hand, it's a popular view that online identity should be "user centric"; many commentators call for users to be given greater determination in how they are identified. People like the idea of "narrating" their own identities, and "bringing their own identity" to work. Yet it's not obvious how governments, banks, healthcare providers or employers for instance can grant people much meaningful say in how they are identified. These sorts of organisations impress their particular forms of identity upon us in order to formalise the relationship they have with us and manage our access to services.

The language of orthodox Federated Identity institutionalises the idea that identity is a good that is "provided" to us through a supply formal chain elaborated in architectures like the Open Identity Exchange (OIX). It might make sense in some settings for individuals to exercise a choice of IdPs, for example choosing between Facebook or Twitter to log on to a social website, but users still don't have much influence on how the IdPs operate, nor on the decision made by Relying Parties about which IdPs they elect to recognise. Think about the choice we have of credit cards: you might prefer to use Diners Club over MasterCard, but if you're shopping at a place that doesn't accept Diners, your "choice" is constrained. You cannot negotiate in real time to have the store accept your chosen instrument (instead you can choose to get yourself a MasterCard or you can choose to go to a different store).

I think the concept of "identity" is so fluid that we should probably stop using it. Or at least use it with much more self-conscious precision.

I'd like you to consider that "Identity Providers" do not in fact provide identity. They really can't provide identity at all, but only assertions -- that is, elements of identity -- that are put together by others who are impacted by the validity of those elements. The act of identification is a part of risk management. It means getting to know a Subject so as to make certain risks more manageable. And it's always done by a Relying Party.

An identity is the outcome of an identification process in which claims about a Subject are verified, to the satisfaction of the Relying Party. An "identity" is basically a handle by which the Subject is known. Recall that the Laws of Identity usefully defined a Digital Identity as a set of claims about the Digital Subject. And we all know that identity is highly context dependent; on its own, an identity like "Acct No. 12345678" means little or nothing without knowing the context as well.

This line of reasoning reminds me once again of the technology neutral, functional definition of "authentication" used by the APEC eSecurity Task Group over a decade ago: the means by which a receiver of an electronic transaction or message makes a decision to accept or reject that transaction or message. Wouldn't life be so much simpler if we stopped overloading some bits of authentication knowledge with the label "identity" and going to such lengths to differentiate other bits of knowledge as "attributes"? What we need online is better means for reliably conveying precise pieces of information about each other, relevant to the transaction at hand. That's all.

Carefully unpacking the language of identity management, we see that no Identity Provider ever actually "identifies" people. In realty, identification is always done by Relying Parties by pulling together what they need to know about a Subject for their own purposes. One IdP might say "This is Steve Wilson", another "This is Stephen Kevin Wilson", another "This is @Steve_Lockstep", another "This is Stephen Wilson, CEO of Lockstep" and yet another "This is Stephen Wilson at 100 Park Ave Jonestown Visa 4000 1234 5678 9012". None of these assertions are my "identity"! My "identity" is different at every RP, each to their need.

See also An Algebra of Identity.

Posted in Language, Identity, Federated Identity

Don't mix business and pleasure

At the recent Gartner Identity & Access Summit, analyst Earl Perkins spoke of the potential for Facebook to be used as an enterprise IdP. I'd like to see these sorts of speculations dampened a little by filtering them through the understanding that identity is a proxy for relationship.

Here's the practical difficulty that shows why we must reframe what we're talking about. If Facebook were to be an Identity Issuer, they would have to be clear about what enterprises really need to know about their staff, customers, partners and so on. There is no standardised answer to that; every business gets to know its people in their own peculiar ways. Does Facebook with its x-ray vision into our personal lives have anything to offer enterprises? If we work out which assertions might be vouched for by Facebook, how would they be underwritten exactly?

And I really mean exactly because liability is what kills off most identity federations. The idea of re-using identity across contexts is easier said than done. Banks have tried and tried again to federate identities amongst themselves. The Australian experience (of Trust Centre and MAMBO) was that banks find it too complex to re-use each others' issued IDs because of the legal complexity, even when they're all operating under the same laws and regulations! So how on earth will business make the jump to using Facebook as an IdP when they have yet to figure out banks as IdP?

I'd surely like to hear from Facebook themselves about how they see their IdP business developing. They're being very coy about even the early forays like Facedeals, which is using biometric data from Facebook to check people into stores by facial recognition. It's a pretty serious app, with very serious privacy ramifications, amplified by the fact that German regulators have thrown the book at Facebook for being underhanded with photo tagging. Under the circumstances, I would have expected Facedeals to have a Privacy Policy, and Facebook to make some public announcements about how they support the third party consumption of their biometric templates. But no, neither has happened.

The old saw don't "Mix Business And Pleasure" turns out to predict the cyber world challenges of bringing social identities and business identities together. I have concluded that identity is metaphorical. Each identity is really a proxy for a relationship, and most of our intuitions about identity need to be reframed in terms of relationships. We're not talking simply about names! The types of relationship we entertain socially (and are free to curate for ourselves) may be fundamentally irreconcilable with the identities provided to us by businesses as a way to manage their risks, as is their prerogative.

Posted in Social Networking, Identity, Federated Identity

Speaking plainly about Identity

I was recently editing my long "ecological identity" paper from last year and I was reminded how we tend to complicate identity when we speak about it. Here's a passage from that paper, which argues that the language we use is important. I contend we don't need to introduce new technical definitions around identity. Furthermore, I think if we returned to plain language, we might actually see federated identity differently.

Why for instance do orthodox identity engineers insist that authentication and authorization are fundamentally different things? The idea that roles are secondary to identity dates back to 1960's era Logical Access Control. It's an arbitrary distinction not usually seen in the the real world. Authorization is what really matters in most business, not identity. For instance, no pharmacist identifies a doctor before relying on a prescription; the prescription itself, written on an official watermarked form confers the necessary authority. Context is vital; in fact it's often the case that "the medium is the authentication" (with apologies to Marshall McLuhan).

What follows is extracted from Identities Evolve: Why federated identity is easier said than done, AusCERT Security Conference, 2011.

The word "identity" means different things to different people. I believe it is futile quoting dictionary definitions in an attempt to disambiguate something like identity (in fact, when a perfectly ordinary word attracts technical definition, it's a sure sign that misunderstanding is around the corner). Instead of forcing precision on the term, we should actually respect its ambiguity! Consider that in life we are completely at ease with the complexity and nuance of identity. We understand the different flavours of personal identity, national identity and corporate identity. We talk intuitively about identifying with friends, family, communities, companies, sports teams, suburbs, cities, countries, flags, causes, fashions and styles. In multiculturalism, whether or not we agree on the politics of this challenging topic, we understand what is meant by the mingling or the co-existence or the adoption of cultural identities. The idea of "multiple personality syndrome" makes perfect sense to lay people (regardless of its clinical controversies). Identity is not absolute, but instead dilates in time and space. Most of us know how it feels at a high school re-union to no longer identify with the young person we once were, and to have to edit ourselves in real time to better fit how we and others remember us. And it seems clear that we switch identities unconsciously, when for example we change from work garb to casual clothes, or when we wear our team's colours to a football match.

Yet when it comes to digital identity -- that is, knowing and showing who we are online -- we have made an embarrassing mess of it. Information technologists have taken it upon themselves to redefine the meaning of the word, while philosophically they don't even agree if we should possess one identity or more.

We don't need to make identity any more complicated than this: Identity is how someone is known. In life, people move in different circles and they often adopt different guises or identities in each of them. We have circles of colleagues, customers, fellow users, members, professionals, friends and so on -- and we often have distinct identities in each of them. The old saw "don't mix business and pleasure" plainly shows we instinctively keep some of our circles apart. The more formal circles -- which happen to be the ones of greatest interest in e-business -- have procedures that govern how people join them. To be known in a circle of a bank's customers or a company's employees or a profession means that you've met some prescribed criteria, thus establishing a relationship with the circle.

[To build on my idea of impressed vs expressed identities, let's acknowledge that the way you know yourself one thing, but the way others know you is something quite different.]

Kim Cameron's seminal Laws of Identity define a Digital Identity as "a set of claims made by one digital subject about itself or another digital subject". This is a relativistic definition; it stresses that context helps to grant meaning to any given identity. Cameron also recognised that this angle "does not jive with some widely held beliefs", especially the common presumption that all identities must be unique in any one setting. He stressed instead that uniqueness in a context might have featured in many early systems but it was not necessarily so in all contexts.

So a Digital Identity is essentially a proxy for how one is known in a given circle; it represents someone in that context. Digital Identity is a powerful abstraction that hides a host of formalities, like the identification protocol, and the terms & conditions for operating in a particular circle, fine-tuned to the business environment. All modern identity thinking stresses that identity is context dependent; what this means in practical terms is that an identifier is usually meaningless outside its circle. For example, if we know that someone's "account number" is 56236741, it's probably meaningless without giving the bank/branch number as well (and that's assuming the number is a bank account and not something from a different context altogether).

I contend that plain everyday language illuminates some of the problems that have hampered progress in federated identity. One of these is "interoperability", a term that has self-evidently good connotations but which passes without a lot of examination. What can it mean for identities to "interoperate" across contexts? People obviously belong to many circles at once, but the simple fact of membership of any one circle (say the set of chartered accountants in Australia) doesn't necessarily say anything about membership of another. That is to say, relationships don't "interoperate", and neither in general do identities.

Posted in Language, Identity, Federated Identity

Let's forget about identity

Here's a radical thought: why don't we Internet engineers forget about identity?

Businesses and individuals identify each other in various ways and to different ends, but always basically in order to manage the risk of dealing with the wrong entity. By and large, we actually do identification pretty well. There are many mature analytical methods and standards by which identification can be analysed and designed, as just one element of risk management.

One of the difficulties in Federated Identity is that it too often pressures participants to change the way they do identification. Now there's nothing wrong with change, and I'm not saying that identity management practices are perfect by any means. But they're changing already. They always have and they always will. What I am saying is that global identification is never going to happen, and neither will global identification benchmarks, like Levels of Assurance. We can think globally all we like but risk management requires fundamentally that businesses will always act locally.

Identification practices undergo continuous improvement under circumstances peculiar to different businesses, industries and jurisdictions. Most industries at some level constantly monitor the adequacy of identification in the face of fraud trends, and make steady adjustments. Some identification protocols are legislated, as in the 100 point check of the Australian Financial Transaction Reports Act and anti-money laundering laws. Some protocols are set by industry overseers; for instance, doctor credentialing is regulated by local and state health agencies with a degree of national coordination. Ad hoc standards (more like habits really) emerge all the time, such as the way so many hotels have taken to photocopying driver licenses at check in. For the most part, identification rules are made up by industry bodies and by businesses themselves to suit their local risk profiles. In general there are no laws that prescribe how employers identify their staff, nor universities their students, nor professional bodies their members -- just as there is no national identity card here.

In going online, several widespread problems in identification have arisen. We all know what the problems are: the inconvenience and cost of repeated registrations; the overhead of managing multiple accounts and often inconsistent authentication mechanisms (multiple passwords, and separately, the "token necklace"); the privacy risks that go with redundant registration information flows and records; identity fraud and "identity theft". These problems are mostly separable and are amenable to improvement without imposing global identity management practices, let alone re-engineering identity itself.

The process of identification boils down to presenting certain pieces of claimed information about the person or entity, and validating those claims. In improving identification in the digital environment, we must focus with more precision on the real problems needing to be solved. And we must avoid wherever possible imposing changes from outside on the way that businesses choose to know their customers, members, staff, partners and users.

Around the world, governments and public-private partnerships continue to strive for big over-arching "Identity Frameworks". I think we need to heed the lesson that Federated Identity is easier said than done. Really worthwhile efforts have repeatedly failed, none more significantly than Microsoft's flagship identity solution Cardspace. I'm positive the underlying problem is simply that identity is not what it seems. Digital Identity is metaphorical; it's not a real thing at all but instead is a proxy for a relationship. And we know that relationships are difficult to carry over across different contexts.

So what's to be done? In my view, a subtle but significant course correction is due. Why don't we drop down a level, forget about "identities", and put our energies into making reliable information about claims more widely available? Fortunately, all the orthodox identity frameworks include Attribute Provision, and let's remember that the Laws of Identity themselves teach that Digital Identities are "sets of claims made by one digital subject about itself or another digital subject". I've discussed elsewhere that the interoperability of IdPs and RPs is more complicated than simply matching Assurance Levels, because it's the details of the elemental claims that really matter. So why don't we stop trying to centrally govern how identities are defined by Subjects and by Relying Parties, and focus instead on improving the mechanisms for conveying the more atomic claims that power those identities?

The diagram shows how a marketplace of verification services could grow around a set of commonplace claims.

Claims Ecosystem Strawman (0 3)

NB: "DVS" stands for Document Verification Service, currently operated by the Australian Attorney Generals Department, which allows state & federal government agencies here to inquire as to the validity and currency of a range of identity documents.

The approach includes many of the standard privacy and security features of higher order Federated Identity systems, such as information hiding APIs delivering only 'yes'/'no' answers to claims queries. But the approach stops short of describing any "identities" per se or characterising "assurance levels" and the like, leaving Relying Parties to continue to set their own identification rules, and to realise those rules by shopping around for claims verifiers that suit their purposes.

The suggested system has the following qualities:


  • It does not impose any identification protocols on businesses, who remain free to select which claims and combinations of claims they want Subjects to exhibit.

  • It does not change the context in which businesses deal with their customers/members/staff/partners/users.

  • It is contestable. While there will be natural authorities (or 'sources of truth') for many claims like driver license numbers or date of birth, the proposal allows for other organisations to offer claims validation. Secondary data sets can be just as reliable (or even more so) for claims such as street address, alternate names etc. Information brokers can be expected to value-add certain claims, attest to baskets of claims, and/or bundle claims validation with other business services.

  • It is much easier to ascribe liability around the validation of precise claims than the validation of "identity"; this approach should be more palatable to banks, government agencies and so on than other Federated Identity concepts where IdPs are asked to underwrite 'who someone is'.

  • It is pragmatic; it avoids semantic technicalities like the difference between "authentication" and "authorization"; the proposal simply provides uniform market-based mechanisms for parties to assert and test elemental claims as a precursor to doing business.

In closing, I'd like to quote Dazza Greenwood on identity:

"Former Speaker of the House Tip O’Neil used to say that all politics is local. Similarly, it can be said that all identity is local as well. Not necessarily geographically local. A parent can have children across the country and a bank for example can have account holders all over the globe. But they are "logically local" in the sense that they are all "home grown" and make sense largely only in their internal context. The account number by which each banking user is primarily known and the attributes surrounding that number are not similar to the naming and identity scheme required by medical clinical systems, for example. One size does not fit all because the subtle contours and content of identity is not monolithic." Ref: Authentication and Identity Management: Information Age Policy Considerations, Greenwood, 2003.

Indeed: identity is not monolithic. We might make much better progress on the digital identity challenges if we dropped down a level and tried dealing with identity's common parts instead.

Posted in Identity, Federated Identity