Friday, May 25, 2007

Turing would be proud

From Don Park, reCAPTCHA.

About 60 million CAPTCHAs are solved by humans around the world every day. In each case, roughly ten seconds of human time are being spent. Individually, that's not a lot of time, but in aggregate these little puzzles consume more than 150,000 hours of work each day. What if we could make positive use of this human effort?

I claim precedence for the idea of leveraging identity operations. My legal representatives will be in touch.

Best phish address ever

Hiding behind '' in a mail message was this beauty (line breaks for readability)


2 'https'? Well that has to be secure.

That plus the fact that its for Canada reassures me that it will be safe to click ....

Thursday, May 24, 2007

Checks and Balances

Doesn't the principle of 'Separation of Powers' forbid Kim playing both the legislative and judicial roles, i.e. writing the 'laws', and then adjuticating on compliance?

Certainly makes for efficient government.

Wednesday, May 23, 2007

Thursday, May 17, 2007

Liberty Alliance - 50% less evil

Lots of people seem to really hate the Liberty Alliance.

It used to get to me, but then I said to myself 'It's not YOU that people hate, it's your colleagues', and then I felt much better.

As Pat points out, even my Liberty colleages are actually not really that bad. I mean, it's not like they're all Irish right?

Bottom line, I think Liberty needs a new marketing campaign that hilites our values, our ethics, and all-around goodness.

While considering that, why not take a break from your busy day and spend some time focusing on our logo?

There goes the neighborhood

This summary is not available. Please click here to view the post.

What's next?

Numbers as art.

Currency as art.

Alphabet as art.

Links as art.

Command line as art.

How long before we have identifiers as art?

Wednesday, May 16, 2007

OpenID - OP first

In describing the supported identity flow patterns for various identity systems, Ping ID's paper omits the support for the IDP-initiated 'portal' use-case that OpenID 2.0 introduces.
Note: Relying Parties SHOULD accept and verify assertions about Identifiers for which they have not requested authentication.

Note: I'm interpreting the above as designed to enable both the OP returning a URI different than that requested, as well as the 'OP initiated' flow I'm discussing here.

