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.
When you don't have anything nice to say, well then perhaps its time consider a career as an analyst.
Saturday, October 22, 2005
Wednesday, October 12, 2005
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.
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.
Tuesday, October 04, 2005
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
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.
Thursday, September 29, 2005
Intrinsic analysis vs social smarts
Last.fm and Pandora take two different approaches to the problem of helping people find new music that they are likely to enjoy.
Pandora asks you to provide the name of an artist or song as a starting point. Then, based on its prior analysis of the song or artist, it recommends 'similar' songs that meet the search criteria. Amazingly, the analysis of each song is perfromed by humans
The Pandora player streams these relevant songs and allows you to customize with your likes/dislikes. So, you can modify the default recommendation playlist but, out of the box, the default is not targetted at particular users.

Last.fm bases its recommendations as to what you might enjoy hearing based not on any intrinsic attributes of a song or artist, but rather on the proximity of songs to each other in a social space. For instance, if two users share a taste in a particular artist (these tastes tracked by a music plug-in for players that pushes played songs to the Last.fm database and presumably weighted by the number of plays) then the sytem assumes that one user would enjoy listening to other songs in the other user's playlist. What I hear is based partly on what those who are close to me in this "taste space" like to listen to. A refinement of the Last.fm model would allow me to assing greater weight to particular users (Last.fm allows me to identify 'friends' but it's not clear whether they are factored into the recommendation algorythm).
Early comparisons of the success rate, (e.g. delivering me a song that I do indeed enjoy) seems to favour Pandora, perhaps not surprising given the heavy-lifting that has gone into creation of the database. Last.fm's recommendations will likely improve as more and more users join-up so that the current occasional perversions (see below) would be swamped out by numbers.
Pandora asks you to provide the name of an artist or song as a starting point. Then, based on its prior analysis of the song or artist, it recommends 'similar' songs that meet the search criteria. Amazingly, the analysis of each song is perfromed by humans
Together our team of thirty musician-analysts have been listening to music, one song at a time, studying and collecting literally hundreds of musical details on every song. It takes 20-30 minutes per song to capture all of the little details that give each recording its magical sound - melody, harmony, instrumentation, rhythm, vocals, lyrics ... and more - close to 400 attributes!
The Pandora player streams these relevant songs and allows you to customize with your likes/dislikes. So, you can modify the default recommendation playlist but, out of the box, the default is not targetted at particular users.

