Imported Authn

In Collapse, Jared Diamond describes the impact of Australia's remoteness from the rest of the world:

with modern globalization, it is cheaper to grow oranges in Brazil and ship the resulting orange juice concentrate 8,000 miles to Australia than to buy orange juice produced from Australian citrus trees. The same is true of Canadian pork and bacon compared to their Australian equivalents.

The economics of the above only make sense for products low in bulk, high in intrinsic value, and, importantly, which can withstand the ordeals of the trip. You ship the concentrated juice and not the fruit; the bacon and not the hogs.

I guess the only thing less bulky than a SAML assertion is an X.509 cert but historically these haven't travelled well - they start to rot in their containers round about the Equator.

Implicit federation

The fact that federated identity connects together the current archipelago of user's identity islands is sometimes presented as enabling (or at least exacerbating) identity theft. The connections are seen as amplifying the consequences of any breach, e.g. a domino effect where one after another of your accounts is compromised.

But, if federated means connected, the different accounts of many users are already implicitly federated through the passwords that they reuse to access those accounts, this percentage of users reported as high as 40% (I confess I do it for "disposeable" accounts). If one account is successfully phished and the password is stolen for that account, it's a fair bet that that user's accounts at other providers will be accessible with the same password.

In addition to making strong and different passwords more useable for the end users, federated identity makes the connections between islands explicit and thereby manageable and controlled.

But, if two currently implicity federated (through shared password) accounts are explicity federated (through SAML 2.0, ID-FF, etc) and the passwords stay the same, then the risk of the implicit federation will remain. I'm sure users would love to be prompted with a request/demand to make sure that the passwords used at the two providers were different.

90210

After months of running in anon mode, I decided to create an account for Pandora, a streaming music service that tailors the stream based on preferred song attributes.

Problem is, you need a US zip code to create an account.


I supplied the only US zip code I knew off hand- it was accepted with no hesitation. I have to believe that there their geographic distribution of listeners would be inappropriately skewed towards Southern California.

Social Tags

One interesting (but admittedly only rudimentarily defined) aspect of Liberty's new People Service is the ability for users to tag the friends, colleagues, and family members (and any groups into which they are placed) that are members of their PS list.

Each friend or group Object can have multiple optional Tag elements, each with a ref attribute carrying a tag value (recommended to be in some established taxonomy like Flickr or Del.icio.us).

Tags are seen as an extra (to the friendly name) axis along which user's can categorize their friends and groups. As an example, if a user created two groups called 'Soccer Team' and 'Hockey Team', both groups could be tagged with 'sports' to make clear their shared relationship (as opposed to placing both in some extra hierarchal level through a 'Sports Teams' group).

Once both groups are tagged, access rights (e.g. allow any of my team-mates, irrespective of sport, to see this video) or group operations (e.g. send a party invite to all my team-mates) can be defined against the tag rather than the individual groups or individuals that have that tag.

We have much to learn here.

Geolocation with no privacy implications

Petscell is a GPS-enabled cell for pets, allowing owners to track the location of Fido.

Remote programmable geo-fence capability. Yes, I'm sure the dog will stop and come home when it gets a call.

Fortunately my children have gerbils - the phone's weight would crush them and I always know where the things are.

Killer Identity App

Judging by the conversations I heard after the Captain turned off the seat belt sign on a trip last week to Austin, there is a killer app just waiting to be built. It needs a slick marketing name but the jist of it is 'Hey, yeah we just landed, see you in 20 minutes, bye'.

Seems that many passengers have family, friends, colleagues who wait anxiously by their phones for just such brief but meaningful status updates.

Liberty's Identity Web Service Framework (ID-WSF) has all the necessary components to support such a system:

- People Service - defines a service by which one user can track those others with which they engage in online interactions
- Geolocation Service - defines a protocol by which the geographic coordinates of a user can be queried
- Subscription & notification - mechanism by which identity info requestors can subscribe to be notified if and when certain criteria are met

