Thursday, November 30, 2006

I demand a(nother) recount

The speaker assessments of the Liberty Alliance Tokyo Event held earlier this month are in.

with this legend
I expect the shirt Pat wore accounts for his inflated ratings.

It's also clear that are 3 individuals in Tokyo who just aren't into 'people'.

I wish I could claim language advantages for Shitamachi-san's dominant showing. Fact is, his talk was just incredible.

Viral (with no redeeming qualities)

A local electronics retailer sent me an incredible one-time offer and, best of all, gave me the option to tell my friends about it.

Who does this? Who is so insulated from dealing with their own spam that they are oblivious to the risk that giving away email addresses would mean for their friends or family?

Personally, I would never infringe on the privacy of anybody I had even a modicum of affection or respect for in this manner (Conor, I hope I gave your correct address).

Beyond the privacy issue, what's the motivation? What's in it for me beyond the gratification of increasing the spam burden of someone I care for? There is no hint of any social application (e.g. favourites list, wish list, reviews, tips, etc) that might be enabled by getting my friends/colleagues to sign-up.

In the Liberty Alliance People Service model, the sequence could work something like:
  1. Store sends me above email (unlike my friends, I've opted in to receive them)
  2. Message contains a number of custom URLs that I can choose to send onto whomever I wish
  3. When my friend receives the message, clicking on link takes them to etailer where they are given options of a) federating an IDP account of theirs with the etailer, and b) joining my People Service (so that future interactions between ourselves can be facilitated)
Key implications:
  1. I don't give away the email addresses of my friends indiscriminately
  2. Interesting social applications between them and I (like above) can be enabled without requiring them create an account at the etailer.
  3. I rely on more traditional mechanisms to inconvenience Conor.

Wednesday, November 29, 2006

A marriage of convergence

Conor provides some feedback on the OpenID Authentication Quality Extension. I was involved along with David and Avery so will take the opportunity to respond (not to the specific issues he lists but the meta-issue)

Conor's fundamental objection is that the proposed extension does not take advantage of SAML's Authentication Context

