Wednesday, July 27, 2005

Necessity is the mother of submission

Kim Cameron writes that WS-SecurityPolicy has been published, presumably in anticipation of the formation of the OASIS Technical Committee that will be formed for its progression.
Today WS-SecurityPolicy, which is an important specification needed to build components that support InfoCards, was published

This is the first time I've heard it acknowledged that Infocard's requirements are driving Microsoft's submission schedule. Makes sense for them but why is IBM so willing to wait?

Another key piece of enabling infrastructure for Infocard is WS-Trust and its another of the three being submitted. The immediate relevance of WS-SecureConversation is less clear to me - perhaps Infocard is facilitating the IDP and SP establishing secure session keys?

Additionally, most attention focusses on WS-Trust. But Infocard wouldn't get out of the box as an 'identity selector' if it wasn't provided with the criteria to be used for selecting. This implies policy and that implies WS-Policy (currently missing from the submission) & WS-SecurityPolicy.

Friday, July 15, 2005

Any friend of mine ....

This is a new one for me. A friend/colleague of mine just emailed me to say 'sorry, but I have to disconnect from you on LinkedIn'.

I assumed it was because their employer discouraged employees from participating in such social networks and said so. My friend said 'No, its your network' and then, without giving any real details, simply explained that it was 'personal, but nothing to do with you'.

This of course has me analyzing my network, looking at its members, and making wild guesses as to what sort of horrible and upsetting incident would cause somebody to give up a connection with somebody as dynamic and well-thought of in the industry as I am. A spilled drink at a hospitality suite? Perhaps a cab fare split unequally?

I think I'll wait to share this precedent with my wife - she's never liked my friends.

Thursday, July 07, 2005

Six Degress of SPeration?

The “six degrees” theory contends that any human being in the world can be “connected” to another human being by a path traceable through about no more than six different people.

Early research suggested that the Web's version of the rule was '19 degress of separation", i.e. that any one Web site is no more than about 19 "clicks” away from any other site.

In 2000 however, IBM, Altavista, and Compaq discovered that the Web isn't so connected. When you can get from one to another, it's about 19 clicks, but sometimes 'you can't get there from here'.

The connected Web was found to be divided into four parts (their combined shape usually described as a "bow tie")

- the central, highly connected core or knot of the bow tie, where pages have hyperlinks to *and* from other pages in the core

- one section adjacent to the core (one loop of the bow), where pages have hyperlinks into the core pages but not from them

- another section adjacent to the core (the other loop of the bow), where pages have links from the core pages but not into them

- the tendrils (the straps of the bow tie) abutting the loop sections, where pages have links either into pages that have no link into core pages or from pages that have no link from core pages

This topography results from the Web being a directed graph, connections between nodes have directions. For the Web, its the fact that HTML's <a href=""> mechanism is one-sided.

The network created between sites/providers by the fact of some issuing identity tokens (identity providers) and some choosing to rely on them (service providers) is also directed; one site might issue assertions to another but this is not to say that the reciprocal relationship would exist. Additionally, a site might act as an identity provider in some transactions and a service provider for others.

Consequently, I expect there will be a similar "bow tie" topography for the "provider network". By analogy, there should be:

  • a strongly connected central knot where it would be possible to jump from any one to another (but not for any one particular user)
  • the "IN" loop in which there are identity providers who will issue identity tokens to sites in the central core, but not accept tokens from any in the core (the major portals like AOL)
  • the "OUT" loop in which there are service providers who will accept identity tokens from core providers but not issue them (presumably the vast majority of sites)
  • islands of isolated CoTs

Given that we are starting with isolated CoTs, it should be interesting to see the network evolve. Islands will be connected together through one CoT member establishing the necessary business agreements with a provider in another CoT.

Wednesday, July 06, 2005

When phishers dream ...

Foopad is an aggregation service for social sites - comparable to Yodlee in the financial space. Foopad allows you to mash-up the various social sites like Flikr, 43things, and, agrregating your content from each service into a single interface (using the APIs each of those services offer rather than screen scraping I believe).

It's cool but there is a price. To aggregate your content, you have to enter your account name and password for each service (once more just like Yodlee). Below is the interface prompting me for my account details for 43things.

When phishers dream at night, surely it must be of pulling something like this off, i.e. getting people to present all their account data in a nice tidy package.

Strangely enough, Foopad does seem to recognize the value of a federated model as they are listed as using OpenID between their subsites.

Tuesday, July 05, 2005

Passwords as Global identifiers

There seems to be a perception in the industry that federated identity, in that it connects together previously isolated web sites, will only contribute to the identity theft problem by exacerbating the ramifications of any successful attack. Break one link through a phish or otherwise, and the whole chain is yours (with a little trial and error).