So, Frequent Flier uses a People Service to track their relationship with Friend, and then defines access rules at their cell phone provider such that Friend (referenced through the People Service) can see their geolocation. When Frequent Flier surreptiously turns their cell on immediately after touch down, the previously defined notification criteria (i.e. that Frequent Flier's location be within some distance of a major airport) triggers a message to that effect being sent to Friend.

You could even track miles flown for status. Maybe then I wouldn't need to save boarding pass stubs on the chance of my miles not being credited.

Panopticon - an overlooked aspect

Stefan Brands often uses the metaphor of the pantopticon to criticise federated identity models (like one possible manifestation of the Liberty Alliance architecture) in which a user's interactions with service providers are (partially) mediated by identity providers.

Stefan and Sun's Pat Patterson had an interesting discussion on the issue a while back. I won't revisit that - it's undeniable that in the LAP model that the IDP may 'learn', the discussion is to the what (it learns) and the when (it isn't appropriate).

There is another aspect of the panopticon model that gets lost in the 'IDP surveillance' theme. Panopticon refers to a proposed model for prison architecture and process in which inmates were distributed in isolated cells about a centralized watch station. In addition to the intermittent surveillance that was enabled, the architecture ensured that inmates had no contact with each other or prison officials. The theory was that such contact would interfere with the inmates reformation.

solitude is in its nature subservient to the purpose of reformation

Liberty today announced the release of another rev of its identity web services framework. This release includes support for what Liberty is calling a People Service. Bottom line, People Service is designed to allow users to manage their online relationships (e.g. friends, colleagues, and family, etc) such that the various applications that depend on a social layer (e.g. photo sharing, Find a Friend, YASN, etc) can build on a single consistent social network rather than each building their own duplicative version. A bit like a SOAP API into a FOAF repository.

The People Service is a key enabler of cross-principal web service interactions, e.g. those where the identity on whose behalf a request is sent is different than the identity that owns the identity resource in question (some site querying my wife's online calendar but indicating that the request is being sent on my behalf.) A key bit of this release of WSF is defining how the multiple identities in such a scenario are expressed in the SOAP Header.

The (admittedly limited) irony is that the ID-WSF People Service enables just the sort of interactions between individuals that the panoptical model for prison (and hospital) architecture was designed to prevent. No analogy is perfect it seems.

The PS spec is here and there is a whitepaper as well.

InteracOnline

A number of Canadian banks have created a federated payment system called InteracOnline. Consumers can pay direct from their banking account, comparable to debit cards versus credit cards at the cash.

They don't use the term but the claimed benefits for the consumer read right out of federated identity white papers:

• Privacy: you do not need to provide any financial details, card numbers or login information to the online merchant.


• Ease of use: because the payment is conducted through web banking, you don’t need to worry about creating any new passwords or accounts.


• Security: the payment is completed through the Financial Institution you know and trust.

and one I hadn't come across before

• Spending Control: The Interac Online service helps you better manage your finances – you can’t spend more than what you have in your bank account!

That last sounds like a challenge.

Despite the currently small number, there seems quite the mix of participating merchants. Professional curiosity as to implementation, UI design etc will almost certainly require me to conduct further research at one or two of these sites (most likely chosen at random).

Social Navigation

Supposedly, it's easier to just ask someone nearby where you are rather or how to get someplace than using mobile navigation applications - at least until the phone interfaces make this less cumbersome.

Whoever believes this has never asked a random passerby how to get to Ueno Park from Shinjuku in Tokyo. 'Sumimasen, Ueno doko desu ka?' only gets you so far.

Ummmmm Bacon

Andre Durand conjectures that the network is collapsing (in the sense that nodes, be they devices or people, are more easily connected than in the past). With the help of his mathematician father, he explores the rate of collapse, e.g. from year to year how much closer are the nodes. Interesting stuff.

As a starting point, they use what they call 'Kevin Bacon's 6 Degrees Theory'. Problem is, I don't think there is such a theory - this expression conflates two different ideas of small-world research.

The first is the well-known '6 degrees of separation' theory - the idea that anyone on the Earth can be connected to any other through a chain of at most 5 acquaitances. The second aspect is a game called 'Six Degrees of Kevin Bacon' in which Hollywood actors are labelled by their 'distance' from Kevin Bacon, this determined by how many links there are in the chain of co-actors between them and Bacon. So, different actors are said to have different 'Bacon numbers' (just as mathematicians can be labelled by their Erdos number)

But, as far as I know, there has never been a conjecture that the number 6 is in any way special for the Bacon number. A variety of actors will have this for a Bacon number, but many others will have Bacon numbers of 5 and 7.

It's meaningful to explore either the possibility that '6 degrees of separation' is becoming '5 degress of separation' (likely but by no means certain) or the possibility that a given actor's Bacon number decreases over time (it can't get larger) - but seems to me that Andre and his father are trying to combine the two.

Maybe we should define a Cameron Number, e.g. how distant people are from Microsoft's Kim Cameron - this distance defined with respect to blog roll membership (among other possible criteria like shared conference attendance). I don't personally know Kim but nonetheless have a Cameron Number of '2' (thank you Pat Patterson).

QR codes for two-factor authentication

On a recent trip to Tokyo, I was able to see some of the work of my colleagues at the Tokyo NTT Information Platform Sharing Laboratories exploring the potential of two-channel authentication systems. Such systems generally depend on various permutations of secrets shared across both a PC channel and a separate device channel. In essence, the phone serves as a second authentication factor.

Existing two-channel systems rely on either:

1) the client providing a phone number at registration time to which the service provider sends a OTP over SMS when the user logs in. When received by the user on their phone, they then enter it on the PC interface. By verifying the presented OTP, the server can be confident that the user is indeed the owner of the phone and therefore the account holder.

2) the server creating a one time phone number and presenting it to the user through the PC-channel. The user then calls this number from a phone with a previously registered number. The server, by verifying that the call came from a registered number, can be confident that the user is the account holder.