In this flow, the user starts at the IDP/OP and requests to be sent to a particular RP (along with an 'assertion' as to their log-in status) rather than starting at the RP. (this was the only flow supported by SAML 1.1, it's interesting to see OpenID & SAML converging from different directions.)

How would this flow work in OpenID? Specifically, how would the OP know where to send the user's browser? In the default OpenID RP-initiated flow, the RP indicates to the OP this address with the openid.return_to parameter.
Value: (optional) URL to which the OP SHOULD return the User-Agent with the response indicating the status of the request.

In the case where there is no request coming from the RP from which the return address could be extracted, where should the OP send the User-Agent?

In SAML's IDP-initiated flow, the SAML IDP can obtain the 'AssertionConsumerService' endpoint URL from the RP's metadata.

OpenID has XRDS for metadata, but AFAIK, the model presumes that the user provides their OpenID to a RP - this identifier used to retrieve the list of services and endpoints from the XRDS doc. Could an OpenID user's XRDS document also list the RP endpoints to which unsolicited responses would be sent? Would a user need to remember their RP URIs so that the OP could ask them "Where do you want to go today?

In the same vein, how would an association be established between RP and OP - given that the OpenID 2.0 association mechanism presumes that the RP initiate the DH sequence?

Could it be that, for this OP-Initiated sequence to work, the RP and the OP must necessarily have previously shared endpoints and keys/trust information? Would this 'scale'?

Tags: ,

That is so like him

Motivated by a thread on 'reputation' (i.e. what it is, what it isn't) on the ID Gang list, I found Phil Windley's paper on Pythia - described as a 'general-purpose framework .... for building reputation systems'.

Very interesting reading. Hilites were

Reputation is calculated. For our purposes, reputation can be represented as function:

Ru = Frp(Iu,Txu,u',Eu)


rp is the relying party's identifier
u is the user id
u' is all users
Iu is a vector of verified identifiers for u
Txu,u' is a vector of transactions between u and every other user in the system
Eu is a vector of ratings and endorsements for u
This captures for me the two fundamental aspects of reputation, namely
  1. that a reputation is calculated or estimated.
  2. that a 'Y's reputation for being X' is determined by aggregating the opinions of many other Z's on 'just how X Y actually is'. If there is just a single Z in the calculation, then that's an opinion, not a reputation.

Later on
The framework is identity system neutral. Pythia is not an identity system, but is meant to rely on one or more existing identity systems for authentication and user IDs. As implemented, Pythia uses OpenID as an authentication mechanism, but other authentication systems could also be used.

I can easily see Liberty's ID-WSF applied. Instead of the reputation request being set over a RESTful API, it would be sent as an SOAP message. Other than that, the model would be the same

A reputation request consists of a digital identifier representing the relying party making the request, the digital identifier representing the subject of the request, and a rule set identifier. To complete the request, the reputation server looks up the rule set requested by the relying party and executes that rule set for subject of the request. The result of the reputation calculation is then returned for the relying party to act upon.

Likewise for the feedback mechanism.

The paper uses blog commenting as a representative use case. The model is that reputation of the erstwhile commenter feeds into the access control decision on whether their comment should be accepted. There are lots of similar use cases in which the user in question is online and attempting to 'do something', e.g. see pictures, add to calendar, etc.

Are there use cases where the reputation of a user is required, but that user isn't themselves online and initiating the transaction? How about:

'Find the current location of all geocachers within 10km of myself with an 'environment friendly' score greater than 9'

'Find me all sys admins looking for work with a reputation for being a workaholic exceeding 75%'

What a stupid prize

What am I supposed to do with 1 million lbs? And even if I wanted the weights (maybe for a gym?), how expensive would it be to ship them over to Canada? All together, they'd weight almost a .... well they'd weigh alot I bet.
60 Merriman Road
London SE3 8RZ

Ref. Number: BTL/491OXI/04
Batch Number: 12/25/0304
Ticket Number: 564 75600545-188
Serial Number: 5388/02




BRITISH LOTTERY, officially bring to your notice the final draw result of April 2007 BRITISH LOTTERY-wheel E-game which was conducted at our international corporate office complex in The United Kingdom.

Your e-mail address attached to ticket number 56475600545-188 with serial number 5388/02 drew lucky numbers 7-14-18-31-45, which consequently won in the 1ST category, you have therefore been approved for a lump sum pay out of 1,000,000.00Pounds (ONE MILLION POUNDS STERLING).CONGRATULATIONS!

The selection process was carried out through random selection in our computerized email selection system(ess) from a database of over 250,000 email addresses drawn from which your Email was selected.

For the release of your winning, kindly contact your claims officer at the The National Lottery Head Quarters via bellow informations:

Mr Powell Paul
Payment and Release Order Dept.
Phone: +44-701-112-9582
Fax : +44-707-5055521


On second thought, I go over to the UK on average a couple times each year ......
Tags: ,

Tuesday, May 15, 2007

Product Placement

I haven't been able to get into the Beta to play around, but Vidoop is an OpenID provider that authenticates users with one of those picture grids.

The interesting twist is where the (or at least some of the) pictures for the grid come from. Vidoop allows sponsors to buy grid spots for their pics. I guess the hope is that advertisers will pay for product placement to get in front of user 'eyeballs' during the login process.

  • During the act of logging in, I personally often find myself thinking "I have disposable income, why can I not think of things to purchase?". So this is perfect for me.
  • Advertisers could pay MITM phishers for picture placement as well. That way, the user would be guaranteed a consistent visual experience and not be unsettled by unfamiliar photos.
  • As big advertisers push out smaller companies for the ' real estate', the 3x4 grid will evetually consist of 7 car models, 4 cans of pop, and a Viagra pill. Maybe Volvo and Sprite will enter into a deal whereby their pics always get displayed together? Or maybe Ford pays for 4 grid spots?
  • Vidoop can up-sell a social network to its users, e.g. 'You've chosen the same pics as these other users, would you like to add them to your Login Buddys?'
  • I wonder what they'd charge me for placing my headshot. My marketing people are always telling me I've got almost no brand recognition amongst 15-24 year olds.

Monday, May 14, 2007

Damn you !

It's rare that I don't perceive my Canadian-ness as 100% goodness. Today I'd have to say it's down in the 80s.

Dear Pandora listener,

Today we have some extremely disappointing news to share with you. Due to international licensing constraints, we are deeply, deeply sorry to say that we must begin proactively preventing access to Pandora's streaming service from Canada. We began blocking access from almost all countries outside the U.S. last week and had originally hoped to maintain access to Canada. However, it has become clear in the last week that we just haven't been able to make enough progress to continue streaming.

It is difficult to convey just how disappointing this is for us. Our vision remains to eventually make Pandora a truly global service, but for the time being, we can no longer continue as we have been. As a small company, the best chance we have of realizing our dream of Pandora all around the world is to grow as the licensing landscape allows.

We show your IP address is '', which indicates you are listening from Canada. If you believe you are seeing this by mistake, we offer our sincere apologies and ask that you please reply to this email.

Delivery of Pandora is based on proper licensing from the people who created the music - we have always believed in honoring the guidelines as determined by legislators and regulators, artists and songwriters, and the labels and publishers they work with. In the U.S. there is a federal statute that provides this license for all the music streamed on Pandora. Unfortunately, there is no equivalent license outside the U.S. and there is no global licensing organization to enable any webcaster to legitimately offer its service around the world. The volume of listening on Pandora makes it a very expensive service to run. Streaming costs are very high, and since our inception, we have been making publishing and performance royalty payments for every song we play.

Until last week, we have not been able to tell where a listener is based, relying only on zip code information provided upon registration. We are now able to recognize a listener's country of origin based on the IP address from which they are accessing the service. Consequently, on May 16th, we will begin blocking access to Pandora to listeners from Canada. We are very sad to have to do this, but there is no other alternative.

We will be posting updates on our blog regarding our ongoing effort to launch in other countries, so please stay in touch. We will keep a record of your existing stations and bookmarked artists and songs, so that when we are able to launch in your country, they will be waiting for you. We deeply share your sense of disappointment and greatly appreciate your understanding.

-Tim Westergren
(Pandora founder)

This is a one time account message

Cache Economy

Microsoft's Vittorio Bertocci discusses caching in Cardspace - and what may or may not be possible given Cardspace's security model (e.g. token encryption etc).

Vittorio doesn't emphasize it, but the IDP & SP may have their own policies as to whether caching is appropriate, e.g. the IDP may not want a token they issued to be cacheable, and an SP may not be willing to accept such a token.

Liberty's Advanced Client makes this explicit by having the client specifically request a SAML assertion for caching.

Waldo deserves privacy too

Ben Laurie asks 'Is Liberty User-centric?'.

A year ago I would have stridently and vehemently defended Liberty's architecture, shouting to the rooftops the justification as to why indeed it deserved the 'user-centric' moniker.

I've moved on, I'm past caring. Countless discussions and ID Gang threads notwithstanding, there is still no industry accepted set of criteria as to just what 'User-centric' is. It's the 'Web 2.0' of identity, everybody seems to have a feeling for what it constitutes, but nobody agrees on the specifics. Like Justice Potter Stewart, maybe we need to fall back on a 'I know it when I see it' methodology.

If Ben's question had instead been phrased as 'Can Liberty's architecture enable meaningful control for users over their identity?', then we might be able to have a useful discussion (brief synopsis, Ben will argue that the answer is 'no', I'll take the counter position).

Ben argues that automated discovery mechanisms, like in Liberty's ID-WSF, are incompatible with user-control - as they would diminish the user's ability to manage the discovery of their identity services.

Responding to a comment of mine where I suggested (with a certain amount of tongue in a certain amount of cheek) that the alternative to such automated discovery would be users deluged in post-it notes with scribbled URLs, Ben writes

Of course, the users won’t be managing their data by such primitive means. Their computer(s) or their chosen service provider(s) will do all the legwork.

I'm lost. A 'chosen service provider' doing 'all the legwork' is exactly the model that Liberty enables (but not dictates). In ID-WSF, a user chooses where they want their various identity slices to be held, and then also designates a Discovery Service provider that will do the 'legwork' of facilitating the discovery of the various services if and when necessary.

How is this different than an XRDS document listing a user's various identity services? The user chooses both a) where they store their identity, as well as where b) they store the XRDS document pointing to all the a's.

On the topic of 'selective disclosure', I'd love to learn more and explore how ID-WSF could carry selective disclosure tokens. Perhaps the scenario is using ID-WSF to get the necessary tokens to the client, with the selective disclosure protocols (over a SOAP Binding?) taking over at that point? I'm sure Ben has a better take on what might be involved. Perhaps Concordia is a forum for discussions.

In his selective disclosure paper, Ben uses a nice analogy to explain the principle. But shouldn't Wally/Waldo be given the ability to control how his geolocation is shared?

The Power of Language

On a Google Tech Talk video, Aza Raskin talks about his company Humanized's HCI product called Enso. He describes the model as

using the power of language to move around your system

With the Enso launcher running, to go to Google's home page a user just types 'Go Google' with the Caps Lock key held down. If Enso has been appropriately trained, the browser opens and you're there.

Why not applied to identity operations?

Hilite a URL, hold down Caps Lock and type 'Go SSO persona gaming'. After authenticating to their IDP, the user would be taken to the corresponding SP with an assertion carrying a transient identifier and attributes describing their online game playing.

Or, a user hilites a picture of a friend and types 'Go add colleague', or 'Go add mistress' as appropriate.

For those who want identity operations to be as difficult as possible, before proceeding with the requested transaction, the system could require that the user
  • answer a math question
  • compose a haiku
  • define user-centric identity

This way we keep out the riff-raff.

Friday, May 11, 2007

Liberty & Silos to Wed

In an objectively titled post 'Liberty Loves Silos', Ben writes
Liberty thinks you need discovery because they think it is both inevitable and correct that all your data should live in silos, beyond your control, and ideally where you can’t see it.

For Ben, it's the perceived fact that, in the Liberty architecture, the user is unable to exercise control over their various pieces of identity that makes silos, rather than whether or not the identity data can be shared amongst providers in a secure & privacy-respecting manner.

Ben points to Liberty's mechanisms for discovery as proof of his conjecture. If the user is in control of their identity, why would there be a need for automated discovery, just ask the user. So, as Liberty supports discovery mechanisms that do not rely on active user intervention, the user must be unable to exercise any meaningful level of control. QED.

Here's my take, Liberty DOES love silos, because without silos (e.g. identity attributes living in distributed and disconnected stores) there is no value for an architecture (ours or any others) that aims to tear down such silos.

Liberty's ID-WSF is built on the following assumptions

1) Users keep their identity where they want to.
2) The 'where' can be 3rd party identity providers as well as local storage (e.g. devices).
3) It's highly unlikely that all aspects of identity will be maintained at the same provider, i.e. there will be multiple 'wheres'.
4) Most users don't want to be responsible for facilitating identity sharing by themselves providing the 'where'.
5) Experts will misinterpret 1-4 to suit whatever is their current competitive positioning.