Overall, as far as I can tell, there is nothing in this specification that is not easily handled using the SAML Authentication Context structure and so I don't understand why they didn't just adopt that model as-is (and the SAML model clearly handles much more than the limited cases supported currently by this proposal). At the minimum, this document should be a limited profile of what portions of the SAML model they want to use.
The proposal's acknowledgement of the similarity between AQE and SAML AC isn't enough.
This is all you hear from or about SAML in the entire specification. There are no other references to the SAML authentication context, nor any use of the structures or capabilities of the Authentication Context. I'm not sure why this is even mentioned here if they aren't going to make use of any of the SAML work in this area.
Personally (and I'm not speaking for David or Avery) I see OpenID leveraging SAML Authentication Context as a desirable end-state (as do I seeas desirable SAML possibly leveraging those pieces of OpenID for which there is no comparable existing functionality in SAML 2.0) and hope that AQE gets us closer to that end-state. Afterall, you can't converge if you don't have two parts to align.

There are tantalizing opportunities for convergence between OpenID and SAML floating around - AQE and AC is just one such.

I would not have liked to have seen Conor courting his wife. "Look, we both know where this is going so let's just cut to the chase".

Pat, it's called 'plenary', not 'pleeenary'

Just listened to Aldo interview Pat about Project Lightbulb

Pat will be discussing the same in just over an hour.

The only point I disagree with is Pat's minimization of the degree of the debauchery in Rome.

Unfortunate coincidence

Marc Canter has a post entitled 'Original Thinking' that returns a "Error 404 - Not Found". Probably not the effect Marc was going for.

Many of my posts should return 203.

AQE - SAML/OpenID Convergence Opportunity #1

David announces the OpenID Authentication Quality Extension (AQE) proposal that he, Avery Glasser, and I drafted.

The Security Assertion Markup Language (SAML) Authentication Context ([SAMLAC] (Kemp, J., “SAML 2.0 Authentication Context,” 2005.) defines mechanisms by which SAML Service Providers and OpenID Providers can discuss the context of an authentication assertion.

The authors acknowledge the similar motivation between SAML's Authentication Context and this extension. Where possible, we have attempted to stay aligned with the SAML Authentication Context model. Indeed, we see this topic as a likely area of convergence between OpenID and SAML. More work is needed here.

Tuesday, November 28, 2006

Complete transparency isn't always appropriate

A perfect example.

In web service security, the token can be opaque to certain actors (e.g. to a client presenting a bearer token, or to a Liberty Alliance People Service forwarding on an identity token) but other actors will need to be able to look into the same tokens (e.g. the WSP receiving the above token).

Like lettuce in the very back corner of the vegetable crisper, tokens don't last forever.

Action Item # 23 Status - complete

I received this email from yesterday.

It's nice to be able to clean this off my plate.

Monday, November 27, 2006

2 out of 3 ain't bad

If you're counting hot memes, I think we have 2 of the big 3.

I'm confident that the 3rd will rear its head at some point during Pat's webinar.

Now that's a protocol

I gave blood this morning. The protocol the nurses use is incredibly precise.

There are no SHOULDs or MAYs here, everything they do is specified to the finest detail. Beyond the expected rigour over medical (and travel, Hong Kong gave them pause for thought) history, each operation is scripted out. The amount of time the nurse spends swabbing iodine before inserting the needle is even prescribed - and timed. I'm surprised the donut I had afterwards wasn't weighed to ensure I received the desired amount of sugar.

Service Providers and Relying Parties

Are they always synonomous?

SAML uses SP, OpenID uses RP.

Will an RP always provide a service? Must an SP always somehow rely on my identity?

Friday, November 24, 2006



We'll always have Paris

I believe the term is "You go girl"

Pam sets a level of sarcasm I'd be proud of.

Pam already knows about my top two candidates for the 'Top 10 Male Geeks Calendar'.

Semi-Modal dialogs

A key piece of Cardspace is the UI experience/ceremony. At key times, Cardspace greys out the screen except for the Identity Selector, visually hiliting for the user that 'something important is happening' (this reinforced by the fact that the identity selector is a modal dialog and thereby prevents the user from doing anything else until they've dealt with the the dialog).

For the first time, I've seen this visual paradigm used elsewhere. When you try to login to Ping ID to access their information library (which I resent by the way) the rest of the browser screen is greyed out except for the account/password prompt window. Additionally, I can't do anything else in that window but deal with the dialog (see below)

Not sure what to make of this. One of the purported justifications for the Cardspace 'greying-out' is to produce a visual effect that would be difficult for a phish site to recreate. But, any phish site could recreate the effect within the browser and it's modal only within the browser (actually only within the tab).

Do semi-modal dialogs diminish the power of those that are fully-modal?

What could be more user-centric?

POSTInterceptor is a GreaseMonkey script that intercepts POSTs and makes their contents visible.

Here is a screenshot taken of the first POST of the OpenID authentication protocol from the "I want my OpenID" RP (the mechanism isn't of course only relevant to OpenID, SAML allows for Assertions be be POSTed around).

For some reason (beyond my limited ability to troubleshoot) the act of intercepting the POST arrests the protocol flow and I don't actually make it over to Strange because I verified that the extension did not interfere in POST operations at other (non OpenID-driven) sites. Perhaps it's interference between the Javascript controlled auto-submit and the extension?

If not for signatures, the user could use the similar control point on the POSTed response from the IDP to change/delete/add the identity attributes being asserted to.

Even without the ability to make changes, it would provide a 'Lets just see what they're saying about me' mechanism for the paranoid.

Thursday, November 23, 2006

Mea culpa

Lately I've found myself occasionally thinking that (and I hesitate to even confess this) 'user-centric' identity might not be so ground-breakingly new and perhaps, just perhaps, might simply be the most recent manifestation of the long established concept of empowering users with appropriate controls over their identity. Technologies have advanced yes, but the fundamental principle is the same. I've even found myself questioning whether or not user-centric identity is appropriate for all use-cases.

Yes, I know, I'm disappointed in myself too. My only defense is to say that I did not want to have thoughts such as this and I can only assure you that this is not what I truly believe.

Consequently, these thoughts will not go unchallenged. To banish such doubts back to from whence they sprang, I've created a GreaseMonkey script to give me constant reminders of the truth.

Here is the script in action (click on the graphics for a larger view)

On the Google results page for 'user-centric'

and on OpenID

and at Project Liberty

Should you find yourself having similar doubts, I'd be happy to share the script.

Recombinant paper folding

This guy cloned himself - in paper.

10-to-1 one of his clones robs a bank.

Wednesday, November 22, 2006

Fair dinkum

Ping ID has a beaut animated sequence showing the different combinations of the various bindings that SAML 2.0 allows for, e.g. redirect for the AuthnRequest and Form POST for the Response, or Artifact for both AuthnRequest and Response, etc.

Unfortunately there is no audio. You'll have to use your imagination. I personally couldn't help but hearing a nasal Australian accent doing the voice-over, e.g. 'the SAIMEL aissershun' is paessed from IDP to SP'. Not quite sure why.

I also couldn't stop thinking that the cookies being passed around were Anzac biscuits.

Many are called but few are chosen

These are the Pauls I know

Paul Squires

Paul Toal

Paul Trevithick

Patience gentlemen, it's all coming together. Pretty soon we'll be able to justify our own song.

My life flashed before me

When I saw this rendering of Google Calendar

I thought it might have been a 'To Do List' GreaseMonkey script I was trying out so I uninstalled that. No change. Cleared cache and cookies. No deal. Using an 'https' URL resolved the issue.

A phish site could intentionally display a seemingly garbled rendering of a page, the only clearly visible information a phone number for 'Having troubles with this page, call this toll-free number 111-222-3333'.

'Uh yes, sir, I'll just need your account details to fix this problem'.

I expect that intentionally garbling the page could actually assuage any ID theft concern the user might have - it being so out of the ordinary that their normal expectations of UI and experience would be ignored. At the very least it would effectively disable any personalization mechanisms the real site might have implemented.

Tuesday, November 21, 2006

Knit one, perl two

Hey XMLGrrl, consider this a challenge.

Just so you know, I'm not interested in any 'knitting and needlepoint are distinct art forms' excuses.

What if you are ordering dinner online?

From Lifehacker, AllergyCards:
provides a fast and convenient way for people with food allergies to print off "allergy cards" for use eating out, while travelling, etc.

Better from a privacy point of view would have the restaurant pose the question to an 'Allergy Service'

Here is a list of ingredients for the food Joe just ordered, any concerns I should know about?

Shades of ACLU Pizza of course.

A video is worth a million statistics

This video and associated site changed the way I think about the world. Makes me want to be a demographer.

I can't help but imagine similar animations showing SAML, Cardspace, and OpenID evolution. Place security along the vertical axis, SP promiscuity along the horizontal, use appropriately sized radii to indicate numbers of enabled identities, and see how the picture changes over time.

I expect we'd see the three circles move through the spaceon different trajectories, sometimes overlapping, sometimes separating, and at any one instant in time, showing differently rates of growth (likely driven by external phenomena like legislative activity or OS upgrading).

Masters thesis anyone?

Alternatively, an animation showing numbers and type (verinymous, pseudonymous, anonymous) of identities for an Internet user over time. If the circles don't start to get smaller we should all start looking for real jobs.

OpenID and i-names

Pamela commented on my post about the OpenID ceremony, at least as currently implemented by Paul Toal's.
And then there are the inames. I can't figure out when exactly I get to start using my iname to authenticate, and if I do, do I still need to specify a provider? I remember from IOS Santa Clara that inames & open IDs are merging for OpenID 2.0, I just can't figure out if that means now, or soon... luckily I get to ask all these types of questions at IIW in a few weeks :)
As I understand it, in OpenID 2.0, if you provide the RP your i-name, the RP would use XRI resolution to retrieve an XRDS document, and from that extract the appropriate IDP endpoint for redirection.

Consequently, having the user provide both the IDP through a drop-down list as well as an i-name would seem to provide only opportunity for confusion.


As I cannot leave comments on Paul Toal's blog, and he cannot leave any on mine (and I don't have an email address for him), we are forced to have a conversation through sequential posts.

Paul responded to a post of mine, in which I questioned the UI elements for his OpenID authentication option. Paul wrote

From looking at the code for the plug-in, the only real purpose of the drop down box is to change the icon within the field next to it to match the type of server you will be using. Other than changing the icon, it serves no real purpose.
Actually, it does appear to do more than this. When I leave 'LiveJournal User' selected, and provide my Verisign PIP OpenID URI, I get an error message of 'Couldn't find OpenID Server'. When I switch to select 'Other OpenID' and provide the same URI, I am successfully directed to Verisign's PIP.

Paul also indicated that he wasn't able to comment directly on my blog because the Blogger captcha mechanism didn't work for him. No clue here. I use Firefox and the captcha works for me.

As for my OpenID-enabling my blog, lately I've found I have less and less ability to drive Google policy on identity. They listened so much more when they were only worth 20 billion.

Monday, November 20, 2006

OpenID ceremony

Paul Toal's blog allows readers to use an OpenID for their authentication mechanism.

The ceremony is different than typical. If they wish to use an OpenID URI (as opposed to authenticating with a local account), the user is asked/allowed to specify the identity provider at which they maintain that URI in addition to the URI itself, see graphic

It's not clear to me why a user would need to both supply the URI as well as indicate the IDP through the select list?

It would make sense to me if the user was allowed to either pick their IDP from the list OR enter their own URI - the former being valid if the user wants the 'delayed binding' model of persona selection (this would be valid but seemingly antithetical to the supposed OpenID freewheeling trust model where an RP isn't expected to show any selectivity in its 'favours').

I tried not providing a URI to see if I'd get sent to LiveJournal regardless but the OpenID authentication on Paul's site isn't working.

Evolving Risk

Fidelity Investments has a mutual fund product - the distinguishing feature of which is that
as each Freedom Fund nears its target date, the investment mix gradually gets more conservative.
As you near the time where you will be removing funds, the asset allocation changes to minimize risk.

Why not the same for identity policy, i.e. privacy rules that automatically become more conservative and risk-averse as the user ages?

I expect that I currently allow usages of my identity now that I won't in 20 years, and I'm absolutely sure that the 43 year old me wouldn't allow operations now that a 20 year old me wouldn't think twice about.

I propose a simple formula

For every 2 years of age past 20, allow one less identity operation in a weekly period.

Based on experience with my Dad :
  1. the particular operation being denied should be chosen randomly
  2. whatever decision made in one instance should not impact subsequent decisions
  3. the Fault code cited should place blame on the 'government', and
  4. should be followed by a prolonged rant on how, when the user was a kid, they had to create their own SAML assertions using a Number 2 pencil, use a slide rule to calculate the signature, and deliver them through plain POST operations, unassisted by JavaScript. And it was uphill for both the request and the response.

Friday, November 17, 2006

SAML paired with Skype

Jeff has made available a SAML document he created. It's more than just an overview, but rather 'How to Study and Learn SAML".

As a starting point, Jeff recommends
Begin by studying various SAML Profiles, e.g. those given in [[SAMLProf]] and [SIP-SAML]. One will likely find the SAML Technical Overview whitepaper [[SAMLTechOvw]] helpful in this endeavor. It provides a detailed, illustrated expose of several of the SAML Web SSO profiles.
Interestingly, when I view the document, a plugin Skype (yes Jeff, I know it's proprietary) installed when I recently upgraded renders a phone number in one of the XML examples as a 'click to call'.

Presents some intriguing possibilities for smart clients.

Thursday, November 16, 2006

Big In Japan

My life is downhill from here on.

It's a bit of a stretch for my Nihongo skills but I believe the translation of the text besides my pic is roughly: "His looks are wasted on identity, he should be in the movies".

It's either that or "Who ironed that shirt" (I'm finding verb tense a bit of a challenge).

Ceremonial Trappings

Aldo has an interview with Drummond Reed, Johannes Ernst, and Chris Messina talking about the importance of usability design and user experience to OpenID.

Like Kim, they refer to the importance of ceremony for users around identity transactions. Pam touches on the same.

Chris refers to the possible advantage of, at least initially perhaps, allowing for experimentation. Let different communities try different ceremonies and user interface paradigms and learn from the collective experiences. Fundamentally, recognize that we have much to learn here and we probably shouldn't think we can get it right the first time. This belief (admittedly as well as a recognition that user interface design was a potential differentiator for vendor's offerings) is the primary reason that the Liberty Alliance has never attempted to tackle this aspect of identity.

Separately, from the chat, you might get the impression that mobile clients present no special challenges or opportunities for user ceremony. It's hard enough for me to enter my email address on a phone but I'll take the 5 minutes to type in URL? How many users know how to find the '/'?

Update: I wrote the above before I got to the point of the interview where Johannes does briefly mention devices.

Aside from that, all other ceremonies I attend always end up with me wearing a suit. That's going to significantly slow down my log-in.

I'm not one to judge

But the stats for ths blog do show an increasing number of people arriving here after searching for 'federation promiscuous eve'.

Whatever clubs Eve chooses to belong to are of course a personal matter for her to decide. But perhaps the organization could pay for some search engine optimization to drive their placement up (and mine down).

Nature abhors an (identity) vacuum

The "nature abhors a vacuum" idiom is used to express the idea that empty space is unnatural (or improbable) as it goes against the laws of physics. It was first coined by Aristotle to explain how water pumps work. He theorized that, if you pump air out with the lever, something must flow into the place of where the air was, which is the water.

The pump works because Nature hates the idea of empty space and so fills it with whatever it has at hand. Give Nature enough time, and it will find a way to break the seal of a Thermos bottle and fill the vacuum that keeps soup hot and beer cold.

This idea of an absence of something enjoying only tenuous existence because the environment will always endeavour to provide that missing substance is, I believe, a nice analogy for anonymity.

What is anonymity but an 'identity vacuum' (its etymology means "without a name")? Anonymity refers to a state in which there is insufficient identity information to allow a user to be identifiable within some set. So, like a vacuum, it's a state defined by the absence of something, namely identifying information. Also like a vacuum, anonymity need not be absolute, you can have partial anonymity as you can have partial vacuums.

Importantly, anonymity is a tenuous state. Like air rushing in to a crack in a thermos bottle seal at the first opportunity, identifying information will always (eventually) leak into anonymity from the environment. However well a system is designed to enable anonymity, outside forces are always trying to find a crack through which identity can be pushed. The leakage may come from recognizable facial or voice characteristics in off line interactions, or from an IP address or buying patterns in those engaged in online. But, wait long enough, and it will happen. Anonymity, like a vacuum, is a fragile state of being (and should be recognized as such).

From this exploration, I posit the following (dare I say it) 'Law of Identity':
If there exists a region of anonymity relatively devoid of identity, identifying information from the environment surrounding that region will attempt to redistribute itself so as to fill said void.
As an exercise I leave it to the reader to develop the "'Surfing Adult Sites at Work' Corollary".

Wednesday, November 15, 2006

I'm confused (and that's the problem)

Johannes asks people to consider whether or not a mashup of SAML and OpenID makes sense.

I don't see why the issue is any different than that which motivated a previous convergence between LID, Sxip, DIX, and OpenID - this manifested as OpenID 2.0?

There was duplication between these systems, now there is none (or less?). Less duplication means less confusion (I personally love no longer having to know what Passel does or doesn't do).

Between SAML and OpenID there is more and more duplication - this because:
  1. the OpenID community is adding new functionality to OpenID 2.0 for which there are existing equivalent mechanisms in SAML, and
  2. the SAML community is exploring how to enable SAML for use cases historically the purview of OpenID (and its erstwhile counterparts).
Less duplication would be 'better' because it would mean less confusion (amongst developers, vendors, customers, end-users, wives, etc).

Do we need more justification than the goal of creating a simpler marketplace - one unfragmented by confusion over multiple and incompatible identity systems?

Distributed Transaction Authentication

An interesting discussion of transaction authentication:
Transaction authentication is software residing on the enterprise security servers that monitors, in addition to the successful use of user id and password the:
  • IP address the user is coming in from
  • Users geolocation
  • Computer hardware the user is using
  • Time of day
  • Previous user pattern of behaviour
What if the scope of the 'transaction' were broadened, i.e. to include behaviours performed at an SP after the user SSO'd in from an IDP?

If the user's behaviour at the SP didn't fit previous transactional patterns (such as those listed above), should the SP alert the IDP as to that fact? There are, AFAIK, no protocols that would support such a call.

Or would the SP simply send the user back to the IDP with a request for an new authentication - this time with a mechanism that would better serve to erase the doubt in the SP's mind.

The semantics seem different, a simple request for authentication doesn't allow the SP to express it's reasons for concern and flag these to the IDP - this potentially important if the IDP has to decide to alert other SPs to which it has recently asserted the user's identity.

Chillin' (I think)

Julian's post alerted me to his profile. did not have high hopes for our musical compatibility. I'm happy to report them (mostly) wrong.

I can imagine a similar 'Interop-0-Meter' assessing the potential of different identity systems working together.

"You share a few logical functions in common, including: IDP discovery, request for authentication, artifact ...

Complaints from Finland

The Helsinki Complaints Choir is particularly timely for me personally as I deal with errata for the Liberty Alliance People Service.

I've contacted the choirmaster to suggest that the following lyrics be added:
  • "Why on earth is the TargetID Optional?"
  • "I hope this was a typo because otherwise the processing rule makes no sense"
  • "I know I've said it before but I strongly disagree with this approach"
  • "We also regularly lose to Canada in hockey"

HTML to blame for porn

At least, that's the reasoning Johannes seems to use when he expresses doubt about the relevance of SAML to Web 2.0.
I got to say that I'm a sceptic on this. I don't think that there has been an existence proof for the successful combination of SAML and Web 2.0: putting control in the hands of the end user — the essence of Web 2.0 — is not typically compatible with the way SAML projects tend to end up.
The argument appears to be 'because SAML can be deployed in ways that don't directly/explicitly/visibly empower users, it can't be deployed otherwise'. Similiarly, because HTML can display porn, or violence, or politicians, it can't be used for more noble purposes.

Notwithstanding his doubt, Johannes signed up for the Liberty Alliance Open Source Identity Webinar and appears willing to have his SAML notions challenged.

Johannes also points out the irony in Liberty requiring Webinar attendees to create an account. A legitimate objection, and one for which steps are being taken (or at least being discussed). I expect Johannes will appreciate the extra irony in this being pointed out by someone who throws up a not insignificant barrier to anybody wishing to leave a comment on his blog.

Tuesday, November 14, 2006

Get on board

Johannes points out the Open Healthcare Manifesto.

I expect the Liberty Alliance's eHealth Special Interest Group would have an opinion on the relevance of Liberty's architecture to certain of the stated principles, e.g. empowerment, trust, privacy, anonymity. I've even seen occurrences of "civility and respect" at Liberty meetings.

I'm not so sure about using a train as an analogy for identity though. According to the criteria of some, for it to be truly "user-centric", the user would be able to force the railroad lines to lay tracks to any and all desired destinations, irrespective of cost, timeliness, and environmental damage. Such a 'narrow gauge' provides a shaky foundation for high-speed travel.

Sunday, November 12, 2006

Remembering (Canadian style)

My son's hockey team had a game yesterday that spanned the 11th hour of the 11th day of the 11th month.

Friday, November 10, 2006

We need an IIW in Panama

Hypothesis - the level of promiscuity of an SP/RP (measured by its willingness to engage in identity transactions with IDPs) will demonstrate a strong negative correlation with the level of security that SP/RP expects for such transactions.

Highly promiscuous SPs/RPs will expect/require less security, selective SPs/RPS will require more (so, amongst other things, they can be sure they are dealing with the IDPs they think they are). What insight!

A consequence of the above is it's possible to combine 1) high security and promiscuous behaviour and 2) low security and discerning partner selection. Possible but not very logical. For the first combination, you are paying for security you don't need; for the second, you probably have insufficient security for your risk model.

I think OpenID and SAML have successfully found the right (but different) mixes of promiscuity and security. OpenID has focussed on promiscuous providers with an appropriate level of security, SAML on the opposite pairing. This is shown graphically below. Along the horizontal is SP selectivity (the opposite of promiscuity), along the vertical a measure of security.

So, both SAML and OpenID seem to have discovered distinct and valid islands. Nice. But, seems to me that both of late are exploring moving beyond these domains. OpenID is allowing for additional security options to OpenID 2.0, SAML to allowing for less security through the proposed SimpleSign binding.

Problem is, while OpenID is adding security, there is less evidence of that community defining mechanisms in support of less promiscuous partner selection (at least in the core spec and not deferred to extensions). Likewise, while SAML is allowing for security to be more a deployment decision, no mechanisms in support of more promiscuous SP/RP behaviour are being defined in the SSTC (like URI-based IDP discovery or something akin to OpenID's association mechanism). Consequently, OpenID appears to be expanding directly upwards into a zone of 'Pointless Overkill', and SAML straight down into a zone of 'Insufficient Security'.

We need an isthmus stretching from lower-left to upper-right - it's there that the "sweet spot" of convergence lays (and which keeps us well clear of the dangerous shoals threatening to tear a hole in the hulls of each ... blah blah blah).

OpenID Extensibility for Strong Auth

In response to my puzzlement, David points out plans for an extension to OpenID that would allow an IDP to distinguish between the nature of the authentication mechanism - and thereby allow the value of stronger methods to extend down to the RP.

This is good to hear. I'd really hope that the OpenID community, in specing out this extension, look at what SAML has done in the area. Additionally, I think its important that, in addition to the IDP being able to say 'This happened', the RP should be able to say 'I want this to happen'.

Avery also commented on the post. Interestingly, in describing the planned extension, he wrote:

about the method of identification at the point of enrollment and the method used when authenticating
Differentiating between (and accounting for both) how the user was registered and how they were authenticated is something SAML's Authentication Context makes possible, most notable examples of which are the 4 mobile targetted AC class URIs that differentiate based on whether the user has a contracted account or is pay-as-you-go.

In his own comment, Pete suggests:
The RP doesn't have to bother but if it chose to it could keep track of those providers that provide strong auth and act appropriately when those IdP's are the ones doing the authentication.
This could work if an IDP only supported a single authentication mechanism. If not, the RP wouldn't know which was used for any given assertion.

Pete then writes
What higher level value is a claim of strong auth from an IdP when there is no trust between the IdP and the RP anyway?
Indeed, but if the RP doesn't trust the IDP, its unlikely to care about how the IDP authenticated the user. And if the RP doesn't care, why would the IDP go to the extra cost and effort?

Thursday, November 09, 2006

Voice Authentication Value-Add (VAVA)

Just listened to Aldo's interview with Avery Glasser of VXVSolutions, talking about their integration with OpenID.

Interesting 'hear'. But one piece confused me. In describing the sequence by which a user would use their voice authentication to OpenID into LiveJournal, Avery said the following:

So, to LiveJournal, it thinks that you just went to any standard OpenID implementation
it doesn't know that, instead of just putting in your log-in and your password, that you were actually going through and authenticating yourself by voice.
Tying in Strong Authn to SSO is great - the two pieces complement each other perfectly. Strong Auth gives SSO 'something to do' and provides value to the RP beyond convenience to the end users, and SSO makes Strong Authn practical and cost-effective.

But this only works if the value of the strong authentication can flow to the RPs - this implying that the RP knows that the user actually used something beyond a password to log-in to the IDP. But, OpenID doesn't support anything to allow the IDP to make this distinction (nothing comparable to SAML's Authentication Context).

With OpenID as it is (or AFAIK expected to be in OpenID 2.0), the RP would be unable to provide a voice-authenticated user any different level of service than a password-authenticated user - this because the IDP isn't able to indicate to the RP that something different happened. The value of the strong authentication effectively disappears at the door. So, why would the RP bother?

Pimp my ID

Ping's Ryan Hunter responds to my post describing a morality scale of sorts for identity transactions.

Ryan questions my premise that providers will allow their users to select their partners (I think of this as a pimp-centric model).

In reality, identity providers will never allow users to drive the partners with which they engage in identity transactions, unless the user(s) have leverage in their relationship with the providers and and also the identity provider has leverage over its partners too.
This was actually the point I was trying to make. I think user's can indeed have this sort of leverage over providers, but ultimately it's granted to them at the discretion of the providers.

So, providers could allow the users to direct them to other providers. The point I was trying to make was that the providers will be content doing so right up to the point where they are no longer content doing so - this when the risks of such promiscuous relations outweigh the advantages.

In Ryan's analogy, the 'model' at the bar might allow the bouncer to introduce Brad to her with a 'This is Brad, I think you guys are perfect for each other'. She might see my own introduction in a very different light (better of course).


Jamie Lewis points out Seriosity.
Carbon (Beta) is an enterprise productivity application, inspired by successful interactive games. It creates an economic system with its own currency and market that allows users to better manage their attention and that of others.
Sounds like the model is "Read this email and I'll slip you a fiver".

I'd want to see an on-screen meter showing my 'vacation day status' - this changing daily as I go about my business. Have a productive day, get an hour of vacation added. Spend the morning blogging, lose 30 minutes.

How would I fill up my health (benefits)?

No identity in Web Science?

Tim Berners-Lee and academia have created the Web Science Research Institute.

What appears to be a related publication is 'A Framework for Web Science'.

I find it strange that in a paper of 130 pages that purports to describe the Web and how it works, there are only 13 references to identity.

And no references at all to any of SAML, Liberty Alliance, OpenID, SSO, user-centric, federation, Cardspace, etc.

Perhaps all the work has been done in identity and so there need be no further research? As opposed of course to that frenzy of real-world implementation that is the Semantic Web.

Any club that would have me

Jeff has updated the SAML Glossary, making it available in HTML.

The SAML definition for 'federation' is:

Federation This term is used in two senses in SAML:

1. The act of establishing a relationship between two entities [Merriam].
2. An association comprising any number of service providers and identity providers.

For some, 'federation' in the latter sense is synonomous with a 'Circle of Trust', this interpreted as some group of providers, the CEOs of which have had drinks together in some swank restaurant, the lawyers of which have had thrashed out detailed legal agreements governing the identity transactions of their shared customers, employees, citizens etc, and the IT staff of which have exchanged metadata, crypto keys, and complaints about their respective CEOs. This is Big Business.

But of course the above definition says nothing about the rules by which membership in the "club" is defined.

Often times the rules will (as in the Big Business case) be strict, with correspondingly strict processes for admittance - there will be forms to fill out in triplicate, lots of background checks, and probably an interview where the Club Secretaries grill the candidates over Martinis.

For some, this sort of club is what a federation is. But the above SAML (and SAML is of course strictly about federation so its the authority) definition for federation also allows for clubs with far less formal rules and processes and, in the extreme case, an open-door policy of everybody welcome.

There needn't even be a membership list in such a club, membership would be defined by showing up. You want in, you're in. The only rules would be to pay your money and remember to tip your bartender. I expect you'd meet some interesting people and have some great chats at such a club. Far more diversity than the 19th hole filled with leather club chairs. Probably not going to be looking for an investment banker there though.

I wonder if they validate parking.

Wednesday, November 08, 2006

Symmetry in social relationships

So it seems Alice and Bob have patched up their differences and have agreed to their continued use in identity transaction scenario descriptions.

Consequently ...

Alice wants her friend Bob to be able to view her current location as she moves around the city. After receiving the invitation and consenting, Bob gets added to Alice's People Service, and a number of shared identifiers are established between various providers.

Critically, Alice's geolocation provider (AGP) gets an identifier for Bob against which it can assign appropriate access privileges (maybe Alice set things up so that Bob can see her location only during the work day). When Bob browser SSO's into the AGP from his own IDP, AGP is able to recognize the asserted identifier as somebody that is allowed to see Alice's location and so can give Bob a nice map interface. Importantly, that may be all the AGP knows about Bob.

For access to such browser-based resources, it's pretty straightforward. However, if Bob wanted to access Alice's location from within his own geolocation provider (BGP) rather than visiting AGP in his browser, things get trickier.

BGP will send a request to AGP for Alice's geolocation so that the data can be integrated into its own application, and then likely shown to Bob. The Liberty Alliance SOAP Binding allows for such a request from BGP to AGP to be sent, logically:

Hello AGP, this is BGP asking on behalf of 'Bob', what is the current location of 'Alice'?
Nb: 'Bob' and 'Alice' in the above will generally be appropriate identifiers (possibly encrypted so that BGP can't see them) for the two users that AGP will either be able to recognize or be able to map into identifiers that it can.

Everything seems peachy keen - as before AGP determines if Bob is allowed to see Alice's location (and perhaps whether BGP is allowed to ask on Bob's behalf), and then either responds with the data or declines.

There is a missing piece in the above however. How does BGP know that Alice has granted Bob permission to see her location? More fundamentally, how does BGP even know Alice exists and that Bob knows her?

The Liberty Alliance People Service addresses these questions by allowing (but not stipulating), that, in addition to Bob being added to Alice's PS, Alice can be added to Bob's PS - the two People Service lists are, in a sense, mirror images of the other.

If this happened when Bob was added to Alice's PS at the start, then Alice would also be added to Bob's PS list. When Bob subsequently visits BGP, that application can query Bob's People Service and will see Alice in the list. From there BGP can obtain the appropriate identifiers and service endpoints so that it can compose the above message.

The sequence by which BGP asks AGP for Alice's data is something like

1) Bob SSOs into BGP from his IDP
2) BGP discovers Bob's PS
3) BGP queries Bob's PS for list of friends
4) BGP requests an identity token for Alice
5) Bob's PS does some work behind the scenes to get an identity token for Alice
6) Bob's PS returns the identity token to BGP
7) BGP uses the identity token to query Alice's Discovery Service for Alice's Geolocation provider
8) Alice's DS returns the location of AGP and an encrypted identifier to use for Alice there
9) BGP sends above message to AGP
10) AGP returns Alice's location to BGP
11) BGP shows Alice's location to Bob
12) Alice and Bob decide to, yet again, 'take a break'.