Both systems require that the user's phone number be provided to the server, which presents both privacy and scaleability (the server has to store these numbers) issues. The first relies on the security of SMS.

My colleagues are working on alternatives that:

a) don't rely on a phone number being registered/stored
b) leverage the certificates on many Japanese phones for client-auth SSL
c) authenticate the server as well

In both models above, it is the user that acts as the conduit by which the PC and phone channels are connected (this necessary for them to be correlated and authenticated). In the first, the user takes the OTP from the phone and types it into some HTML form; in the second, the user takes the presented phone number and manually dials it.

The research is exploring the potential for a technology mostly unique to the Japanese market to provide this connection/interface between the two channels. QR codes are two-dimensional bar codes into which can be embedded significantly more information. Critically, over 77% of Japanese phones have support for QR code readers. The phones' cameras can thereby serve as the conduit through which the two channels can be connected and correlated.

The prototype system has the server generate a dynamic QR code and present it to the user when authentication is required. The user uses their phone to take a picture of the code from their PC screen - the phone QR software then extracts the corresponding server address to which a mutual SSL session is established. To authenticate the server, the user sends a short text string from their PC as a nonce that the server signs and presents to the phone.

Below are pictures of 1) a user taking a picture of an on-screen QR code with their phone and 2) the phone display by which the server is authenticated.





The system is attractive because it leverages a (ubiquitous) second factor that users already have and expect to use, requires no specialized client software, does away with the privacy/scaling issue of stored phone numbers, and doesn't rely on the questionable security of SMS.

As Bruce Schneier points out, such systems can't guard against MITM attacks:

An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can't do it himself.

Nevertheless, to say that a technology doesn't prevent one attack doesn't mean they provide no value in defending against others.

Separation of Powers

Separation of powers is the concept within democratic government in which powers are distributed amongst different government organs to prevent any one of them from abusing that power. Along with checks-and-balances (the ability and responsibility of each to monitor the activities of the others), separation of powers is intended to reduce opportunities for tyranny.