#1-4 motivate a discovery mechanism for identity attributes. #5 is tiresome.

Ben's post title makes me think of that classic grade school tease.

Liberty & silos, sitting in a tree
Liberty & silos, 'd' 'e' 's' 't' 'r' 'o' 'y' 'i' 'n' 'g'
First comes SSO
Then comes services
Then comes silos feeling nervous

Update: A blogger with less refined ethics than I would link to this.
I'm proud of myself for keeping to the high ground.

Update 2: Pat uses assonance to good effect.

Thursday, May 10, 2007

Provider Metadata

Mark Wahl looks at

whether metadata, in particular attributes or claims supported by a service, can be discovered, if the site's service supports one of the cross-organizational identity protocol families:

Mark includes how, in Liberty Alliance ID-WSF, the identity provider metadata is communicated using a WS-Addressing EndpointReference (EPR). But, in the table where he summarizes mechanisms by which Service Provider metadata is shared, he omits the ID-WSF column.

There are however ID-WSF scenarios, and supporting mechanisms, in which SP metadata is shared. For instance, when subscribing for notifications regarding some attribute of a particular user, an SP can specify the endpoint (once again as a EPR) to which it desires those notifications be sent.

Putting meat on meta

The Liberty Alliance Concordia program is collecting 'metasystem use cases'.