Somewhere in County Cork

An internet cafe experienced an (almost certainly loud) bunch of first time Internet users yesterday.

I imagine that the conversation would have been something along the lines of:

Seamus: So, are you sure that Cousin Conor said he'd buy us drinks if we did this?
Paddy: Damn straight he did. All we have to do is click this mouse thingy on this little button over and over. He said one Guinness for each clicky.
Seamus: But what does it mean? Why does he want us to do this?
Paddy: Jeez Seamus, what do we care. He's probably compensating for some sort of, what der ya callit, an 'inferiority complexity'

A business opportunity?

This is an interesting idea for the retrieval of a lost USB drive. But, as implemented, the owner of the driver has to advertise real address information to whomever might find the drive.

Perhaps there is a opportunity for an "anonymizing snail mail proxy". The owner of the drive would register an account with such a service and in return receive a shipping address to insert into the USB drive (even if only a readme.txt and not the slicker option shown here). The address would be personalized such that, if in the future the service was sent the drive from somebody who had found it, it could be then forwarded onto the owner.

I wonder if there is a model in which the service does not obtain physical control over the drive but rather simply plays the role of anonymizing the ship-to address?

The alternative is of course to back up the drive's data, encrypt it against anybody who finds it, and write-off the drive as a business expense should it be lost.

