Just watched Tulsa beat Fresno State in the Liberty Bowl.
Disappointing play by play - seems only fair that if we sponsor the game they mention our identity services framework more often. Maybe something along the lines of 'Man, he lost his privacy on that hit - could have used ID-WSF' or 'I don't think he would have given his consent to being thrown around like that'.
I tried to think of a more 'convergent' name - 'Meta Bowl' sounds too medical, 'URI Bowl' sounds like the Russian Mob bought the game, a 'WS-* Star Bowl' would require an indoor stadium (closed to external influences).
Maybe next year it'll simply be the 'Identity Bowl'. We could get a bunch of no-name players, opaque face masks, use encrypted URIs for uniform numbers. Advertisers would line up.
When you don't have anything nice to say, well then perhaps its time consider a career as an analyst.
Saturday, December 31, 2005
Tuesday, December 20, 2005
RSA Security blamed for failure of many federated identity projects
In an article discussing the challenges involved in federated identity projects is the following classic from copy-editor Hell:
Too often, federation projects suffer from poor motivation/co-ordination with business partners. This may be because the complexity of the options available has been underestimated and is usually RSA Security ......As an ex-Entrust employee, I can't help but take a measure of enjoyment from this typo.
Saturday, December 17, 2005
Geographic persona URIs?
Wired has an article on the possibility of Berlin being awarded a top level domain.
The line that jumped out at me is
Nevertheless, it does suggest the possibility of personalization for such URIs beyond a user being merely able to pick their identifier in some domain.
The line that jumped out at me is
Berlin's businesses and citizens will flock to the domain because millions of people regard the hip European city as a part of their identitiesI suspect that Wired is referring to the potential of Berlin's citizenry liking the idea of a ".berlin" based email address rather than a URI identity (ala OpenID, LID etc) in the new domain.
Nevertheless, it does suggest the possibility of personalization for such URIs beyond a user being merely able to pick their identifier in some domain.
Thursday, December 15, 2005
Newswire: Liberty Alliance Changes Name
The Liberty Alliance management board has voted unanimously in favour of changing its name to the "Liberty URI Alliance".
In a prepared announcement, Liberty Alliance Prime Minister I.P. Roperty stated 'URIs have garnered significant popular enthusiasm in the industry lately. Quite simply, they are hot and we wanted to make clear that the Alliance is completely in favour of them. They are just super. Fantastic things! I fully expect to like them even more when somebody explains them to me.'
Roperty explained further 'The new name simply reflects the emphasis and priority we have always given URIs. In fact we use them all the time. For instance, Liberty's homepage has a URL and that's kind of like a URI right? I myself am considering having my name legally changed to "SAMLart". Or maybe "http://" - I haven't decided yet. Maybe they could be different personas - those are hot too'.
In a prepared announcement, Liberty Alliance Prime Minister I.P. Roperty stated 'URIs have garnered significant popular enthusiasm in the industry lately. Quite simply, they are hot and we wanted to make clear that the Alliance is completely in favour of them. They are just super. Fantastic things! I fully expect to like them even more when somebody explains them to me.'
Roperty explained further 'The new name simply reflects the emphasis and priority we have always given URIs. In fact we use them all the time. For instance, Liberty's homepage has a URL and that's kind of like a URI right? I myself am considering having my name legally changed to "SAMLart". Or maybe "http://" - I haven't decided yet. Maybe they could be different personas - those are hot too'.
Wednesday, December 14, 2005
Is it theft when identity is given away?
BugMeNot is a database of (freely provided) account names and passwords for many sites that require registration. Instead of creating an account, you ask BugMeNot for an existing account and password that will (hopefully) work there. BugMeNot looks through its previously created accounts and returns a pairing for you to use. There is even an Firefox extension to streamline the database query and form fill.
Anonymity through shared credentials.
The FAQ warns that only 'fake' (e.g. some disposable account I might create to read some online whitepaper) accounts should be registered. Nevertheless, people do appear to be registering 'real' (i.e. those for which they receive customized service) accounts.
As an example, using the BugMeNot extension, I was able (after many failed attempts) to access the (non-paid) Last.fm account of somebody named "Zudo***" and view their profile page. I know this was a real account (and not some aggregate reflection of all previous BugMeNot users who had been given this account name and password) because I was able to view which songs they had been listening to over the last week, so they must have installed the Last.fm plug-in into their music player.
Message to Zudo*** - Devo?
Anonymity through shared credentials.
The FAQ warns that only 'fake' (e.g. some disposable account I might create to read some online whitepaper) accounts should be registered. Nevertheless, people do appear to be registering 'real' (i.e. those for which they receive customized service) accounts.
As an example, using the BugMeNot extension, I was able (after many failed attempts) to access the (non-paid) Last.fm account of somebody named "Zudo***" and view their profile page. I know this was a real account (and not some aggregate reflection of all previous BugMeNot users who had been given this account name and password) because I was able to view which songs they had been listening to over the last week, so they must have installed the Last.fm plug-in into their music player.
Message to Zudo*** - Devo?
Tuesday, December 13, 2005
From the mind of a child
I was trying to explain what I do to my 6 year old son.
I presented a scenario of him playing a game at one site and then his high score being made available at some other site he travelled to.
After a pause he said 'So you help them connect?'.
'Exactly' I replied.
'But then what happens when you are sick. Do they just not connect on that day?'
I presented a scenario of him playing a game at one site and then his high score being made available at some other site he travelled to.
After a pause he said 'So you help them connect?'.
'Exactly' I replied.
'But then what happens when you are sick. Do they just not connect on that day?'
Federated log-in & email validation
While playing around with an OpenID identity I received from Videntity, I saw an interesting artifact of the federated log-in mechanism.
At LiveJournal, I opted to sign in with my Videntity Open ID instead of using my local account. Everything worked great, I was redirected to Videntity, there I logged in, and was then redirected back to LiveJournal as my OpenID identity.
However, when I clicked on 'Manage My Account' at LiveJournal, I saw the following
Because my account at LiveJournal was virtual, there was no email that would have been validated through the normal registration process. When I clicked on the 'Not Validated' string, I saw this
LiveJournal didn't have an email for me so it tried to create one.
This is of course in no way specific to OpenID but just reflects how LiveJournal's account management mechanisms assumed an old-style account in which I would have supplied an email at registration.
If I had instead supplied my email to Videntity, then (assuming I authorized its release) it could have been passed to LiveJournal and there would have been a validated email for me (albeit validated by Videntity) for LiveJournal to display.
At LiveJournal, I opted to sign in with my Videntity Open ID instead of using my local account. Everything worked great, I was redirected to Videntity, there I logged in, and was then redirected back to LiveJournal as my OpenID identity.
However, when I clicked on 'Manage My Account' at LiveJournal, I saw the following
Because my account at LiveJournal was virtual, there was no email that would have been validated through the normal registration process. When I clicked on the 'Not Validated' string, I saw this
LiveJournal didn't have an email for me so it tried to create one.
This is of course in no way specific to OpenID but just reflects how LiveJournal's account management mechanisms assumed an old-style account in which I would have supplied an email at registration.
If I had instead supplied my email to Videntity, then (assuming I authorized its release) it could have been passed to LiveJournal and there would have been a validated email for me (albeit validated by Videntity) for LiveJournal to display.
ISSO & Authentication Context
Looking at the i-names SSO (ISSO) spec being defined at XDI.org, they account for some minimum password strengths by which users MUST authenticate to their i-Broker (within the XDI.org community)
To help prevent dictionary attacks, XDI.ORG MUST specify a minimum password strength required of all ISSO accounts in the XDI.ORG network.
As they use SAML 2.0 as the protocol by which the Website requests an authentication and by which the i-Broker responds, it seems strange that they don't refer to SAML 2.0's Authentication Context as the mechanism for defining such minimum authentication requirements.
To help prevent dictionary attacks, XDI.ORG MUST specify a minimum password strength required of all ISSO accounts in the XDI.ORG network.
As they use SAML 2.0 as the protocol by which the Website requests an authentication and by which the i-Broker responds, it seems strange that they don't refer to SAML 2.0's Authentication Context as the mechanism for defining such minimum authentication requirements.
Friday, December 09, 2005
Planet Identity GreaseMonkey Script
I don't like to read my own blog entries at Planet Identity so I created the following GreaseMonkey script to remove my posts.
// ==UserScript==
// @name Ignore Planet Identity Users
// @namespace http://www.planetidentity.org
// @description deletes my blogs
// @include http://www.planetidentity.org/*
// ==/UserScript==
ignorelist = new Array("Paul Madsen", "Other author");
var allDivs, thisDiv;
allDivs = document.evaluate(
'//div[@class=\"entry\"]',
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for (var i = 0; i <>
thisDiv = allDivs.snapshotItem(i);
for(j = 0; j <>
if(thisDiv.childNodes[1].childNodes[0].innerHTML == ignorelist[j]) {
thisDiv.parentNode.removeChild(thisDiv);
}
}
}
Others could use it "out of the box" or adapt as preferred by modifying the ignore list array above.
// ==UserScript==
// @name Ignore Planet Identity Users
// @namespace http://www.planetidentity.org
// @description deletes my blogs
// @include http://www.planetidentity.org/*
// ==/UserScript==
ignorelist = new Array("Paul Madsen", "Other author");
var allDivs, thisDiv;
allDivs = document.evaluate(
'//div[@class=\"entry\"]',
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for (var i = 0; i <>
thisDiv = allDivs.snapshotItem(i);
for(j = 0; j <>
if(thisDiv.childNodes[1].childNodes[0].innerHTML == ignorelist[j]) {
thisDiv.parentNode.removeChild(thisDiv);
}
}
}
Others could use it "out of the box" or adapt as preferred by modifying the ignore list array above.
Thursday, December 08, 2005
Screwy GUI
To access my frequent flier account online I have a 9-digit account number and a password.
For some reason, the Aeroplan Web designers have decided to get creative with the GUI for logging in. Rather than providing a single HTML <input> element, they've divided it up into three separate input elements.
The problem is, Firefox's password manager can only recognize one of the three input fields for form fill.
Consequently, only the last 3 get filled in automatically.
I guess the lesson is that if a request for identity isn't properly posed then the IDP can't respond.
For some reason, the Aeroplan Web designers have decided to get creative with the GUI for logging in. Rather than providing a single HTML <input> element, they've divided it up into three separate input elements.
The problem is, Firefox's password manager can only recognize one of the three input fields for form fill.
Consequently, only the last 3 get filled in automatically.
I guess the lesson is that if a request for identity isn't properly posed then the IDP can't respond.
False sense of Security
I have the following strings of characters to remember in order to access my mortgage account through the Web or phone.
- card number
- Web password
- PIN
- telephone security string
- verbal passphrase
All these for a single account. Of course I write them down. I've complained to the bank that I shouldn't have to and thereby potentially compromise my account. No change. Seems that the perception of secerity is more important than the reality.
I wish I could forget the amount of debt as easily.
- card number
- Web password
- PIN
- telephone security string
- verbal passphrase
All these for a single account. Of course I write them down. I've complained to the bank that I shouldn't have to and thereby potentially compromise my account. No change. Seems that the perception of secerity is more important than the reality.
I wish I could forget the amount of debt as easily.
Imported Authn
In Collapse, Jared Diamond describes the impact of Australia's remoteness from the rest of the world:
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.
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.
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.
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.
Wednesday, December 07, 2005
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.
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.
Tuesday, December 06, 2005
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.
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.
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.
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.
Monday, December 05, 2005
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.
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.
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.
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.
- 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!
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).
Subscribe to:
Posts (Atom)