As I see them, any use case that accounts for more than a single identity system qualifies.

So far, I see categories of
  • Systems X and X' are both candidates in a given situation, which to use?
  • Systems X and X' have to be sequenced, how to facilitate this?
  • Systems X and X' are used within the same context, how to create a consistent experience across them?

A friend indeed

A friend of mine, knowing what I do (and almost certainly trolling to get this blog post) sent me the following message
I have recently developed an interest in remote control planes. I joined an electric RC flying club and was invited to their Yahoo chat group. I had to register as a new user. I thought the idea of a ‘seal’ as an anti-phishing mechanism was quite clever. I had never heard of that before. Allowing the user to personalize their seal with a picture of their choice is also a good idea as it gives the user the feeling that they have some control in the whole matter. Overall, a very good experience.

With typical insight, I replied
yeah, but see

His hurried response

Different I would say. A picture of Son 1 and Son 2 showing up every time I log into Yahoo is much more effective than a bogus error message. What you are describing sounds like a pain in the butt.

My closing argument

the issue is whether users can be conditioned to expect a certain 'login ceremony' to a sufficient point where, should a subsequent experience be different than that to which they've been trained, they will be alerted.

users are amazingly accommodating to the vagaries of the internet, they've been trained to expect to see hiccups and glitches.

If you were to go to a site that purported to be Yahoo and that showed a blank square instead of the boys pics, and had a message of 'Yahoo apologizes for the technical difficulties, please proceed as normal'. you would probably go 'Hey whoa there'. Most users wouldn't