I demand a recount

Liberty Alliance handed out some nice football jersey swag at the July plenary in Vancouver. The shirts each have a number representing the organizational primacy of the member receiving it. Mine has a '3' on the back.

My NTT colleague Yuzo Koga wasn't at the Vancouver meeting in order to receive his so he had to wait till Liberty came to Tokyo to get it.

The wait proved an effective strategy for Yuzo's ranking. I'm just glad I didn't do a Faith Hill when I saw the number.

Tuesday, November 07, 2006

I fear I :-) too much

This reminded me of how easy it is to fall into typographic traps!

Would friends tell me if it were true? :-)

I also suspect I use quotation marks too "much".

Note: the equation in the video is undefined for zero exclamation marks. That's pretty funny :-)

Quantum effects

Rob Zuccherato sheds some light (but not photons) on what the availability of large-scale quantum computers might mean to existing cryptographic algorthyms and key sizes, as well as the practicality of quantum crypto.

...the limitations of quantum cryptography (e.g., a single continuous fibre or line of sight must exist between the two parties) suggest that it will only really be applicable to high security link encryption, and not necessarily to other current applications of cryptography.

In addition, quantum key distribution requires that a pre-existing authentic channel must exist between the two parties. Typically, this will be realized by the two parties having a pre-shared symmetric key that they can use for authentication.
Sounds like quantum crypto and OpenID is a marriage made in heaven.