But, most users reuse passwords across the various sites they deal with (the more sophisticated may not exactly reuse the same password but rather have some scheme for generating memorable passwords from some seed and the site name in question).

So, in a sense, the accounts of many users at their different providers are already linked - linked through the duplicated passwords those users have at the different sites.

Vector Addition for Identifiers

Kim Cameron's 4th Law of Identity deals with directional identifiers

A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

As explanation, "identity has direction, not just magnitude".

In math, something specified by both a direction and a magnitude is called a vector and are usually represented by an arrow pointing in the appropriate direction with a length corresponding to the magnitude. Like normal objects with just magnitude (scalars), two vectors can be added together. But, the addition has to take into account the direction of both vectors. To add vector A to vector B, the tail of B is joined to the head of A, the arrow from the tail of A to the head of B is the resultant sum.

The relevance of vector addition to federated identifiers is that 'adding' two identifiers for a user must also take into account their direction, i.e. the provider(s) for which the identifiers are targetted. Federated identifiers only make sense when qualified by the entities that will recognize them and be able to map them into some local account.

In many situations, a service provider may have a shared identifier for a given user with an identity provider and the identity provider may have a (different, when privacy is required) shared identifier with another service provider for the same user. If the first and second service providers are to communicate on behalf of the user, they need a means to refer to that user. Assuming that the two servie providers don't wish to themselves establish a permanent shared identifier, the identity provider can help by mapping from the first identifier to the second. The first provider asks the identity provider for an appropriate identifier to use when talking to the second service provider about the user in question, and the identity provider returns the appropriate identifier that the second provider will recognize (likely encrypted for the second provider).

If the identifier shared between the first service provider and the identity provider is vector A, and that shared between the identity provider and the second service provider is vector B, the mapped (and encrypted result) is logically equivalent to the sum - vector A+B.

This is shown in the diagram (using different terminology - web service consumer (WSC) and web service provider (WSP) for the first and second service providers and security token service (STS) for the identity provider).

Monday, July 04, 2005

Misnomer - by Elisa Korenne

Elisa Korentayer was until very recently a key part of the human infrastructure that keeps the Liberty Alliance running. Elisa served in a variety of roles, most recently as the Program Manager for the Public Policy Expert Group (where, through my interactions with PPEG, I can attest to the incredible job she did).

Elisa has left Liberty to concentrate on her music career (using the pseudonym Elisa Korenne) but, before her departure, she penned the following lyrics (likely after some session on ID Theft)

(c) 2005 Elisa Korenne

Commerce drowns the sorrows
A name makes you a man
I left mine in the storehouse
I go visit when I can
I go visit when I can

Couldn’t see past the windows
Left the X on the map
Then you took my measure and my name
I wish you’d also take the rap
I wish you’d also take the rap

I forgot the password
I forgot the key
I left my name in the storehouse
Now there’s nothing left of me

Now I’m stuck behind the doorjam
This collar is too tight
An old bottle in the hay
A locked door to my right
A locked door to my right

I forgot the password
I forgot the key
I left my name in the storehouse
Now there’s nothing left of me

I left my name in the storehouse
With the Spanish brew and my clothes
Now I sleep in straw and iron
And weep in the watering hole
And weep in the watering hole

I forgot the password
I forgot the key
I left my name in the storehouse
Now there’s nothing left of me

There’s a name for every person
There’s a name for what you pulled
My name now has two owners
Your misnomer’s got them fooled
Yeah, your misnomer’s got them fooled

I feel compelled to mention that, in the Liberty model, mere possession of a federated identifier for a user does not guarantee an attacker the ability to impersonate that user. I expect Elisa intentionally kept well clear of the need to rhyme with 'pairwise opaque'.

Personalized Graphics for Password Fields

Referring to a paper describing a scheme for using 'dynamic security skins' as a defense against phishing attacks, Ben Hyde writes "This is a perfect opportunity for a grease monkey script!"

The following simple script demonstrates the principle of using user-specific graphics to simplify server authentication (while in no way implementing the full system outlined in the paper Ben references).

For trusted sites (mock ones listed below under '@include'), a user-chosen graphic (here my Flikr logo), is used as the background image for the password field. The effect is shown in the graphic above, it's a capture of the password interface for one of my trusted sites with a visual cue to that effect (the alternating purple-bands are an artifact of the dimensions of my logo).

// ==UserScript==
// @name Personalized Password Fields
// @description Displays user-chosen graphic in trusted password fields
// @include https://**
// @include https://**
// ==/UserScript==

function addStyle(css) {
var head, style;
head = document.getElementsByTagName('head')[0];
if (!head) { return; }
style = document.createElement('style');
style.type = 'text/css';
style.innerHTML = css;

var backg = "input[type='password'] { background: url( }";