Notwithstanding what I told him, my friend would of course click away unsuspectingly. It's the same gullibility that makes him so vulnerable to my moves on the ice.


A central tenet of user-centrism is typically expressed along the lines of
users choose their identifiers, it's not handed to them by Da Man.

In my own experience, I've taken advantage of the great freedom this provides by choosing to preface all of my OpenIDs with 'paulmadsen'. Those 'Paul Madsens' that follow me will of course have to resort to the normal trickery, (e.g. 'paulmadsen2012', 'newpaulmadsen', etc.) when creating their own OpenIDs.

I've seen no details yet, but I'd be willing to bet that Sun employees will not be choosing their own OpenIDs.

Another key piece of OpenID functionality is delegation - the ability for a user to show one URI, but to authenticate elsewhere. Will Sun support this? i.e. allow an employee to continue to present a non-Sun OpenID to RPs, but to delegate this back to Sun for authentication? or allow an employee to delegate their Sun OpenID to an existing external OpenID? The former possibly, the latter almost certainly not.

Neither will employees be able to keep their Sun-issued OpenIDs once they leave the company (given the semantic of employment status ascribed to the identifiers).

Will employees opt-in for the program, or rather simply be presented after the fact with their new URI? (I contend that my customer agreement with AOL gave them no such freedom, does Sun's employment contract?)

My view is that Sun's deployment of OpenID (which I predict will be called OpenOpenID) should not be considered user-centric (not that I've seen anybody make the claim).

Here is my point. Is it possible (and I mean no offense) that OpenID, as a technology, cannot guarantee user-centric deployments? Indeed that no identity technology can?

On the other hand, is it conceivable that other technologies, inevitably labelled/pigeon-holed as 'enterprise only' by the 'user-centronoscenti', could be deployed in a user empowering user-centric manner? Again, no offense meant.

Wednesday, May 09, 2007


Liberty Alliance has announced the 2007 IDDY (Identity Deployment of the Year) Awards.

I think I'm going to submit Google for their various uses of SAML.

Imagine this. I'm getting interviewed for a GJob and, midway through, I reach into my briefcase and say 'Oh, I almost forgot, I got you this award' and then plunk the thing onto the desk of that mid-level HR rep.

Let's talk vacation weeks. And why is that 'Serge' guy in my corner office?

XML Summer School 2007

My core body temperature just recently having returned to normal after last year's steam room, I am looking forward to participating in the 2007 XML Summer School in Oxford this coming July.

The 'Web Services & Identity' track has the following faculty members
I'll be adapting my deck from last year to reflect the identity industry's progress over the last year, i.e. incorporating the latest buzzwords, acronyms, and FUD.

Regrettably, at the request of the organizers, I will be deprecating the well-received adult film industry use case as motivation for privacy-respecting sharing of personal identity details. Fortunately, I foresee no great difficulty in adapting the use case to express it into terms of CEOs and the size of their yachts.