Nudge nudge wink wink

Lately, I've more and more heard the OpenID trust model described as 'promiscuous' - this because the default assumption (seemingly under examination as that community explores the relevance of blacklists and whitelists) in OpenID is that IDPs and SPs are able to engage in OpenID authentication without necessarily 'knowing' each other beforehand (where 'knowledge' here means the two having some existing trust and/or business relationship).

This sort of SSO promiscuity is often contrasted with SAML's model - where typical use cases more often presume that the two providers will 'know' each other, if not through some direct legal relationship, at least through some shared trust framework by which some level of confidence in the other can be established.

Far be it for me to criticize promiscuity - some of my own key formative experiences were heavily dependent on that model of social interaction - but it only gets you so much. It's great for the bar scene, OK for a date to the prom, but isn't at all suited for marriage (attempts to the contrary notwithstanding).

That is of course just fine. There are many valid use-cases where promiscuity is appropriate (or at least providers with more discerning rules for their partners aren't necessary). Providers should be able to choose partners based on whatever criteria they feel is appropriate (and of course under the guidance of their parents and religious advisors).

An 'easy' provider will empower its users with more choices for other providers as candidate SSO (or other identity application) partners. If the provider doesn't care with whom it partners, why not partner with any provider the user indicates is desirable. Sounds very user-centric - the user can effectively tell its providers with which others to engage in relations.

But of course, the user will have this power only until such time as the providers 'just say no'. As soon as the risks associated with such promiscuous activity outweigh the associated 'pleasures' (e.g. keeping users happy) - providers will quickly see the attractiveness of a more guarded approach to personal relations. And if that means the provider losing the ability to call its system 'user-centric' because the user's wishes are no longer the sole criteria for partner acceptance - so be it.

Additionally, while SAML may not define mechanisms specifically in support of promiscuity, that's not to say that it couldn't be deployed in a promiscuous manner. After all, at the end of the day, it's up to the IDP to decide from which SPs it accepts AuthnRequests from, and up to the SP to decide from which IDPs it will accept Assertions. SAML does not dictate a particular business model on either side.

I take the following from this essay:
  1. For providers, as for young adults, the trick is finding the right balance between promiscuity and the other extreme.
  2. Providers will allow users to drive the partners with which they engage in identity transactions until such time as they choose not to.
  3. An identity protocol, OpenID or SAML, should not be conflated with the trust model of systems in which that protocol gets deployed. Put another way, SAML, if appropriately liquored-up, could be as much a whore as Brittany Spears before Kevin and the babies.
Austin Powers had this to say on the subject

"as long as people are still having promiscuous sex with many anonymous partners without protection while at the same time experimenting with mind-expanding drugs in a consequence-free environment, I'll be sound as a pound!"

Gravity is a myth - the Earth sucks

You only ever experience gravity when you resist it. As you sit in a chair reading this, the chair pushes back against you as gravity pulls you down. You can literally feel gravity in the 'seat of your pants'.

If you ever given in completely to gravity (by skydiving for instance) then during that period you are effectively free of its experience (because there is nothing to push back on you while you are falling). Gravity is of course still present, but you don't 'feel' it (you will of course 'feel it in the morning' if your chute doesn't open).