Federated identity is sometimes criticized for exacerbating the risk of identity theft through its connection of currently separate identity collections into a greater virtual whole. The argument goes something like:

'So, if I login to the identity provider, I can then access my resources at some other service provider? That sounds nice but what happens if my identity at the identity provider is stolen/phished/pharmed/hacked, can't the thief, because of the connection, immediately jump to the service provider and steal my identity there?'

The argument is based on the assumption that some rogue individual, on hacking the identity provider, can get everything they need in order to impersonate me so that they can access my multiple federated service provider accounts.

Here is the rub though. It does the hacker no good to impersonate me, they have to impersonate the identity provider. As they do not know my various service provider credentials, they have to convince the service provider that they are the identity provider asserting to my authentication status. And, the burden of authenticating one site to another site (not to a user as in phishing) is considerably more challenging for a hacker.

If a hacker is to fool a service provider into accepting a counterfeit assertion for me (and thereby assume my identity at that service provider) it needs to present two things:

1) whatever federated identifier had previously been agreed upon between the service provider and the identity provider for myself. Present a random string and the service provider will refuse access because it won't recognize it as one of its federated users. Even if the hacker were to by chance get lucky and pick a valid identifier, its only valid when presented by the corresponding identity provider. see 2) below

2) a signature over the message carrying the above identifier associated with a key trusted by that service provider. Not any key issued by Verisign will do, the service provider will certainly keep a list of 'trusted IDPs' and if the associated key is not on the list then you are not invited to the party.

If the identity provider does things "right", then it will ensure that it is very difficult for any one entity (internal or external) to steal both of the above (it will almost certainly make it difficult to steal either as well). A "good" identity provider will implement "separation of powers" to ensure that, were one of the above was stolen, the other wouldn't be.

You can fool such an IDP once, but likely not twice.

"There's an old saying in Tennessee — I know it's in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can't get fooled again." —President George W. Bush, Nashville, Tenn., Sept. 17, 2002

It's a Mad Mad World

In the Cold War, Washington advertised one policy for the use of its nuclear weapons while privately holding a very different strategy.

The visible & public policy was referred to as Assured Destruction (the 'mutual' was later added by a critic to create a more derisive acronym). AD was the idea that the only sane application of nuclear weapons was a non-application - if both sides were completely confident that they would be destoyed in any altercation they would be unwilling to strike first, and so nuclear weapons would never be used. The opposing counterforce strategy (which Qwynne Dwyer in his book War claims Washington actually held even whilst professing AD) saw such weapons providing value above and beyond their deterrent effect through their potential delivery in a controlled and constrained manner in a conventional war .

So, the "real" policy was much less restrictive in its criteria governing the 'release' of the ICBMs. While AD was based on the premise that one side's missiles would only be lanuched in retaliation to a first strike from the other side (stringent criteria) - the counterforce policy asserted that weapons could be deployed in a range of situations, e.g. in a tactical manner even as part of a convential non-nuclear altercation (relaxed criteria).

(This is the exact opposite of what I might have expected, e.g. a public bluff of aggressiveness but a more realistic and sane private plan. Of course, there were vested interests involved for which the status quo of maintaining weapon expenditure was desirable)

I wonder if the idea of different public/private policies is relevant for any policy governing release of identity information? Would a provider claim to be governed by one policy whilst actually listening to another?

If the visible policy were less stringent than the actual, the provider would receive attribute requests that would be immediately rejected - requests that would not have been sent if the advertised policy were accurate. Beyond the inefficiency, this is a privacy leak as the provider would unnecessarily learn at which requestor sites the principal had been visiting. If the advertised policy were more stringent, then the requestor might not even send requests that would be approved had they been - doesn't seem much risk (or sense) in this.

Bidirectional PII leakage

Motivated by a spate of fiascos and consequent legislation, enterprises are currently focussed on ensuring that any privacy sensitive data they may hold about individuals doesn't leak out.

Given the risks of damage to reputation and liability associated with storage of such data, how long is it before enterprises worry just as much about not allowing PII to leak in?