History T'ID'bits

Overheard in the Privy Council in January 1587.
Oh yes Your Majesty, a horrible case of squatting. Unfortunately I have checked with the authorities and it seems that, although you are indeed Queen of England and your cousin Mary is not, nothing actually prevents her from claiming the URI. Of possible interest, I've found a little known clause that suggests that, were the Queen of Scots to die, then the URI would pass to you as her heir. Of course, as her Majesty is a young woman in the prime of health, this is a highly unlikely scenario .......

Tuesday, May 08, 2007

No man (or provider) is an island

I'll go out on a limb here and say
Interoperability between A and B is simplest when there exists only a single mechanism by which the two can achieve X.

In the SSO world, that ship has sailed. There are multiple technologies that 'do' SSO.

Next in line in complexity would be a world where multiple mechanisms for X exist, but A or B (or C etc) will only ever use a particular choice. So A only ever uses X', B uses X'' and so forth. In such a world, you end up with distinct islands - constituents of each can talk amongst each other but not with anybody from 'across the water'.

That this is no longer (if it ever was) the case for SSO is hilited by Sun's announcement yesterday of support for OpenID. Sun will use OpenID's protocols for employee SSO to some relying parties, and will use SAML for enabling SSO to other relying parties.

The Sun scenario is one in which, while a particular entity A may use either X' or X'', they'll only ever use X' (or X'') with particular partners. So, A uses X' with B and uses X'' with C, etc.

In this scenario providers have to remember which SSO protocol to use with each possible partner - the 'right' one likely previously agreed upon between the two.

More complex yet is where some entity A uses either X' or X'' based on the application context, and not on the identity of the other provider. So, A might use SAML for SSO with B for app 1, and use OpenID with B for app 2.

Most complex is a situation in which the choice of a SSO protocol is not pre-determined by either provider identity or particular application context, but dynamically established by the two providers at run-time. This would imply that the two parters had means to
  1. determine the SSO protocol capabilities of the other
  2. indicate their own SSO protocol preferences
  3. negotiate/select within the available mechanisms
  4. fault out in case of failure
The above list describes the type of functionality SASL provides for authentication, and that ID-WSF provides for security of SOAP messages.

How will this work in the SSO world? What combination of Yadis, SAML Metadata, etc would enable this?

The signs are clear

The apocalypse draws nigh.

Identity for Dapper

I had found Dapper a while ago so I was interested in reading this review from ReadWriteWeb.

I became especially interested when I came across the line

The problem that these applications will face is identity.

Their interpretation of identity is a little different than mine.
How can you know that two movies - one at and another one at Netflix - are actually the same movie?

For myself the identity issue is instead how Dapper supports scraping of data requiring authentication and not publicly available.

Dapper deals with this currently by storing the encrypted passwords used for authentication to various services as cookies on the client, as shown in this screenshot from the Snag application built on Dapper.

Monday, May 07, 2007

Dear Sun Microsystems

Hubert Le Van Gong
Sun Micro

Dear Mr Le Van Gong.

It has recently come to my attention that Sun Microsystems is planning on becoming an OpenID provider. As a fervent collector of all things OpenID, I am writing to enquire how I might obtain such a URI.

I have one from every other OpenID Provider (even one from AOL, long story). My collection will not be complete until I have one in the prestigious * domain.

I understand from various blog posts that the OpenIDs will be 'reserved' for Sun's employees. Of course its important to be strict about such things, I was just telling my wife the other day about how our Country Club has gone downhill ever since they expanded the membership to allow provisioning people in. But, as we are both men of the world, I'm sure we can recognize that such rules needn't get in the way of reasonable people. As a small token of my appreciation for your prompt attention to this matter, please find enclosed $5 Ca.

In order of preference, here are my desired URIs.


Yours Federatedly

Paul Madsen

A James by any other name

In his history of identity protocols, Eric mistakenly attributes the 'prediction' to "James Governor of Redmonk".

Of course, it wasn't from Redmonk's James Governor, but from another with the same first and a similar last name.

I consider myself lucky that the only 'Paul Madsen' who I might (based on a Google) conceivably be confused with works in a different field.

Plus, I expect I'll get a good price if and when I try his diet.