So it is with identity policy defaults. A user can choose to 'go with the flow' and take the defaults for identity release as offered. For these users, the experience of managing their privacy will be minimal, insulated from the details and logistics by such default policies. These are the free-fallers - they choose not to actively resist and so will not so directly 'experience' privacy.

Other users will choose to become an 'active steward' of their privacy, and continuously manage the release of their attributes. Such users will have a real and constant experience of privacy. Like a couch-potato and gravity, they will be constantly reminded of privacy because of the day-to-day reminders they will receive.

A 'good' implementation/deployment of an identity system will protect the free-fallers (those who go with the flow) with defaults that provide appropriate levels of privacy protection 'out of the box'; while enabling the couch-potatoes with suitable controls, interfaces, and mechanisms for actively managing their privacy.

This insight is more 'general' than 'special', but 'relative' all the same.

Condemned to Repeat

My "travel book' for last week's trip to Hong Kong and Tokyo was Alice Hogge's "God's Secret Agents - Queen Elizabeth's Forbidden Priests and the Hatching of the Gunpowder Plot".

The book tells the story of the deadly (for one side) game between Elizabeth I's government and police against Catholic priests. The priests believed they were sneaking into England in order to save the souls of the citizens from the heresy of Protestantism. The government saw only rebels and fears of Spanish invasion - and so hunted down the priests, tortured, and then executed them in grizzly fashion.