Ben Laurie suggests that one tenet of privacy-respecting identity management is minimalism, i.e. that only that identity information required for a particular application be shared and no more. He describes it as a principal for the protection of the individual - which it is of course.

But, it's also protection for the data requestor/recipient. Unless it has an immediate and (business)justifiable need for some piece if identity information, why ask for it, or even accept it if not requested but nonetheless offered? Or store it past any usage? Better let some identity provider, presumably with a business model and corresponding security technology and processes take the burden and risk.

Just remember to log that you didn't accept it.

SP Collusion

Dictionary.com defines 'collude' as

'To act together secretly to achieve a fraudulent, illegal, or deceitful purpose; conspire'.

In the context of identity management, the term is typically used to refer to multiple providers communicating together about some principal without that principal's consent.

If each provider stores some aspect of a given principal's digital identity - collusion between them is made possible if the nature of such identity information allows them to infer that it is the same individual with which they both have accounts.

Federated identity management, if done improperly, can enable collusion by simplifying the correlation burden for the rogue providers. This because, valid (e.g. based on informed consent) connections between the two providers and some other third provider can provide to the rogue providers the necessary correlation keys.

Federated single sign-on (SSO) can be used to explore the dangers. In SSO, a user authenticates to an IDP, and then the IDP creates claims to that effect for use at other SPs. Correlation and collusion is enabled if the claims are not created carefully. If the same user presents two different claims to two different SPs, the SPs might be able to correlate the claims as referring to the same principal through any of the following mechanisms:

A common identifier in both claims, e.g. if an email address or SSN is used to identity the subject for which the claim was generated. SAML 2 and Liberty address this by defining mechanisms by which identifiers unique to each IDP-SP pairing are established and used.

sufficiently identifying attributes, e.g. if both claims describe me as male, 41, working on identity management, living in Canada, tired father of 3, then the SPs would be able to infer that their different local acocunts referred to the same user, me.

small-community IDP, e.g. if both claims are issued by an IDP known to only issue claims for a small community of end users, then the SPs can narrow down their focus. If the IDP is associated with a single principal then its trivial.

temporally, e.g. if the two SPs somehow knew that the nature of some other application required real-time data from both of them, then perhaps they could use the timing of the requests to correlate. For instance, one SP is a calendar service, another a shipping service. If both SPs received a request for one of their user's data within some window of time from a home grocers site, then the two SPs could infer that their two users might be the same. If it happened again it would be confirmed.

keying material, e.g. if the keys used to ensure HOK subject binding were to be reused for the two SPs, then they could correlate based on that.

I'm sure there are others.

SSSO - Social Single Sign On

There is nothing social in default SSO. There is a single user and he/she, based on an authentication performed at some identity provider, is granted appropriate access for their own resources at some service provider. There would seem to be some unexplored social (i.e. more than a single user involved) aspects of SSO.

For instance, a user may be SSOing in to access resources belonging to another user. If I define the permissions at some online photo site such that certain friends can see my recent photos; if and when those friends log-in to that photo site they will be granted those privileges. If they log-in with an account local to the photo site then its very straightforward for me to define privileges against the corresponding identifier and for the site itself to enforce them. This is how sharing currently works at such sites.

However, if they don't have such an account nor desire to create one, they will want to access my photos based on an authentication performed elsewhere, e.g. SSO in to the photo site. The challenge now becomes how the photo site gets an identifier for the friend to which the privileges can be assigned and how users can track and manage the social relationships relevant to their online interactions. The Liberty Alliance People Service is designed to facilitate this.

Another social angle comes from the fact that, in many situations, the nature of the credential by which a user authenticates to an IDP is such that the IDP can't unambiguously identify them as individuals. For instance, when I access the Net from my home PC, my ISP knows only that I am one of the family members with access to that PC. Based on that shared credential I should be able to SSO to some SP and be granted permissions appropriate to mmy family, but not to any particular member. So, I might be able to see the family's calendar but not my personal one (at least not until I re-authenticated with a credential that did allow the IDP to unambiguously identify me and make an assertion to this effect to the SP).