Sunday, May 06, 2007

Well that's it then

James McGovern predicts:

I humbly predict that WS-Federation will become more important than SAML within the next two years and will invalidate all the hard work already done by the Liberty Alliance.

I guess it's over. I have to admit that I'm disappointed and, to be honest, even surprised.

I actually thought things were going well, you know, lots of adoption, encouraging signs of convergence, important new functionality etc.

As for the New Jersey Devils, it seems that the Liberty Alliance's playoff run is over. I'll be emptying my locker and signing autographs this afternoon before spending the summer golfing.

Hopefully Fozzie Bear can make it

Kermit Snelson's full schedule will prevent him from attending the IIW un-talent show, as announced by Eve.

I was planning to attend, but unfortunately I really do need to rearrange my sock drawer that evening.

This reporter hears that the real reason Kermit won't attend is that the organizers were unable to meet his financial terms for performing the Rainbow Connection.

More IDM for Indoor Rowing

Interesting identity scenario in the context of indoor rowing this morning.

The monitor/console attached to the rower has two profiles on it, one for myself and one for my son. When you start rowing it allows you to select into which profile the data should be saved. So far so good.

Now the rowing software on the laptop I have attached to the monitor has only a single profile- that for me. When my son uses the program he uses a guest account for which the data doesn't get saved.

This morning, about halfway through my row, in trying to change the monitor display, I inadvertently hit the button that selected my son's profile. Unable to reconcile this switch to the fact that it was storing the row data against my profile, the software, rather than displaying my boat slicing quickly & effortlessly through the water, subsequently displayed me furiously churning water in place for the rest of the 40 minutes. It was as if I was in one of those infinite swim pools, built wide enough across for the oars.

Wednesday, May 02, 2007

Identity as Relationship Precursor

I participated (and really enjoyed) in a ProjectVRM call this afternoon. I've been interested in VRM for a while now so it was great to talk to people who know it beyond the acronym. We talked about what Liberty Alliance ID-WSF might provide in the way of plumbing for match-making between customers and vendors.