Elizabeth's government played fast and loose with legalities of arrest, imprisonment, and torture. Laws were changed to suit, making torture allowed as necessary (as deemed by the government).

Fortunately, today's governments have learned from such past abuses to fundamental rights ands freedoms.

Intelligence Service Provider?

I'm watching an American Intelligence Officer critique the processing of intelligence data in the run-up to the Iraq War (think WMDs).

He (partially) ascribed the debacle as a result of those analysts tasked with assessing Saddam's abilities and plans failing to follow the Intelligence Golden Rule, to say:
What we know, how we learned it, and when we learned it.
Sounds like an IDP doesn't it?

For an SSO assertion, the 'what' is the authentication status of the user, the 'how' is the authentication context, and the 'when' is the time from which the assertion is valid.

He also said that a good analyst will always also provide 'What we don't know'. That would be a little tougher for an IDP. Maybe we need negative assertions in SAML.

Monday, November 06, 2006


Gay-gregator is a PeopleAggregator network that describes itself as a:

(GAY) Network with homosexual tendencies

What does it mean for a social network to have gay tendencies?

That it's attracted to other networks with similar interests?

That it votes Democrat?

That it's considering travelling to Canada for a marriage ceremony?

That it knows where the ottoman goes?

Friday, November 03, 2006

A Principle of Identity Locality