Last.fm bases its recommendations as to what you might enjoy hearing based not on any intrinsic attributes of a song or artist, but rather on the proximity of songs to each other in a social space. For instance, if two users share a taste in a particular artist (these tastes tracked by a music plug-in for players that pushes played songs to the Last.fm database and presumably weighted by the number of plays) then the sytem assumes that one user would enjoy listening to other songs in the other user's playlist. What I hear is based partly on what those who are close to me in this "taste space" like to listen to. A refinement of the Last.fm model would allow me to assing greater weight to particular users (Last.fm allows me to identify 'friends' but it's not clear whether they are factored into the recommendation algorythm).
Early comparisons of the success rate, (e.g. delivering me a song that I do indeed enjoy) seems to favour Pandora, perhaps not surprising given the heavy-lifting that has gone into creation of the database. Last.fm's recommendations will likely improve as more and more users join-up so that the current occasional perversions (see below) would be swamped out by numbers.
Saturday, September 24, 2005
LinkedOut?
How many invites to refer one member of your network to another have you received? Isn't that the real measure of the value of a social network site, e.g. whether it enables connections to be made that would otherwise be impossible?
My network reflects the relationships I already have. If it doesn't enable something more, it's just a glorified contact book (admittedly one in which I get an interesting glimpse of my friends/colleagues job aspirations trough their assertions as to who they are interested in hearing from :-)).
I like LinkedIn and I enjoy the feeling of nurturing my set of connections through invitations to join, but I can't say I've benefited from the supposed 'network effect'.
My network reflects the relationships I already have. If it doesn't enable something more, it's just a glorified contact book (admittedly one in which I get an interesting glimpse of my friends/colleagues job aspirations trough their assertions as to who they are interested in hearing from :-)).
I like LinkedIn and I enjoy the feeling of nurturing my set of connections through invitations to join, but I can't say I've benefited from the supposed 'network effect'.
Thursday, September 22, 2005
It's a Flat Flat World
Reading Thomas Friedman's The World is Flat- centered on how the lowering of trade, political, and technological barriers now allow people to do business with others located all over the world.
For me, one of the most interesting implications of this gloabl connectivity is how the time zone difference between the different regions can be leveraged and taken advantage for increased productivity and efficiency. Friedman cites US hospitals that, overnight, send X-rays to India where they can be read by trained radiologists during normal (Indian) working hours.
I've experienced this sort of time-shifting first hand. My NTT colleague Yuzo Koga and I are co-editors of a specification within the Liberty Alliance's Web Services Framework. The fact that Koga-san and I are on opposite sides/ends of the world (he in Tokyo, myself in Ottawa) proves a blessing whenever we are faced with an editing crunch. When one of us finishes for the day, he simply sends the latest version of the spec to the other, who is just beginning their work day. There is little dead time where the spec is not being actively worked on. The 13 hours between us allow us to work "together" far closer than we ever could in the same city.
It does seem ironic that the book's chosen metaphor for the new geography is one that would actually make impossible this phenomena - if the world really were flat, then there would be no time zones to shift work through.
For me, one of the most interesting implications of this gloabl connectivity is how the time zone difference between the different regions can be leveraged and taken advantage for increased productivity and efficiency. Friedman cites US hospitals that, overnight, send X-rays to India where they can be read by trained radiologists during normal (Indian) working hours.
I've experienced this sort of time-shifting first hand. My NTT colleague Yuzo Koga and I are co-editors of a specification within the Liberty Alliance's Web Services Framework. The fact that Koga-san and I are on opposite sides/ends of the world (he in Tokyo, myself in Ottawa) proves a blessing whenever we are faced with an editing crunch. When one of us finishes for the day, he simply sends the latest version of the spec to the other, who is just beginning their work day. There is little dead time where the spec is not being actively worked on. The 13 hours between us allow us to work "together" far closer than we ever could in the same city.
It does seem ironic that the book's chosen metaphor for the new geography is one that would actually make impossible this phenomena - if the world really were flat, then there would be no time zones to shift work through.
Friday, September 16, 2005
Tag Clouds (or Cloudy Tags)
Seeingthe new home page of Flock got me thinking about whether anything interesting could be done with tag clouds. I wonder if anybody has tried to game the weighting Algorythms to artistic purposes.
Tuesday, September 13, 2005
Descent by Modification
If I was starting over and could choose a different career path, it would be evolutionary genetics. I guess that's why I find myself constantly looking for related analogies within my current career. And so that's why I found the matrix of SAML 2.0 conformant products (as determined by the Liberty Alliance) so interesting, specifically the feature support of HP and Trustgenix.
The rows for HP's Select Federation products and TrustGenix's IdentityBridge product are identical in the SAML 2.0 feature's they support. Given the number of permutations of possible features (even after accounting for the logical dependencies that would decrease the full number), this perfect overlap suggests a relationship between them, just as the large overlap between the DNA of humans and (for instance) chimpanzees indicates an evolutionary relationship between them.
That's why I was so pleased to track down this press release describing just such a relationship - specifically an OEM one. The two products share the same SAML 2.0 feature support because, in a sense, HP's product is descended from that of TrustGenix (at least with respect to support for SAML 2.0).
I'm not suggesting that we are descended from chimps. maybe that's a shame - pygmy chimps (or Bonobos) do seem have to found a gratifying lifestyle.
The rows for HP's Select Federation products and TrustGenix's IdentityBridge product are identical in the SAML 2.0 feature's they support. Given the number of permutations of possible features (even after accounting for the logical dependencies that would decrease the full number), this perfect overlap suggests a relationship between them, just as the large overlap between the DNA of humans and (for instance) chimpanzees indicates an evolutionary relationship between them.
That's why I was so pleased to track down this press release describing just such a relationship - specifically an OEM one. The two products share the same SAML 2.0 feature support because, in a sense, HP's product is descended from that of TrustGenix (at least with respect to support for SAML 2.0).
I'm not suggesting that we are descended from chimps. maybe that's a shame - pygmy chimps (or Bonobos) do seem have to found a gratifying lifestyle.
Monday, September 05, 2005
Universal Identity Grammar
Reading Steven Pinker's Blank Slate again and revisited the concept of Universal Grammar (first proposed by Noam Chomsky)- the posited common underlying rules/infrastructure on which all the world's various languages are built. The theory is that we all have an innate instinct (a language instinct) for these rules and that, based on which specific language we are exposed to as children, various switches are thrown (determined by the environment in which we are raised) that determine the actual manifestation of those rules (e.g. which language we speak as adults). Its asserted that that is why learning a language as an adult is so much more difficult that as a child, you're fighting against the switches that were set long ago.
Universal Grammar suggests that the underlying structures of language, the grammar, is innate and the same for all humans; different languages are the result of some config file in the head of a young child being set with various binary parameters. The simplest illustration of one of these params is the choice of Head first or Head last; depending on which choice is made, a language is either SOV (Subject Object Verb) or SVO (Subject Verb Object) with many associated orderings in other aspects of syntax. For instance, Japanese is a SOV language and English is typically SVO. In Japanese, the verb always appears at the end of clauses and sentences (a fact which makes my sometimes attempts to learn the rudiments of Nihongo interesting).
Given the recently introduced concept of an identity 'metaystem', the idea of some set of fundamental set of rules and/or components, from which various identity applications can build, seems appropo. Just as languages differ in their particular manifestation of the Universal Grammer, particular identity systems will inevitably vary in their manifestation of the basic underlying components and principles.
I can imagine that in the 'mind' of every young SSO architecture, there is a config file with switches for 'front-channel vs back-channel', 'remote or local storage', '3rd party or self assertions', etc. The specifics of the environment in which that architecture (e.g. B2B, constrained client, privacy requirements, legislative issues) grows to maturity determine how the various parameters are set, and consequently the use cases for which that architecture is appropriate as an 'adult'.
So I guess we shouldn't feel bad about favouring one federated identity architecture over another - it's just that we are adults and our switches were set long ago.
Universal Grammar suggests that the underlying structures of language, the grammar, is innate and the same for all humans; different languages are the result of some config file in the head of a young child being set with various binary parameters. The simplest illustration of one of these params is the choice of Head first or Head last; depending on which choice is made, a language is either SOV (Subject Object Verb) or SVO (Subject Verb Object) with many associated orderings in other aspects of syntax. For instance, Japanese is a SOV language and English is typically SVO. In Japanese, the verb always appears at the end of clauses and sentences (a fact which makes my sometimes attempts to learn the rudiments of Nihongo interesting).
Given the recently introduced concept of an identity 'metaystem', the idea of some set of fundamental set of rules and/or components, from which various identity applications can build, seems appropo. Just as languages differ in their particular manifestation of the Universal Grammer, particular identity systems will inevitably vary in their manifestation of the basic underlying components and principles.
I can imagine that in the 'mind' of every young SSO architecture, there is a config file with switches for 'front-channel vs back-channel', 'remote or local storage', '3rd party or self assertions', etc. The specifics of the environment in which that architecture (e.g. B2B, constrained client, privacy requirements, legislative issues) grows to maturity determine how the various parameters are set, and consequently the use cases for which that architecture is appropriate as an 'adult'.
So I guess we shouldn't feel bad about favouring one federated identity architecture over another - it's just that we are adults and our switches were set long ago.
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.
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.
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.
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 del.icio.us, 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.

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.
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
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).
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)
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'.
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)
Misnomer
(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://*.bank-a.com/*
// @include https://*.bank-b.com/*
// ==/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;
head.appendChild(style);
}
var backg = "input[type='password'] { background: url(http://photos6.flickr.com/buddyicons/25436942@N00.jpg?1110378496) }";
addStyle(backg);
Wednesday, June 29, 2005
Feedback to prevent ID Theft
Researchers at Stanford are looking at ways in which drivers could be encouraged to not speed.
Assuming that this sort of feedback wouldn't do much to discourage a phisher from sending an attack (it would be difficult to convince them to attach electrodes to their fingers for instance), perhaps it could be used to alert the recipient of the potential dangers of "clicking on the URL"?
As the idea of simple visual indicators to show the risk level of emails has been done, perhaps:
The domains covered in the idea space included foregrounding of information to increase awareness, visual and audio notification, providing haptic feedback (accentuating real-world effects), reputation systems (publicizing driver reputation / behavior), offering trade-offs (gas consumption, speeding tickets), rewards and incentives (insurance incentives for monitoring), and playing on emotions.
Assuming that this sort of feedback wouldn't do much to discourage a phisher from sending an attack (it would be difficult to convince them to attach electrodes to their fingers for instance), perhaps it could be used to alert the recipient of the potential dangers of "clicking on the URL"?
As the idea of simple visual indicators to show the risk level of emails has been done, perhaps:
- mouse vibration alerts recipient of risk (maybe for really obvious phsishes the mouse just refuses to work and sits their shaking crazily?)
- paying users to NOT click on URLs in suspicious emails.
- dynamic graphic showing their bank account balance dropping
- publicly listing those who do fall prey
Wednesday, June 22, 2005
Liberty ID-WSF is an identity metasystem
Already with ID-WSF 1.1, but to a greater extent with upcoming ID-WSF 2.0, Liberty's Web Services Framework meets the logical requirements of (at least part of) an identity metasystem.
From Microsoft's whitepaper explaining their vision (my emphasis below):
and
In ID-WSF, the 'technology' that is (currently) allowed to be different between the two providers, and that can be 'translated' to some extent, are security tokens. The web service provider (WSP) can, when it registers its service at the Discovery Service (DS), indicate which security token formats it expects (e.g. SAML, X.509, bearer, etc). When a client WSC) subsequently queries the DS for available services, it can also indicate which token formats it can support. It is the DS that looks for an intersection between the two different sets of security tokens and (acting as an STS) provides an appropriate token format to the WSC for inclusion in its subsequent request to the WSP.
Additionally, the DS may need to perform some translation between the security token that the WSC presents it as part of its discovery query and that which the DS returns to the WSC for inclusion in the request to the WSP. For instance, the WSC may present in its discovery query a SAML 1.1 assertion that it received from an IDP through ID-FF based SSO. If the relevant WSP (that being discovered by the WSC) only supports SAML 2.0 assertions, then the DS will have to translate from SAML 1.1 to SAML 2.0 to ensure that this WSP gets what it needs.
Admittedly, this level of flexibility on security token formats is not the wide-open freedom of different providers being able to choose different protocol stacks. But there is a price to be paid for that freedom.
From Microsoft's whitepaper explaining their vision (my emphasis below):
The Identity Metasystem is an interoperable architecture for digital identity that assumes people will have several digital identities based on multiple underlying technologies, implementations, and providers.
and
The metasystem enables identities provided by one identity system technology to be used within systems based on different technologies, provided an intermediary exists that understands both technologies and is willing and trusted to do the needed translations.
In ID-WSF, the 'technology' that is (currently) allowed to be different between the two providers, and that can be 'translated' to some extent, are security tokens. The web service provider (WSP) can, when it registers its service at the Discovery Service (DS), indicate which security token formats it expects (e.g. SAML, X.509, bearer, etc). When a client WSC) subsequently queries the DS for available services, it can also indicate which token formats it can support. It is the DS that looks for an intersection between the two different sets of security tokens and (acting as an STS) provides an appropriate token format to the WSC for inclusion in its subsequent request to the WSP.
Additionally, the DS may need to perform some translation between the security token that the WSC presents it as part of its discovery query and that which the DS returns to the WSC for inclusion in the request to the WSP. For instance, the WSC may present in its discovery query a SAML 1.1 assertion that it received from an IDP through ID-FF based SSO. If the relevant WSP (that being discovered by the WSC) only supports SAML 2.0 assertions, then the DS will have to translate from SAML 1.1 to SAML 2.0 to ensure that this WSP gets what it needs.
Admittedly, this level of flexibility on security token formats is not the wide-open freedom of different providers being able to choose different protocol stacks. But there is a price to be paid for that freedom.
Thursday, June 16, 2005
Social lists
I use Webjay alot for streaming music. The site allows you to define playlists of (legally) downloadable MP3s. The playlists you create are connected to others that share the same songs. The resulting network is a great way to discover new music - there is a better chance that I'll like a song that somebody else likes if I know that we already share tastes in music.
So I get exposed to lots of great new music and artists. Oftentimes, as I listen, I think 'X would like that' where X is some friend of mine. As it stands now, I manually send an email to X with a link to the song in question. This is less than ideal as there is no record of the connection for future reference and X has to keep track of these sorts of 'invitations'.
I think there is value in the idea of people defining lists (songs, bookmarks, radio stations, geolocations, etc) FOR others rather than themselves.
A system which exposes people to new things (e.g. music, sites, etc) would be valuable - that's the problem with sites like iTunes - you have this wealth of great music that you just know has songs you will love, but but don't know how to get to them.
What your friends think would be interesting "to you" would be a valuable entry point (far more than some untargetted 'Whats popular')
So I get exposed to lots of great new music and artists. Oftentimes, as I listen, I think 'X would like that' where X is some friend of mine. As it stands now, I manually send an email to X with a link to the song in question. This is less than ideal as there is no record of the connection for future reference and X has to keep track of these sorts of 'invitations'.
I think there is value in the idea of people defining lists (songs, bookmarks, radio stations, geolocations, etc) FOR others rather than themselves.
A system which exposes people to new things (e.g. music, sites, etc) would be valuable - that's the problem with sites like iTunes - you have this wealth of great music that you just know has songs you will love, but but don't know how to get to them.
What your friends think would be interesting "to you" would be a valuable entry point (far more than some untargetted 'Whats popular')
Subscribe to:
Posts (Atom)