Towards the end, in a discussion of the value of VRM for the vendors, somebody (I'm pretty sure it was Chris Carfi) said something like
They (the vendors) will never see a better qualified sales lead

Seems that Chris's presumption is that the vendor and the customer will only ever interact AFTER they determine that there exists an intersection between the desires of the customer (e.g. Sony PSP for less than $160) and the vendor's offerings (e.g. Sony PSP for greater than $155). Thus the wonderfully qualified sales lead - the customer is pre-filtered even before the two ever meet.

So, interaction (in the form of offer and acceptance) follows discovery and retrieval of identity attributes (specifically the personal RFPs of the customer that they've created). Based on the identity RFP it finds for a particular user, the vendor decides whether or not further interaction is appropriate (i.e. beneficial to both). The model is

Identity sharing ----------> Interaction (or not)

This is interesting because it seems the exact opposite of most use cases in which identity attributes are shared (and those that Liberty ID-WSF has historically focused on). In these use cases, interaction comes first. The user shows up at a service provider and, in order to provide some enhanced level of customization, the service provider seeks to obtain identity. The model is

Interaction --------------> Identity Sharing

I'll argue that current identity systems (OpenID to a lesser extent, albeit not spec'd out) are geared to the latter model, what are the implications of the former?

If identity sharing comes first, as the precursor to (possible interaction), the question is how:
  • a service provide can retrieve identity of a users when not initiated by some interaction of that user
  • once identity is retrieved, how can the service provider initiate the interaction (if appropriate)
For the first requirement, there would appear to be 2 alternatives
  • broadcast - the user makes their identity publicly available for service providers to find
  • filtered query - the service provider sends a query for desired identity to designated identity providers, specifying their request abstractly in terms of the identity they seek rather than in teh context of specific users (e.g. 'who do you have that's looking for a Sony PSP?')
The second requirement presents privacy challenges. How do you make contact information available (so as to enable interaction) without throwing privacy out the window?

This isn't specific to VRM either. A bricks-and-mortar shop could be constantly looking for 'anybody within 1 km of my location' and, once found, interact with them in the form of a 50 cents off coupon. Scaling issues I grant you.

Let's all agree to not enable this

When self-asserted ain't enough

Robin questions his performance.

If this is a climax, I've been doing something very wrong for the last few decades.

Sexual prowess surely falls into the category of identity where self-asserted just doesn't 'make the cut' in inspiring confidence in relying parties.

It's like somebody saying 'people like me'. Let's ask 'people' why don't we.

I guess the old saw is true
It's not the size of your assertion, it's what you do with it.

Drake's Equation

Drake's equation is an attempt to estimate the number of extraterrestrial civilizations in our galaxy that we might come into contact with.

I propose the following modification

N = R* × fp × ne × fl × fi × fc × fpwd x L


N is the number of civilizations in our galaxy, with which we might hope to be able to communicate;


- R* is the rate of star formation in our galaxy
- fp is the fraction of those stars that have planets
- ne is average number of planets that can potentially support life per star that has planets
- fl is the fraction of the above that actually go on to develop life at some point
- fi is the fraction of the above that actually go on to develop intelligent life
- fc is the fraction of the above that are willing and able to communicate
- fpwd is the fraction of the above that get past passwords
- L is the expected lifetime of such a civilization for the period that it can communicate across interstellar space.

Captn Kirk: I need full power Scotty.
Scotty: I'm trying Captain but I've forgotten the password to the control system. Bones, didn't I share it with you?
McCoy: I'm a doctor not a help-desk rep.
Spock: Your reliance on such antiquated technology is illogical.

Tags: , ,

Tuesday, May 01, 2007

More on OpenID bootstrap

In posting this, I forgot a couple of things:
  • that John Kemp was here first (was it Newton that said something like 'if other men were able to see further than me, it's only because they were standing on my shoulders'? I think that was the jist?)
  • I had already pretty much blogged the exact same topic already.

I'm literally drooling

Alerted by this, I installed the following two Thunderbird extensions
  • Lightning - a local calendar integrated into Thunderbird
  • Provider - an extension to sync Lightning with external calendars
Once both were installed, I added new calendars to Lightning, each of which pointing at one of my Google calendars.

The process was painless. I grabbed the appropriate URL for each from Google Calendar, gave it to Lightning, provided my Google password (a twinge here but I'm not going to let it ruin my joy), and the data started flowing.

It works for both read/write - in both directions.

I need a moment.

Consenting Adults

I'm embarassed to say that I missed the sexual innuendo that Jeff hilited in my previous post on 'Consent Context Markup Language'.

My only defense is to point out that children use the Web as well; consent systems must deal with them as well. For myself, 'consenting children' just raises too many Grade 7 ghosts.

Jeff writes
Perhaps I am thinking of a different use case than Paul. He seems to be thinking about user’s viewing their own past consents. I am looking at it from an auditing standpoint.

I see such a syntax useful for both the 'user dashboard' and audit use-cases. We're defining a Reporting Service in the Liberty Alliance to support both.

I do so love being able to justifiably use a title and tag combination guaranteed to spike my readership.

Liberty Alliance Technology List

As part of the Liberty Alliance's commitment to openness, transparency and yada yada yada, the Technology Expert Group (TEG) mail list is henceforth readable by non-members.

The archive of past messages is not being opened, the decision was made that we could not justify the expense and effort of scouring out the many occurrences of:
  • references to questionable parentage of other contributors
  • variations on 'WTF was BMEG thinking?'
  • plans for global domination of the IDM market
  • tongue-in-cheek proposals for as yet unseen WS-* specs (e.g. WS-NeedsHeavyProfilingForAnyChanceOfInteroperability)
  • 'You're talking about the %$#*^&@! Attribute Broker!'
  • the phrase 'A) - you're wrong, B) - ....'
The first topic under discussion is the definition of 'privacy event types' to be used within the Reporting Service (spec currently not released). The use case is a centralized Citizen Dashboard to which particular events (e.g. the release of attributes, federation establishment, SSO, etc) could be sent by the various government agencies that a citizen might interact with - and so provide the citizen easy 'privacy transparency' into such dealings.

Wonderfully panoptical. And yet powerfully user-centric.

Message in a bottle

I suggest that the following mod to the Pioneer plaque would have had a better chance of explaining 'who we are' to aliens, as well as establishing shared experiences.