In physics, the principle of locality says that 'whatever happens here at Point A can only influence what goes on over there at Point B if something or someone travels from A to B'. So, no action at a distance, you can only ever directly effect things that are besides you.

I wonder if there is a 'Principle of Identity Locality'?

Perhaps something along the lines of
"Identity Context at one network locale for a given user can only impact the identity context for that user at another provider if some representation of the context at the first is communicated from the first to the second"
Web SSO is a perfect example. For the fact of my authentication at an IDP to be of any value for my interactions with an SP, an assertion/claim as to the act of my authentication must get from the IDP to the SP. Providers aren't psychic after all. So, the principle holds for SSO it seems.

But I don't think it's necessarily as clear as this. If identity context at Provider A includes a perception of their experience at that provider, then that perception can impact my experiences at another provider, say Provider B. As an example, if Provider A abuses my privacy and uses my email to send undesired marketing - that will alsmot certainly colour how I deal with Provider B when it asks for my email. And this can happen without anything travelling from one provider to another (except my doubt and lack of trust). Action at a distance and the two identity contexts are entangled.

As intuitive and common sensical as the locality principle is for the world around us, multiple experiments over the last 40 years have proven that it doesn't always apply in the world of the very small governed by quantum mechanics.

SSO to the Psychic Friends Network

Imagine the following SSO transaction with the Psychic Friends Network (PFN)

User wants to SSO in to PFN

User->PFN: My IDP is ..
PFN->User: No, No, don't tell me! I know this.
PFN->User: AOL? Yahoo!? MyOpenID? No? perhaps you could give me a hint?
User->PFN: It starts with a 'G'.
PFN->User: Google?
User->PFN: Yes, it's Google.
PFN->User: See, told you I knew.
PFN->Google: Please authenticate this user.
Google<->User: Sign-on steps
Google->PFN: Here is the assertion, the user is ....
PFN->Google: Wait, wait, don't tell me, let me guess first
PFN->Google: I'm getting a strong sense of an identifier for this user. I see a 'j', then a '2', followed by a '@', no wait it's a 'O'.

May the force be with me

I'm no coder, but when Pat Patterson demoed to me (at last week's Tokyo Liberty Alliance Day) the steps involved in adding SAML 2.0 support to an SP site using his Open Source SAML 2.0 PHP library, it looked so straightforward that even I could do it.

Conseqently, I will try.

For full developer versimilitude, I see a sequence something like the following:
  1. purchase a Simpson's Desktop Calendar.
  2. download and install Wordpress.
  3. go watch a matinee showing of 'Star Wars - Revenge of the Sith'. Tell co-workers I'm going to the dentist.
  4. install Pat's library.
  5. complain about the stupidity of Product Managers.
  6. tell Product Management I need more time, citing the fact that they didn't account for the time difference with India.
  7. various 'parameter setting' and 'tweaking'
  8. pontificate on the subject of Java versus C++. Say things like 'You don't know what you are talking about - Java's inheritance sucks'
  9. complain to Pat about the quality of his documentation.
  10. do something involving 'source control'
  11. more tweaking
  12. pull an 'all-nighter' to finish
  13. delay 3 weeks before telling Product Management (use the time to learn Klingon)