False claims?

Will an identity system allow me to lie?

I (and I expect most others) often provide false data to sites asking me for personal data. I'm more likely to do so if the site is asking me for specific identity information as opposed to some range. For instance, if the site asks for my birth date (or even age) it's very unlikely that I'll give the actual date (unless it will eventually serve as some credential). If instead, the site provides me a set of ranges of ages from which I can select I am far more inclined to be truthful.

Now, if an SP were to ask an IDP of mine for my age rather than me directly, what happens if the SP and request are such that I don't want the IDP to provide the real value. Does the IDP provide a value from a persona I've set up just for such requests? What is the meaning of such an assertion if there is another persona with my real age, i.e. is the IDP asserting to the truth of its claim or merely to the fact that its asserting a value previously supplied by me?

Seems to me that the problem with the current status quo of sites asking for my age is that there is no 'fall-back' option, e.g. if I want to proceed with setting up the account or purchasing whatever, the HTML form requires me to provide a value for the field. There is no negotiation possible, no leeway in the site's identity demands and consequently I respond with the only option that satisfies both this demand and my desire for privacy - I lie.

In the brave new world of identity, perhaps there is no need to lie. If an SP asks my IDP for my age, the IDP might respond with 'Why do you need it?', to which the SP would say 'Demographic study', so that the IDP would finish with 'Well then his age range of '35-45' will be sufficient'. Because there needn't be a binary yes/no for release of identity data, but a negotiated middle-ground, its more likely that both the SPs and mine can be satisfied.

Airport Perimeter Security

Leaving Singapore the other day at Changi Airport, I saw different model for security than what seems to be default of a single security checkpoint (e.g. X-ray machine and wand-waving, body-frisking attendants) for all gates.

At Changi, you don't go through security until you reach your gate, each gate has its own security checkpoint. The advantages of centralizing security seem clear - so I started thinking as to what might the advantages of this distributed model.

Theoretically possible would be security customized to the destination, e.g. for flights to political hotspots, full rigour (e.g. laptops get sniffed, every bag gets checked, random body searches, etc) for other destinations, less intrusive security. Travel to such 'safer' destinations wouldn't pay the price of security appropriate to riskier destinations. I don't know if they actually do this.

I saw a specific example of another advantage. As we moved through security at the gate for my flight to Tokyo, the traveller just in front of me was informed by the personnel that he was at the wrong gate. This sort of application-layer check isn't possible with the centralized gatekeeper security model - the gatekeeper doesn't have the application details and so can't apply security based on them.

SPeciation

In evolutionary biology, speciation refers to the process by which different species emerge out of some common ancestor. Species are defined by the ability of their members to interbreed successfully (this measured by creating viable offspring) so the emergence of two species from a single common stock implies that some genetic separation be established where there was none before.

By this criteria, SAML 1.1, Liberty ID-FF 1.2, and Shibboleth were not different species as the three of them participated (I hesitate to use a more common phrase for such co-operation) in a furious orgy of successful interbreeding to create SAML 2.0.

p.s. Evolutionary science has another term that those more cynical than I might apply to other creatures participating in the current Malthusian struggle to pass on their identity management genes.

Ning Identity

Ning describes itself as a playground for creating social apps. It provides a common layer of registration, authentication, tags, feeds etc onto which people can build a variety of socially-aware apps (e.g. Zagat-like restaurant reviews, Flickr-like photo sharing, etc). To enable the creation of new apps, developers can clone existing applications, and then tinker with the PHP to tailor as required. Much like 'View Source' for HTML/Javascript.

The SSO across all these apps is interesting. As its based on a 'global' identifier, the implication is that Ning would be able to correlate any one user's actions/identity across all these purportedly different applications.

It appears that Ning acknowledges this as a concern because the FAQ has the following

I want to use different email addresses and identities for different apps. Can I do that without creating two accounts?

Not at the moment. For now, you probably should just go ahead and use one of the many free email services that are happy to give you as many free email addresses as you want.