Interactive Consent

When the user is 'present', it's easy for for a provider to obtain their consent for the release of some piece of their identity being requested by another provider. For instance, if the browser is redirected from a Service Provider to an Identity Provider with a request for some slice of identity, the user is 'right there' for the IDP to pose the question 'You OK with this?' Or, if the identity is stored on the user's client, they are available to approve any identity requests.

If the user is once (or twice removed) from the provider trying to determine if the user is 'OK with this', things are trickier.

As an example, if a user SSOs into an online movie rental provider (MRP), the MRP might want to obtain the user's 'Favourite Genres' from other provider (FGP) in order to customize the selections they are displayed. The MRP can ask the FGP but, if the FGP needs clarification from the user before releasing the identity, they're all the way over at the MRP and so isn't available for interaction to clarify their wishes. What to do?

The Liberty Alliance ID-Web Services Framework defines a number of related mechanisms designed to address this issue:

1. Allow the FGP to respond to the MRP request and indicate 'Sorry, I need to talk to the user before I can give that out. Please direct their user agent to this address so I can get the clarification I need." After the user's browser is directed over to the FGP, they can be authenticated and asked for their consent to the release of identity. They can then be directed back to the MRP- which can then resend its original request for the user's preferred genres, this time with an expectation of success.
   
2. Allow the MRP to indicate within its request that it is willing to pose any consent requests the FGP might have back to the user. If the FGP does need to interact with the user, it sends the questions it has back to the MRP. As the MRP already has a session with the user, it can pose the question "FGP would like to know 'Are you OK with this?'". After the user answers, the MRP returns the approval (or not) back to the FGP as input to its authorization decision. As it is the MRP that is asking for the attributes in question, having them also attest that the user is 'OK with it' may not be appropriate in all situations.
3. Like #2 above, have the FGP send a request for interaction with the user , but to a dedicated Interaction Provider (IP) rather than the MRP itself. The IP, on receiving this request from the FGP, would use whatever channels it had available (e.g. SMS, email, IM, etc) to contact the user and pose the consent question. If the user approved, the IP would send that response back to the FGP, which would then process the original request from MRP appropriately (approve/deny).
   

This sort of mechanism within ID-WSF (and the focus on privacy-respecting consent that drove its development) often gets conveniently ignored when Liberty's architecture is pigeon-holed as 'enterprise only'.

Update: Pete comments:

Why is the obvious 4th option missing?

Send the user to FGP straight away, the FGP sends the user back with the request information, if the FGP requires something over the MRPs say so it has its interaction point right there.

Fundamentally, ID-WSF is a 'web service framework' and so the preferred channel for provider communication is a direct SOAP call rather than a browser-mediated front-channel. Justification includes:

1. the assumption that MRP will potentially be asking FGP for the list over and over (into the future) and so any efficiencies gained by using a front-channel redirect (in that consent can be obtained that first time) are outweighed by the advantages of using a direct call when consent needn't be obtained
2. A server to server web services protocol can be much richer from a functionality point of view as well as a security point of view.
3. related to the above, many of these messages are too big to reliably be handled via redirects and in many cases too big for browser-post
4. user experience and speed implications of the redirects
5. the limitations of the browser as a secure intermediary
6. the relevance of use cases where the user in question isn't even online, much less visiting the MRP

I guess a hybrid solution would have MRP use a front-channel the first time in order to faciliate FGP getting consent, and direct calls every other time. But, how would the MRP know what the FGP's (potentially constantly changing) consent requirements are in order to use the appropriate binding?

Ontari-ari-ari-o

Ontario's (map courtesy of Muskie Ontario) Privacy Commisioner has released a paper outlining how to embed privacy into Microsoft's Identity Laws. (I actually thought the laws already had some privacy stuff in there, I guess we Canadians warrant Privacy 2.0?).

The great uncertainty (some doubt and a tiny bit of fear) I've been experiencing for the last little while has been resolved - the identity system I will use to avail myself of my province's online services appears to have been decided.

Update: $@^&$*# I knew it was too good to be true - the irony was just too sweet. www.gov.on.ca does work in Firefox. So, the para below is moot.

Small hiccup though. The Government of Ontario site doesn't (at least right now) work in Firefox. So, other compatible identity card selectors aren't an option for me. Oh well, I've had to manage two browsers before, I can do it again.

Give us a land of lakes
and a land of snow
And we will build Ontario
A place to stand, a place to grow
Ontari-ari-ari-o !

1-10-1 rule

I just listened to an interesting CBC Radio interview with a cold-water researcher who goes by the name of "Professor Popsicle" when he presents the results of his research into hypothermia (always of interest to Canadians).

He recommends a 1-10-1 rule should you fall into icy water. 1 minute to get your breathing under control before attempting to get out, 10 minutes of useful efforts at escape before you run out of energy, and then finally 1 hour before your heart stops. How cheery.

Is there a comparable rule for identity theft victims?

• 1 hour of uncomfortable questioning the wisdom of giving your password to that nice person from 'tech support';
• 2 days spent with bank customer support determining if they did indeed contact you;
• 3 years to deal with the consequences.

Priceless.

Well that was unexpected

Out of the blue, and completely unprompted, Pam, on her own initiative, added an unsolicited link to this blog in her "Smart People with Blogs" blog roll.

Unrelated, how serious a breach of blog etiquette is it to ask somebody (making vague and in no way binding committments with respect to Hong Kong Ultimate tournament discs as incentive) to be added to such a list? I'm asking for no particular reason of course.

Firefox extension needed

Mark Dixon points out a risk rating system for different identity attributes.

I can see a Firefox extension that colour-coded identity requests according to such a system.

Get fancy and account for increased risk from correlation of multiple low-risk attributes.

W3C Workshop on Privacy Policies

My Liberty Alliance colleague Robin Wilton presented a position paper (co-authored by Robin, HP Lab's Marco Cassasa Mont, and myself) at the "W3C Workshop on Languages for Privacy Policy Negotiation and Semantics-Driven Enforcement" (now that would be an acronym).

In the paper we proposed a taxonomy of privacy language types for identity services, examined the relevance of various XML-based policy languages for supporting these different aspects, and considered how the Liberty Alliance's ID-WSF <UsageDirectives> SOAP Header can be used to move such policies around.

Robin's slides are available here.

Connected

Pat and I are now "friends" on Last.fm.

Pat and I are also connected on LinkedIn. And AIM. And through the social mechanisms of the Liberty Alliance Members Site.

If he and I fall out because of a late night whiskey drinking session in some Hong Kong opium den, it will take a not insignificant amount of work for both of us to eradicate the electronic manifestation of the relationship.

If only there were technologies by which a social relationship, once established, could be leveraged across multiple applications.

Pat appears to be big into The Clash. I've got this mental image of him in tight leather pants that I'd appreciate help in dislodging.

Update: Pat reminded me that in certain parts of the world (those lacking air conditioning mostly), 'pants' refers to undergarments. This little tid-bit of localization has only exascerbated my mental imagery issue.

Do the Right Thing

SAML 2.0 has the concept (originally defined in Liberty Alliance ID-FF) of Authentication Context. Authentication Context provides a set of related mechanisms by which IDPs and SPs can discuss the details behind an Authentication Statement. The IDP is able to provide details beyond the mere fact of authentication, and the the SP is able to indicate its requirements for such details.

Most people associate the <AuthnConext> element with capturing the specifics of how the user authenticated to the IDP, e.g. either using a password or (more meaningfully for maximizing the value of the SSO) some stronger authentication technology like a OTP or smartcard. This information can be important, all else being equal, an assertion issued after a smartcard authentication to the IDP is likely 'better' (from the SPs point of view) than one issued based on a password.

But Authentication Context is far more powerful than merely describing this aspect of the authentication (SAML 1.0 had an AuthnMethod mechanism that would have sufficed for this). Authentication Context gives IDPs and SPs a language to discuss many other aspects of the context of the authentication, including:

• The initial user identification mechanisms (for example, face-to-face, online, shared secret)
• The mechanisms for minimizing compromise of credentials (for example, credential renewal frequency, client-side key generation)
• The mechanisms for storing and protecting credentials (for example, smartcard, password rules)
• The authentication mechanism or method (for example, password, certificate-based SSL)

It's the SAML Authentication Classes (definitions of representative contexts for particular scenarios) for the mobile space that most obviously take advantage of this expressiveness.

For instance, the mobile oriented classes, in addition to distinguishing whether the user authenticated to the IDP with one or two factors, also distinguishes whether the IDP (likely the operator) has an account (and contract) for the user in question or whether the user is unregistered (using pay as you go cards etc). The former, with the implied opportunity for physical verification of identity that might be unavailable for a pay as you go user, might present a very different risk profile for an SP considering accepting an identity assertion from the operator IDP.

I've seen some object to the idea of Authentication Context, the view seeming to be 'Why doesn't the SP just trust the IDP to do the right thing?' If the IDP can only do one 'right thing', then that's fine. If your IDP does password authentication only and your use cases don't demand (or your security doesn't warrant) anything beyond, then all actors can be on the same page without any special mechanisms. If however the IDP has more options, then in many cases the SP will both need to be able to express its requirements of such options, and be informed as to the results.

Take-offs are OPTIONAL, landings are MANDATORY

As supporting material for tonites Nova episode, PBS has an interesting article on the risk of air travel.

The article points out that there are different ways of calculating the risk associated with flying.

You can calculate the risk of flying by:

1. Dividing the number of people who die into the total number of people, which gives you the risk for the average person;
2. Dividing the number of victims into the number of total flights all passengers took, which gives the risk per flight;
3. Dividing the number of victims into the total number of miles all of them flew, which gives you the risk per mile.

I can imagine similar variations in how an SP might determine the risk associated with accepting identity assertions from IDPs.

For some SP's the analogous "risk fraction" might be dividing the number of dollars lost (as a result of damage to reputation from fraud, legal costs, etc) into the dollars gained (from increased user retention etc); for other SPs dividing the number of users lost through identity portability over the number of users kept/added might be a more useful metric. An SP that does lots of low value transactions would probably have a different view of risk than another that engages in fewer higher-value transactions.

I bet there is an MBA thesis in here.

The article points out that the majority of flying risk comes from take-offs and landing. For identity, it's authentication that skews the distribution.

Music as identity

Last.fm allows the songs that you play to be recorded. You can download plug-ins for iTunes etc that record the songs you play and then upload the list to Last.fm. You can then embed this list as a widget in your blog so that the whole world (or at least that fraction that reads your blog) can learn about your Barry Manilow problem.

Pandora is a (separate from Last.fm) streaming music service. You might want the songs that you listened to through Pandora to also be recorded into your Plast.fm playlist (in order to de-emphasize the show tunes etc that would otherwise swamp out anything else). Last.fm has an API to allow other applications to add songs but it requires authentication.

The easiest solution would be to give your Last.fm account details (username and password) to Pandora and then have Pandora use the Last.fm API to push your played songs into your playlist there. A variation on this model is to give your credentials to a 3rd party, and have them do the integration between Pandora and Last.fm. Either way, you're handing out your password. This is of course the current default mash-up model.

The other available alternative is to keep your credentials close, and rely on an extended client to authenticate to the Last.fm API and to then push your Pandora songs. Of course, you have to pretty much take it on faith that the extension isn't sharing your password inappropriately (protestations to the contrary notwithstanding)

Everything sent by this extension goes directly to the Last.fm servers and nowhere else

Of course, the best solution would be for Last.fm to accept a security token attesting to my identity in its API and not require the password itself.

You could build some really cool social apps with a 'Playlist Service' defined on top of Liberty Alliance ID-WSF. I'd love to be able to define things like 'If 2 or more friends of mine play a certain song (that I haven't listened to) within the last month, put it on my "Consider listening to" list'. I find that the challenge for me with music these days is how to get exposed to new material that I'm likely to like. I want a system that automates the e-mails I currently receive from friends with subject lines like 'you should give this a try'.

Nobody has yet defined such a service interface for music playlists (AFAIK) but all the social, privacy, and security plumbing is already in place in ID-WSF.

Privacy Negotiation in a Flat World

In this NY Times article, the description of how E-Loan deals with outsourced data privacy is interesting

E-Loan Inc. customers worried about safeguards when data get outsourced to India can choose to have loan applications processed domestically, though loans in such cases would take two additional days to close.

Not only is the customer given options for controlling how/where their data is processed, but importantly they are explained the consequences of the choices they make.

The same idea as demonstrated in this Flash.

I wonder if those who opt for local-processing are making an informed decision, i.e. basing their choice based on objective analysis and not some xenophobic gut reaction. I expect E-Loan doesn't disclose which data centers, US or Indian, have better records for employee retention - always a factor in privacy goodness.

2-day difference in loan processing times, hmmm. North America will never be able to compete until we get computers that are equally as fast as those being used in Asia.

The 'op' doesn't stand for 'optional'

The Register reports on a schema by which airline passengers would be tagged while in the terminal.

At first glance I was worried about the privacy implications of OpTag but I'm reassured by the stated motivation

Up to 5% of aircraft departure delays are caused by late passengers or late bags at the gate, and the impact of this in missed slots and subsequent costs will increase as the number of flights increases. The OpTag system will enable the immediate location of checked-in passengers who are either missing or late, and thus reduce passenger-induced delays and speed up aircraft turn around.

Oh well that sounds just fine.

Oh wait, perhaps there is an alternative. Why not forget the privacy-invasive necklaces and just pull back from the gate at the designated time. If Billy-Jim loses track of time in the 'Some Name Here Brewing Company', bad luck for him. He can catch the next flight to the Shriner's convention.

ELgg & Liberty Alliance

ELgg is an open source library for a 'personal learning landscape with the goal of connecting learners, instructors and resources creating communities of learning.'

And, according to the European Institute For E-Learning (which I believe the ELgg activity is part of) EIfEL, they're working on integrating Liberty Alliance People Service for the social layer.

Users establish personal digital identities and connect with other people, collaborate with them and discover new resources through their connections. Plugins allow users on different social networks to collaborate, and provide specific functionality for tasks like project management, mobile browsing and collaboration through user-controlled wikis.

The emerging ELgg support for Liberty Alliance ID-WSF components expands on the existing support for ID-FF (as well as OpenID it would seem).

Organizing education sessions in pubs should serve as an example to the industry. It definitely motivates me to learn more about ePortfolios and the potential relevance of ID-WSF to sharing CV information.

Monotreme

GreaseMonkey has always been powerful. It's a Firefox extension that gives you the ability to customize the HTML etc that gets displayed in the brwoser - you needn't be constrained by what gets served up. I've previously played around with a bit.

But, unless you were able to use an existing script created for a well-known page, or were willing to get in and edit a script by hand to create or tailor, GreaseMonkey hasn't been particularly accessible to the masses.

Enter Platypus, another Firefix extension. Platypus is as a WYSIWYG editor for creating GreaseMonkey scripts. After installing both extensions, when visiting a page that you want to customize (e.g. remove some screen components, rearrange components, etc), you use the Platypus toolbar


to make your desired changes, and then 'Save' those changes to a GreaseMonkey script. The next time you visit that same page it will appear as you customized.

As an experiment, I used Platypus to customize the login page at Sxore (chosen because it, in its unmodified form of supporting multiple identity systems/options, demonstrates the potential for user confusion about identity options). I removed all screen elements but the 'Log in with OpenId' option to remove some of this confusion. The result is below.


Irrelevant (for me) options are removed. Others would tailor to suit their tastes.

Beyond removing some visual identity clutter, allowing users to tailor the identity components of pages would act as a poor-man's anti-phishing mechanism. If I were to visit a phish site purporting to be Sxore, the GreaseMonkey script would not kick-in and I'd see the default interface, possibly clueing me into alertness.

The platypus belongs to the monotreme family of mammals, distinguished from other mammals by the fact that in the monotremes a single opening (the cloaca) serves for urination, defecation, and reproduction. Perhaps then the relevance of Platypus's name to identity is to hilite the danger of overloading a single interface.

Monotreme's are also characterized by the fact that females lactate from openings in their skin as opposed to defined nipples. No analogy comes to mind.

OpenID's DTP & Darwinism

Scott Kveton responds to my implied criticism of the OpenID DTP proposal.

The fact that it ignores other standards may be true but one of the design goals is to do for data transfer what OpenID has done for single sign-on; light-weight, simple, easy-to-implement, etc. Think of the proposal as a best-of-breed of those heavier technologies.

To my mind, best-of-breed implies that the old and new are still of the same breed. But, were OpenID to continue down this road, DTP and the existing XML-based messaging stack would be completely separate species with no chance of successful intermixing.

To Do: make some analogy on how whippets and St. Bernards, bred for very different applications over generations of artificial selection, can still interbreed. ...

Scott adds:

The same can be said of OpenID as it relates to SAML ...

I agree.

Regardless, a comment from Grant Monroe on my original post indicates that the next rev of DTP will ditch XML completely and instead build on MIME and S/MIME. So, it seems this particular concern is moot.

Most innovative use of an away message

I sent an email to some friends as a call for volunteers to help with a litter clean-up on a nearby road.

Deafening email silence from most conscripts followed.

I did receive the following from one inventive friend.

Thank-you for your email. I will be out of the office until February 18 2007. I will reply upon my return.

Ian

It might have worked if the reply hadn't taken 3 hours. If you're going to run a mock MITM attack you have to be faster than that.

Conor buys into Passport

I kid you not. And what's more, he is storing sensitive information on it! I thought we had moved beyond centralized storage.

CrazyEgg

CrazyEgg allows you to visualize the visitors to your site. Embed a little script and sit back.


The above heat-map graphic is very informative. It tells me a number of things about my blog and how people interact with it:

1. I was more interesting a year ago than I am currently.
2. There is nothing more pathetic than a cold heat-map.
3. My profile has not changed since I last checked

Tools like this could provide an interesting visual insight into the usability of new identity interfaces from the heat-map of user's clicks. Unfortunately, CrazyEgg would be incapable of tracking the ACT ('Anguished Confusion Time') spent with mouse button poised, during which the user tries to decide whether to 'Log-in Locally', 'Log-in at your Identity Provider, 'Register a New Account', or 'Provide your Identity URI'.

Identity Use Case

Emergency exit row s can make a long flight bearable. Unfortunately, Air Canada does not allow these seats to be booked online, the agent at check-in has to make an assessment of your ability to hoist the door if necessary before assigning these seats.

Now, if the Air Canada booking system were to receive an assertion as to a passenger's size and strength from a trustworthy source, then the need for a visual once-over from the agent would disappear. If Dr Jones says you can lift the exit door, that would be good enough.

An advanced system could balance the plane based on weight, assign skinny people seats next to those with a tendency to spread beyond their allocated space, or put me right next to a chatty Grandmother with multiple photos of her family (oh wait that already happens).

Fortunately no overlap with WML

This OpenID proposal ignores existing XML-based standards that provide the very same functionality.

These alternatives are admittedly somewhat obscure in the industry, little known specs like SOAP, WS-Addressing, WS-Security, XML Signature, and XML Encryption.

Fortunately there appears to be no duplication between this proposal and WML. Consequently, at least for mobile markup we don't have to worry about convergence. Bullet dodged here for sure.

Hong Kong Ultimate

It's very infrequently that I'm able to fit anything into a business trip other than the occasional dinner and the mandatory shopping trip.

Consequently, I'm really looking forward to being able to combine an upcoming trip to Hong Kong for a Liberty Alliance meeting with an Ultimate Frisbee tournament. The Hong Kong Ultimate Players Association is hosting the Hong Kong Pan-Asian Ultimate Tournament October 28-29 in Aberdeen Stadium.

I noticed that the Hong Kong league site would require me to create an account in order to post to the forums or comment. Maybe I can convince the Liberty Alliance to pay for my tourney fees and a disc if I can make a sale?

Sites considering hiring consultants & lawyers could save themselves some money by simply agreeing to abide by Ultimates' Spirit of the Game' guidelines

1. The golden rule: treat others as you would want to be treated.
2. Control: SOTG takes real effort.
3. Heckling and taunting are different.
4. SOTG is compatible with championship play.
5. Don't "give as you got."
6. Breathe.
7. When you do the right thing, people notice.
8. Be generous with praise.
9. Impressions linger.
10. Have fun.

I try to follow #3 in all aspects of my life.

OpenID Sequence Nits

Two nitpicks with the protocol flow as described at OpenID Enabled (admittedly based on what I think I know and not what I really know about OpenID)

1) Step 3 is as follows:

3: Consumer associates with server (option 1) - In order to communicate securely with the server, the consumer gets an association with the server discovered in step 2, using an existing association if it is available, otherwise visiting the server and using Diffie Hellman to negotiate a shared secret with which to sign communication.

As written here, the consumer uses an existing association in order to get an association? I believe the intent of the above para is something more like

If necessary, the consumer establishes an association with the server discovered in step 2. If the consumer already has an association with the server, or is capable of dumb-mode only, it MAY skip this step.

2) Step 4 indicates

The OpenID server URL accepts a query, containing all the information the server needs to check the user's identity and redirect the user back to the consumer. The server checks the authentication of the user. If the user is signed in (has an auth cookie) and has already authorized sending their identity to the consumer, step 5 may be skipped.

and Step 5 includes

The user authenticates to the server with a cookie or a username and password, and the server asks the user for permission to send their identity information to the consumer.

Both steps refer to the user authenticating to the server and the result is confusing. I think the intent was more something like

Step 4 - user agent is redirected to server (along with information the server may need to direct the browser back to the consumer)

Step 5 - user authenticates to server, either with existing cookie or, if not present, with a password etc. At this point, the user is asked if they consent to their identity being sent to the consumer. If the user has already authorized identity being sent to the consumer, this previous consent declaration may be used.

SAML & IMSafer

Kaliya asks me to explain how SAML could help address the issue that IMSafer faces in tieing together IM accoounts so that parents can be confident that their kid's IM conversations at both home and work are appropriately monitored.

From the original TechCrunch article on IMSafer came this line:

While multiple screen names can be tracked at home, the company is working on a tool to associate different screen names across school and home to notify parents.

A not insignificant piece of SAML 2.0 deals with the establishment of connections between such disconnected accounts in order to facilitate subsequent identity-driven interactions, whether those transactions be SSO, attribute sharing, or 'dangerous chat language notification'.

If the child had two different IM handles or used different systems, then a connection could be established between them in the form of a persistent & opaque identifier (different from either IM name) to ensure that the appropriate parents can be confident that they are covering all "conversation bases". Likely better would be to establish multiple identifiers, one between each IM provider and IMSafer. SAML defines how these connections can be established, nothing about the specifics of how you build a notification system for dangerous phrases using these connections.

Build the system on Liberty Alliance ID-Web Services Framework and you get alot more - parents could specify their own favourite dangerous phrases for monitoring, use a People Service to manage the privileges for creating and managing accounts, and build on the WSF notification framework.

Kaliya then asks:

Isn’t the whole point of the Laws of Identity that people should not have there identifiers aggregated across contexts without their knowledge.

Who said anything about doing this without the knowledge of the kids? SAML could definitely be used in an underhanded way to establish the connections between IM accounts (just as IMSafer can be run in covert mode - the FAQ 'advises' parents to tell the kids it's installed). SAML can also be used in an open, privacy-respecting user-centric manner to do the same (like the multiple identifier model above in which the kids could be involved in the establishment of the identifiers and so be completely 'in the loop'.) Is there any identity system that we can't say the same thing about?

With respect to privacy, it seems there are more fundamental issues. From the IMSafer FAQ:

How do you know what IM accounts to monitor?

When a user on a computer onto which you have installed the IMSafer client software uses IM, we automatically detect it and start monitoring the account. You don't have to do anything. How nice is that?

Now that's informed consent!

Obscurity through Noise (reprise)

If was a musician these days and didn't want my music shared on P2P networks, I'd choose a name that would hinder efficient searching.

Something like 'rolling' or 'stairway' or 'champion'. Valid hits would be swamped by the noise from the more common alternatives - you can't download what you can't find.

I have absolutely no idea what made me think of this.

Obvious social applications

downloadsquad reports on a 3-D search engine. How long before a MySpace implements?

When searching for 'friends', no longer will you need to describe the desired physical characteristics, you'll just sketch them out.

A tool for drawing circles would be a significant usability boon for many men.

Code metrics for Identity

Google's Code Search allows you to search public code.

My analysis of the results when searching on identity-related terms (raw data below)

• Ideally, the numbers for identity & privacy wouldn't be different by an order of magnitude.
  
• Everybody always goes on about how much Scott Cantor has does for SAML but he's only got 50 more hits than me!
• Related to the above, apparently the Javascript rollover script I stole and tweaked 3 years ago doesn't count as 'code'.
• There are far fewer 'stupid users' than we might otherwise have assumed.
• Similar to 'existentialism', 'user-centric' doesn't appear to manifest itself in code (this one was a shocker to me).
• Many American developers use snippets of the Declaration of Independence as a test string.

user ~ 2,870,000
identity ~ 301,000
privacy ~ 57,000
shib - 31,500
liberty ~ 28,600
SAML ~ 14,000
OpenID ~ 10,000
pseudonym - 6,000
liberty alliance ~ 5000
ID-FF ~ 100
stupid user ~ 100
YADIS ~ 100
user-centric ~ 100
existentialism ~ 50
scott cantor ~ 50
WS-Federation ~ 7
paul madsen ~ 0

Blood - it's in you to give

I just received a new donor card from Canadian Blood Services.It has my blood type on it but I don't know why?

Given the danger of mismatch, would anybody ever be willing to take this assertion on face value and not directly verify my blood type? If I told the nurse my type when I went in to donate she'd smile at me and say "That's nice dear, but let's check anyways shall we?". The claim as to type on the card might as well be similarly self-asserted.

So, what purpose does the blood type assertion on the card serve?

Maybe it's some sort of confirmation method for the token. If my tested type matches that on the card then that's some evidence that I am indeed the valid owner of that card (further evidence probably provided by separate identification).

Apparently, only 6% of the Canadian population has my blood type. It's like I'm like an online banking site with exclusive criteria for which IDPs I'm willing to accept assertions from. In this case I think I'd prefer to be more like some "universal recipient" blog site.

Update: Anon's comment makes sense. The blood type is there for me, and not for the 'relying party'. Is there an electronic analogy? Perhaps a friendly name on a long-lived token stored on a smart device in order to remind the user of its applicability?

Update 2: Pam trumps my 6% with her 2%. Big deal, it's not like I had any sort of emotional investment in my relative uniqueness .... I do think I'll demand a recount though. Maybe the chads were hanging.

Yea verily!

Ping's Andre Durand, in an interview

KCP: I had the feeling at Digital ID World that some people are using the term user-centric to describe sort of the next big thing after federation, implying that federation was yesterday. Doesn’t that worry you?

Durand: That’s my point. However, I understand the marketing aspect of it. Its about creating a new category and dominating it and attempting to disconnect it from the prior category. That’s all happening on the marketing front. I just don’t want the technicians and customers to buy into the marketing jargon that’s been fairly self-serving for those that are looking to create a new sandbox to sell from. The reality is that when we’re talking about identity you can’t have a break in the chain. Identity transactions are going to be chained together and most of them either start or end in a business, so you can’t separate the business infrastructure from the consumer infrastructure in terms of the ability to do business with the business. It’s just one big continuum and if we need to add capabilities such as privacy and user mediation in the transaction, then so be it, but that’s not something completely separate.

DinkAlert

LinkAlert is a Firefox extension that shows an icon appropriate to the target of a link on mouse over.

YASNs would benefit from something comparable that showed the calculated reputation of the referenced individual.

I think I'll start collecting icons in anticipation. Here's the first in my collection.

We're not needy, we're just driven

Liberty Alliance published yesterday a retrospective of the marketing requirement documents (MRDs) that have driven the technical specifications.

It's from these documents that the Technical Expert Group worked (and often cursed), the use cases and derived requirements guiding us in the development of protocol specifications that met the requirements. So, for instance, you can see a 1-to-1 correspondence between the sections of the WSF 2.0 MRD and the spec'd out People Service and Subscription functionality.

The MRDs make for interesting reading. One use case from the WSF 1.0 MRD stands out for me. In Section 3.1.1.3:

An SP may wish to provide basic personalization services to its visitors/customers without requiring them to have an account at the SP or even identify themselves at the SP. Hence a user may anonymously share certain attributes with such SPs. For example, an SP may not require any sign-in by the user on their initial visits. Nor does the SP require the user to have an account at the SP. Yet, the SP may want to provide basic personalization based on attributes such as preferred language, gender, geo-location, time zone, etc. The user, when visiting the SP, may see content personalized to the user's preferences. Such personalization is the value-add provided by such SPs to attract customers and increase airtime and online time usage.

Note the anonymity is intended to protect the identity of the user. The SP never gets an identifier for the user, not even a repeatable pseudonym. Therefore, even if the user re-visits the SP a minute later, the SP would not know if it is the previous user visiting again. However, such anonymity (privacy) does not exist if the user willingly gives the permission to anonymously share his/her PII (Personally Identifiable Information) such as social security numbers, driver's licenses, passport numbers, etc.

This use case, the derived requirements, and the resultant support in WSF may not fit the image of "hard-coded federations" that some seem to have about the Liberty Alliance's architecture.

Standard Loses 200 Pounds in 1 Day on New Miracle Diet

Jeff Hodges and Scott Cantor have released an updated version of their HTTP POST "SimpleSign" Binding.

The 'SimpleSign' in the name refers to the binding's use of a (if signatures are used at all) 'sign the blob' model for message integrity and authentication rather than using XML Signature (as is the case in the existing SAML HTTP POST Binding).

XML Signature is part of the 'weightiness' that some associate with SAML. The 'un-wanted pounds' that SAML supposedly carries are seen as an artifact of the formative years it spent in an enterprise cafeteria eating subsidized lasagna and drinking watered-down Coke.

Even with its love-handles, SAML has had no trouble getting dates. But I think of this binding as SAML flexing a bit, showing off a new leaner bod, and getting ready for new relationship opportunities (such as
SAMLv2 Lightweight Web Browser SSO Profile). And of course, the tall-n-husky SAML is still around as well, should you be looking for a more secure relationship.

And he didn't even get miles

In her biography of Queen Isabella, Alison Weir describes the wandering lifestyle of a medieval court such as that of Edward II.

During his reign, Edward II lodged at more than 4,000 places in England.

I guess if I was married to someone known as a 'she-wolf' I might be looking to stay over the Saturday night whenever possible as well.

Liberty Alliance Releases Web 2.0

Oops, that should have been 'Liberty Alliance Releases Web Services Framework 2.0' - apologies for any confusion.

Details of what this release is about are available here.

I'm doing a webinar on WSF 2.0 along with Ericsson's Carolina Canales-Valenzuela (some other long name here) tomorrow. Carolina will be the one with the charming accent who doesn't end every sentence with 'eh'.

InternetNews thinks it took a long time. Believe me when I say it felt even longer from this side of the PDFs.

Consenting Lawyers

Lawyers would love to be this involved in every identity exchange.

Lawyer 1: My client is willing to provide first name.
Lawyer 2: C'mon, that would be like milking the horse before the cow, my client absolutely needs email address.
Lawyer 1: What if we threw in postal code?
Lawyer 2: For home address? or shipping address?
Lawyer 1: My client would be willing to give both if you got rid of the ridiculous request for their sexual preference.
Lawyer 2: It's not ridiculous, my client needs that information before deciding whether or not to proceed with this relationship.
Lawyer 1: C'mon, we're in a gay bar, get it from the context!
Lawyer 2: Ok, ok, we can bend on this. But not on email address - that's a must have.
Lawyer 1: (after whispering with client) Ok, here you go.
Lawyer 2: What the &$%@# is this? I said we wanted an email address!
Lawyer 1: It's a URI. It's like an email address but protects my client's privacy. Your client would go that web page and leave a message.
Lawyer 2: Where did you learn your law? I didn't say we wanted something 'like' an email address. I said we needed 'an' email address. Jeez, go read PIPEDA before wasting our time like this (packing up papers).
Lawyer 1: C'mon, sit down and relax. My client will provide her real address on the condition that it not be shared with anybody else and thrown away after a week (whispering with client) Oh, wait, clarification, not shared with anybody ugly.
Lawyer 2: (after whispering with client) Would writing it on the bathroom wall be considered acceptable usage?
Lawyer 1: (more whispering) My client says yes, but only in a small font.

User-centric Screen Scraping

Dapper is cool. It provides an interface and service by which you can build your own screenscraper (they don't call it that) for any arbitrary site and then output the scraped content into various formats (e.g. HTML, custom XML, RSS, iCal, etc).

So it's an end-run around sites that don't themselves provide APIs. You use Dapper to scrape their pages and effectively create your own API. The key difference is that you define what gets scraped rather than somebody else.

As an example, I created a 'Dapp' from this blog, using the Dapper interface to specify that I wanted only the post titles and following metadata (e.g. posted by, # of comments etc) scraped. I chose to have XML as the output format and the result is here. No programming necessary (although some would be required in order to use the 'feed').

Inherent to screen-scraping, it's fragile - as soon as I change the blog template, the Dapp could break. I also wonder how long the window of opportunity will remain open - if Blogger had an API and gave me (or others) control over what data was relevant then the need for Dapper disappears.

Well duh

Kaliya blogged the TechCrunch article on IMSafer.

From that article, the following caught my eye:

While multiple screen names can be tracked at home, the company is working on a tool to associate different screen names across school and home to notify parents.

If only there were technology to help.

Updated SAML Basics Slides

Eve has uploaded a new version of her excellent deck to the OASIS SSTC public page.

It's available in both OpenOffice document format and PDF (the source format is supposed to have some animations but I couldn't see them).

For me, it's the graphics that steal the show (isn't there some saying about graphics and their worth etc?), especially the callouts on the various XML structures.

Cardspace on Zune?

Why not? Zune's primary distinguishing feature seems to the wireless connectivity designed to enable (DRM-constrained) song sharing. I wonder what control the user will have over such sharing, a binary on/off determined by enabling WiFi? Or something more granular?

Cardspace would allow a Zuner (can I trademark this?) to specify which identity aspects get advertised in which contexts. I might show a different set of songs in an after hours (I hear they can be open till midnight!) club than I would in an airport terminal. Other Zuners could define ACLs for their playlists and songs in terms of the required identity characteristics of potential recipients (e.g. if you advertise that you like 'Broadway Show Tunes' then you should just keep searching).

I'd be interested to hear Microsoft's story on how they see Cardspace working in a social world.

Mothers-in-law & technology

Before she lost her son last month, if you had said 'web address' to my mother-in-law, she would have assumed you were talking about the street location of a spider's spinning endeavours. No longer unfortunately.

A photo site dedicated to her son, and her desire to inform far flung friends and family of it's existence and location, has forced her to deal (albeit from a distance) with the technology she so successfully avoided up till now.

Of course she doesn't have email, so the communication channel by which she broadcasts the above address is good old Canada Post. Consequently, there have been many a phone call along the lines of:

Mom: Can I get that address for Jamie's photos again?
Me: Sure, it's 'w w w'
Mom: capitals?
Me: doesn't matter , but no, no capitals.
Mom: OK, 'www'
Me: 'dot flickr dot com'
Mom: Got it
Me: Now a line starting from bottom left and ending top right
Mom: K
Me: 'photos' and another line like above
Mom: K
Me: 'jamiemurraylife' and that's it
Mom: Got it. Any dot at the end?
Me: Nope. Now it doesn't change so you could write it down and save it for next time
Mom: Oh, I'd probably just lose it. I'll just call you back.
Me: Righto. Talk to you tomorrow.

Using the POTS to communicate a web address for snail mail forwarding. Now that's convergence.

I agree 100% but ......

Ping Identity's Patrick clarifies his thinking on what user-centric identity management is, and how various identity systems (e.g. Cardspace, SAML, OpenID etc) can support it.

Patrick reintroduces his 'passive' and 'active' distinction, expressing the varying abilities of clients for enforcing the user's wishes for identity sharing (and probably other identity functions like IDP discovery too).

One issue. Patrick writes

I would argue that active federation is superior to passive federation when the requirements of user-centricity are to give the user the ability to independently enforce control and privacy stuff.

The caveat here is that active federation implies that the user is an active participant in the flow of identity (if not necessarily aware of it because of stored privacy policies). So, active federation requires that the user be 'online' (e.g. be sitting at their desk, looking at their phone, or having inserted their USB dongle into an airport kiosk).

Lots of use-cases have the users online so that their client can actively mediate their identity flow, lots of others don't.

Who dat?

Whobar is a cool library from Sxip that simplies the integration of some of the various identity systems into sites.

This pic shows Whobar in action at Sxore.

I guess the user would see the same interface at any other site that implemented Whobar.

Note: the use of 'Homesite' on the left, while perhaps appropriate for Sxore, seems to tie it too closely to Sxip for the general case? I wonder if this is configurable?

The above pic hilites the usability challenge of how to present log-in and/or registration options to a user. I'm no UI designer but have to question whether the above is optimal. As the number of options for logging-in grows, and the opportunity for confused users grows accordingly, maybe we need to separate out the possibility of registration, rather than intermixing the two as the above does?

Whatever does turn out to be the best (in the sense of minimizing user confusion) interaction solution, the Whobar model could make practical the reproduction of that sequence across sites.

Ping Cardspace implementation oddity

I used Chuck Mortimore's Firefox extension to present a self-asserted card to Ping's IDP, which, after doing the Cardspace dance, displayed the following on the IDP portal page.



It's the 'PASSWORD' as authentication context that confuses me.

I didn't authenticate to the IDP with a password, I did so with Cardspace. More precisely, I authenticated to the IDP (acting as a Cardspace RP) by proving I had a key through an XML-Signature. So, strictly speaking, the appropriate SAML Authentication Context class should be 'XML Signature'.

A Cardspace user will sometimes be required to authenticate with a pin or similar to a local key store (and so it could be conceivable that there would be a password in the mix). In such cases, just saying 'XML Signature' wouldn't adequately describe the authentication context. The options would appear to be to use combinations of existing AC class URIs or define new SAML AC class defined specific to Cardspace.

Update: Patrick Harding reminded me that Cardspace uses SAML 1.1 so doesn't have the full expressiveness of SAML 2.0's Authentication Context available. The conjecture is that Ping's Ashish Jain, because of this lack of expressiveness, had to fall back on 'password'.

A book waiting to be written

Conor's Bi (directional argument)

I'm sure he would have preferred to actually get in and invoke 'editorial privileges' to modify my post but Conor has settled for a response.

While I'll admit there's a certain level of consistency to Paul's proposal, I still think that the right way is to put the identifier in the NameID value rather than the SPProvidedID. My reasons include:

* The NameID carries the value chosen by the "IdP" to represent the user at the "SP". In this case, the Former-SP-Now-Acting-As-An-IdP has chosen to use the identifier that it had received from the Former-IdP-Now-Acting-As-An-SP. Therefore that value belongs in the NameID elementnot in the SPProvidedID attribute.

The other interpretation is that, when playing their initial roles, the SP and IDP made the following commitment to each other:

SP: Dear IDP, when I communicate with you I will use the 'abc' identifier (in the NameID) that you created for me.
IDP: Dear SP, when I communicate with you I will use the 'def' identifier (in the SPProvidedID) that you created for me.

The question is, does this commitment still apply when the two providers switch roles?

Conor will argue that the initial commitment is more along the lines of:

SP: Dear IDP, when I (acting as an SP) communicate with you I will use the 'abc' identifier (in the NameID) that you created for me. When however I (acting as an IDP) might communicate with you, I will use the 'def' identifier (in the NameID) that I created for you.
IDP: Dear SP, when I (acting as an IDP) communicate with you I will use the 'def' identifier (in the SPProvidedID) that you created for me. When however I (acting as an SP) might communicate with you, I will use the 'abc' identifier that I created for you.

I don't know which it is (and don't really care). I just don't believe its straighforward to infer the right choice from the specs.

* The SAML 2.0 Core Specification does not allow for a null value in a persistent identifier (see section 8.3.7).

I wasn't arguing that the Former-SP-Now-Acting-As-An-IDP should insert the null string, but rather that consistency with the double identifier case as he laid it out forced it to. More precisely, consistency with the double identifier case required it to insert the identifier previously created by the Former-IdP-Now-Acting-As-An-SP in the SPProvidedID attribute, and that it had no other identifier to place in the NameID element - thus 'null'.

So, consistency between the single and double identifier cases breaks SAML (as SAML doesn't define a null.

Reductio ad absurdum.

* Lines 3326-3332 and 3350-3356 of the SAML 2.0 Core Specification actually discuss the case of an SP using the same identifier provided to it by an IdP when that SP-now-acting-an-IdP issues assertions pointing out that they would need to identify the original issuing party using the NameQualifier attribute.

As I read them, these two paragraphs from the SAML spec require that the Former-SP-Now-Acting-As-An-IDP, if they use an identifier initially created by the Former-IDP-Now-Acting-As-An-SP, to use the NameQualifier attribute. So, the example from my first response was incorrect, it should have been

<saml2:NameID Format="persistent" SPProvidedID="def" NameQualifer="IDP.com">
     abc
</saml2:NameID>

Ironically, I believe that this sentence (Line 3352):

If a service provider that receives such an identifier takes on the role of an identity provider and issues its own assertion containing that identifier, the NameQualifier attribute value does not change (and would of course not be omitted).

supports my model as it implies that the SP, in a reverse assertion, would use (in the NameID element) the identifier previously created by the IDP, and not the identifier it has previously created.

Badges? we don't need no stinkin' badges

Central Scrutinizer proposes a new twist for those 'Web 2.0'y badges

Identity start-ups should not be ignored.

Never Say Never

I don't have quite the same amount of faith as Bavo De Ridder does in Liberty Alliance's new intro to our specification set.

I know I've heard 'recalculating' countless times from another system that makes the same claim.

Let your users do the walking

Wired has an article on how map data companies get their information. Assuming sufficiently accurate GPS data from a phone or PDA, they could get real-time data from users themselves.

Maybe everytime a user alerts the system to the status of a road changing, they get 50 cents off their morning coffee. Extra points for new road construction. You'd need a Karma-like reputation system or rely on duplicate reports.

When in Rome

I'm reading through the XDI.org OpenID Authentication Service, which profiles how to use XRI and OpenID together.

The initial document metadata leaves no doubt that this doc is coming from XRI enthusiasts/advocates.

Fair enough, they are eating their own dogfood (no pejorative connotation intended).

Interestingly, although Drummond Reed is also an editor of the comparable document profiling how XRI and SAML can be composed (XDI SAML Authentication Service), in that document's metadata, he goes by just plain ol' 'Drummond Reed, Cordance'.

Drummond appears to be managing his identity just fine - choosing the right persona for the particular context. And he's not even using desktop software.

Give me a 'P'!

A certain unnamed business class traveller alerted me to the fact that, if you closed one eye and leaned sideways, his upcoming travel itinerary spelled out a 'C' when mapped onto the globe.

I hereby vow to fly IAD-SFO-YVR-YYC-DEN-SFO before I die.

Bi-directional federation in SAML

Conor proposes a model by which the federated identifier(s) established in one "direction" can be made to serve double duty in the other direction.

For instance, if an IDP and SP agree to use 'abc' whenever they communicate in order to refer to a particular user (either in an IDP Response or some SP message), then that same identifier could be used were the two to switch roles. So, if the SP (acting as an IDP) were to issue an Assertion for the user in question, the SP would use 'abc' in its NameID rather than some other identifier that the two providers might feel the need to establish for this direction).

Seems to make sense.

But if, instead of there being a single federated identifier 'abc' for the user between the two providers, as will happen if the SP avails itself of its right to specify 'def' as the identifier (called the SPProvidedID) it desires the IDP use when referring to the user, then things don't seem as clear.

Conor recommends that, in this case, when the SP switches roles and creates an Assertion for the user to be delivered to the IDP, the SP also effectively switch identifiers, and use that identifier it previously specified as the SPProvidedID as the primary identifier. So, the NameID of the reverse direction Assertion would look like

<saml2:NameID Format="persistent" SPProvidedID="abc">
     def
</saml2:NameID>

This model can be justified because the 'abc' identifier was initially generated by the IDP (but now consuming it playing the role of an SP). So, placing it in the SPProvidedID attribute makes sense. In this model, providers use the identifiers appropriate to whatever current role they are playing, rather than whatever role they might have been playing when the id was established.

Problem is, I think the alternative option, in which providers, once they've agreed upon an identifier(s) to use, use that identifier regardless of the roles they may find themselves playing in the future. In this case, because the two providers initially agreed that, when communicating from the SP to the IDP, the 'abc' identifier is the right one to use, the SP would do just that in its Assertion to the IDP. Consequently, the NameID would be the mirror image of the above

<saml2:NameID Format="persistent" SPProvidedID="def">
     abc
</saml2:NameID>

There is I think justification for this model in trying to stay consistent with the case where there is only the single 'abc' identifier. For this case, to be consistent with the model where the choice (and location) of an identifier is determined by the current role of the provider using it, then the NameID in the reverse direction would necessarily appear as:

<saml2:NameID Format="persistent" SPProvidedID="abc">
     null
</saml2:NameID>

As it was the IDP that originally created the 'abc' identifier, then (when acting as an SP) that identifier needs to appear in the SPProvidedID attribute of the reverse Assertion (phew, say that 5 times fast). And, because the SP had never generated its own identifier to give to the IDP, it has to insert 'null' as the value of the NameID element. But, the above is different than what Conor proposes for this simple single identifier case.

Conor appears to acknowledge the choice, as he writes:

With that minor understanding, the remaining SAML 2.0 profiles, including Browser SSO, all work out-of the box bi-directionally.

Tokyo Liberty Alliance Day 2006

I'm looking forward to participating in the Liberty Alliance Day 2006 in Tokyo on October 30th. I'll be presenting the Liberty Alliance People Service.

I have to work in the 'Web 2.0' theme/meme into my existing material. Liberal sprinklings of 'mashup' and 'remix' should get me close. Must remember to get a 'long-tail' graphic.

I'm not looking forward to the air travel for this trip quite so much (I did have the option of a much shorter itinerary but couldn't resist the somewhat toroidal shape of this set of flights).

Taking pictures of the various economy traytables I will be sitting behind will consume, oh perhaps, 1 minute of the total 40 hours of flying time. No matter, I find the pain from my knees hitting the aformentioned seat backs makes the time just fly by.

FutureShock

FutureMe allows people to send email messages to themselves at some designated time in the future. Depending on how far forward into the future the send time is set, it's either a reminder service or a personalized time capsule service.

The FAQ attempts to address a fundamental issue with the time-capsule model:

but what if i don't have the same e-mail address in the future?

a possibility for sure. we recommend using an address with some potential for longevity (hotmail, yahoo, your own domain). in addition, we created a account management system so that you can change the addresses of your future letters. (though that's kind of cheating.)

I expect the XRI people would have something to say about this.

When I signed up for an account (Conor, do these sort of test accounts count towards my total?) I specified an email address (which was not verified). When I attempted to use the system to send a future message, I provided a different address to see if I would be allowed. I was. Consequently, I can send into the future helpful 'reminders' to my friends and colleagues.

Examples might include 'Hey, if you owe Paul any money it's time to pay up' or 'Are you still taking credit for the work of your Liberty Alliance colleagues?". Endless fun ahead for me.

Unrelated, I love the disengenuity of the following:

how can i make a cash payment to said fellas for providing such a nifty service?

we're glad you asked. we've set up an amazon honor system thing. it's fresh. you can use paypal too if you'd prefer. they take less money away. see, if you donate a tiny amount of money, we spend less of our money. FutureMe is a free service and will remain so, but it does cost us a bit of cash to maintain the site and ensure proper delivery of your so-very-precious future letters.

Fair enough except for this from the privacy policy:

it is important to recognize that "public letters" submitted on FutureMe.org become solely the property of FutureMe.org. FutureMe.org reserves the right to edit and reproduce any "public letters" as the sole copyright holder (i.e. we're putting together a book and it's very exciting).

So, while we are waiting for the book royalties to come in we'd appreciate some micro-love sent our way.

Identity systems as fried pastries

Pete (like Mark before him) jumps on the toroidal shape I used to depict the "spatial scope" of identity systems.

All I can say is that these shapes, misleading as they may be, are better than my first attempts at 3D drawing.

Speaking of Canadian pastries, Tim Hortons sells Timbits, tiny 'bite-sized' donuts. Timbits are sometimes presented (by me at least) as the remnants of the donut manufacturing process - the mythical 'bit' from the middle that would be otherwise discarded.

An offering of questionable value and necessity made viable by positioning in opposition to a well-established existing solution - purportedly filling holes in these existing alternatives? I'm just glad the identity standards industry is beyond such shenanigans.

There has to be an identity analogy

From Boing Boing, a mechanism for ensuring the security of checked luggage.

What could you put in a SAML Assertion to ensure that nobody would try to peek inside? Maybe Bush's inaugural speech? Village People lyrics?

I know a Base-64 encoded pic of Celine Dion would keep me and 25 million Canadians out.

Liberty Alliance top ground

Pam had previously pointed out the deficiencies with the Liberty Alliance Web site, implicitly asking 'Where's the Beef?'.

At the time, I hinted that a new version of the Liberty Alliance site was coming that would hopefully address the concerns she raised. Well it came.

Worth noting in the new site:

• A search that actually appears to find appropriate items (although I question the relevance of a search based on ini files? )
• A 'Public Community' page for both member and non-member use (account required, how ironic)
  
• A snazzy Flash graphic as a navigator for the specifications and hopefully helps to address the 'Liberty Alliance as PDF publishing engine" issue
  

Tags:

• identity liberty

2d is just sooo last year

My friend Patrick Harding from Ping ID has blogged a nice graphic in which he plots various identity protocols onto a 2D grid.

I question the boundaries and positioning of many of Patrick's ellipses:

• SAML's ability to cover the user-centric use cases is minimized.
• Cardspace's relevance to the enterprise is marginalized.
• Managed Cardspace is shown as enabling more valuable transactions than SAML.
• Liberty WSF isn't shown.
• The extreme of the 'user-centricity' axis is typified by 'self-asserted identity (suggesting to me that 3rd party asserted identity is somehow incompatible with "pure" user-centrism)
  

Regardless of the details (Patrick and I have disagreed before) I think such diagrams are valuable in providing a framework for discussion. So, I was prompted to update my own similar analysis and plot another "identity system" onto the 3 (yes Patrick, 3, count 'em) axes I proposed.

Consequently, below is a plot for the SAML 2.0 Enhanced Client Profile (ECP), distinguished by:

1. how identity flows 'through' the user agent and thereby enables direct control by the user
   
2. the possibility of an asymmetric relationship between the SP and the IDP (as the client can mediate)

By any definition I've seen, SAML ECP is user-centric and so, at minimum, the SAML ellipse in Patrick's diagram should be streched to the right (and a separate, much smaller, ellipse created for WS-Fed, maybe used a dotted line).

Blog names I'd like to see

SurelyYouAreJoking

ThatsFineInTheory

HavingSaidThat

IAgreeBut

An apt description of our relationship

Conor giving me a hard time (in his own words).

I have to stop blogging about him. He's like a sore tooth that you can't help probing.

With my choice of words for that last sentence, and knowing how his minds works, I do realize I have guaranteed myself a follow up.

Nonage

I've been really happy with my Vonage VoIP service. So, I was willing to fill out a survey to which they sent me a link (the promised $5 discount helped) even it was presented by a 3rd party named Intellicontact.

I was giving Vonage high points with my answers ... until I saw the last two requests for info.

On some machine at Intellicontact, a process lies dormant, patiently waiting for survey data to be submitted.

I won't give away the ending

There is a line in Lucky Number Slevin (an excellent movie by the way) in which the Rabbi says:

Names, even made up ones, can bring about quite a bit of trouble.

This reads like a line from a Liberty best practices document.

Definition of Serendipity

Notwithstanding the excellent food & drink, getting together with Liberty friends, nice progress on our specification development, and interesting demonstrations and feedback from a number of Liberty implementations, this on its own would have made my trip to Paris all worthwhile.

New French Smoking Laws

Compared to my last visit to Paris 4 years ago, it seems that France has relaxed its smoking laws.

What had been a MUST (as in 'everybody MUST smoke') appears to have been loosened to a SHOULD.

That's not a knife

And neither is this much of an Eiffel Tower picture.

Now this is a picture of the Eiffel Tower.

Conor's picture is derivative and bland, mine is innovative and daring. Much like how we go about our Liberty specification work. I expect that Conor will somehow now make mods to my picture, claiming 'Editor Prerogative'.

I am at liberty to comment

Or, more precisely, I will be at liberty to comment (and deride) in 3 days.

The Liberty Alliance Technology Expert Group is meeting at France Telecom facilities in Paris.

Sync-ups with Egalite and Fraternite are planned.

My Frequent Flyer Sensei

Conor complains about a United miles promotion.

It's a tough call but I'd venture that Conor might have even more expertise and insight on the subject of business travel than he does on identity (although he does get 'awards' in both domains).

Amazingly, he is also equally opinionated in both. Do normal people care whether they sit on the left or right-hand side of the plane? Conor appears to (and I bet he has statistics to justify his preference).

They must want me to call them

I'm trying to reset a password on a site I don't use much and I see the following



The Q&A would have been previously supplied by myself sometime ago.

Unfortunately, for each Q, there are a couple of possible A's that I might have provided. For instance, I was born in Moscow but maybe I entered 'Russia' or 'USSR'. Who knows. The same for the questions about names, did I enter full names or shorter versions?

So, since each Q has at least two variant A's, and they give no hints as to which A is wrong, the odds are 1 in 8 that I, the valid account holder, will be able to reset without calling them for help (or spending the time trying the permutations).

The help desk staff must have a strong union protecting themselves from redundancy layoffs.

No visible signs of support

The virus scanning from my email provider has been flaky lately. When I asked for support, the message below was their response:

This is either the worst support response ever or a diabolically clever interactive phish.

The user has 2 pages of instructions thrown at them, the only one that they can easily perform is the 'provide user name and password' step. It's even first in the list to make sure Vern from Mattawa sees it. "Well jee wiz, why don't I do #1 and see how that helps".

Dear Paul Madsen,

Thank-you for your email. We strive to provide you with the highest level of customer support, and hope we can be of assistance in addressing your questions.

We understand your concern.

Please confirm the following so we can determine the source of the
problem:

1. Username and Password being used to download the software
2. Exact error message received and at what step in the process
3. Steps taken that led to this error and the step where the error is
occurring
4. Operating System and the version of the browser being used
5. Do you have any firewall software installed?
6. Any other anti-virus software installed prior to installing YOP and
has it been removed?
7. Please ensure that your proxies are disabled and that Active X is
enabled
8. Any changes were made on computer prior to the occurrence of the
issue (for example: Windows updates or software install/removal)
9. All information from WINIPCFG or IPCONFIG (PC IP,DNS Server IP's,
DHCP Server IP, Hostname, Nic mac address, Lease times)

========================================

For details on Active X, please refer to the URL shown below. Also, you
may refer to Microsoft at (905) 568-4494.

http://support.microsoft.com/default.aspx?scid=kb;en-us;154544


To turn proxies off using I.E.:

1) Click on TOOLS - INTERNET OPTIONS.

2) Click on the CONNECTION tab near the top of the window.

3) Click the LAN SETTINGS button.

4) Click the ADVANCED button.

5) Make sure that all of the address fields are clear and click on OK

6) A dialog box will appear asking if you do not want to use a proxy
server. This is normal - click on YES.

7) Click OK.

Your connection to the proxy server should now be disabled.

========================================

To view your IP configuration settings, run the 'winipcfg' utility
provided by Windows 95/98/ME. To do this, follow the steps below:

1. Click on START then RUN...
2. In the RUN... dialogue box, enter the following command:

'winipcfg' (without the quotations)

3. This will display an IP Configuration window. At the top of this
window, there is a drop down box that allows you to specify a hardware
device. Make sure you select your Ethernet Adapter (and not your PPP
adapter for instance).

4. Once you have selected your network card (your ethernet adapter),
your IP information will be displayed in the boxes below. Click the MORE
INFO button to view all the configuration information.

5. Once you have released and renewed your IP configuration, click OK to
close the IP Configuration window.

----------------------------------------

If you are running Win2000 or Win XP, you must first goto the command
prompt by following the options below:

1. Click START - RUN , and then type 'CMD' and press Enter.

2. At the command prompt, type "IPCONFIG /ALL" (to view IP address).
3. At the command prompt, type "IPCONFIG /RELEASE" (to release IP).
4. At the command prompt, type "IPCONFIG /RENEW" (to renew IP).
5. At the command prompt type "EXIT" (to exit back to the desktop).

========================================

In addition, please ensure that you have the following minimum system
requirements:

Windows 98SE, Windows 2000, or Windows XP
Internet Explorer 6.0 (or later) with ActiveX enabled or Rogers Yahoo!
Browser 3.0 (or later) with ActiveX enabled
350MB free hard disk space
RAM: 196MB for Windows 98SE and Windows 2000; 256MB for Windows XP
Network Access via Rogers Yahoo! for Broadband

To install further requires:

Administrator rights on intended computer
All other antivirus software must first be removed

If you have any further questions or comments regarding our service,
please fill out the online form on our Customer Support page listed
below or contact us by phone at ...

Regards,
Electronic Support Group

Would it even things up

if I blogged only with my left hand?

I'm trying to think of ways by which I can give Conor a fair chance at approaching my blog readership lead (thanks for the link Mom!). His latest response convinces me that something is necessary.

So far, I've come up with the following possibilities

1. switch the blog focus to fly fishing
2. start a charity for the 'interesting challenged'
3. pay neighborhood kids to create blogs that link to him
4. vow to not use vowels in my posts

But, come to think of it, I think I'll just continue to pad my lead. It'll be all over when Kim eventually reaches down and creates a 'pity-link' in his blog roll to the guy.

In the spirit of pointless bit flow

My travelling colleagues and I are proud to announce TrayTable.

Take a look, you might recognize some of them.

Whether or not you do, you'll definitely recognize the cramped feeling (notwithstanding Conor's ridiculously frequent upgrades).

Jamie Murray (1973 - 2006)

I lost my brother-in-law and friend last week. As they say in the Ottawa Valley, he 'took a heart attack'. At 33 years of age. The world seems a whole lot more perverse than before.


I like to argue, learn new things, drink beer, and build things. Jamie was a willing and able partner in all these. He was also the best damn Uncle to my kids that could be spec'd out.



The doctors tell us it could have happened while he was pumping gas or filling out a Web form - neither a fitting end to a life of activity and love. Jamie died in his treasured boat after wake boarding on the river he loved, surrounded by the nieces and nephews that adored him, and close to his wife and family.

I will continue to argue, learn, drink beer and build sheds at the cottage. It just won't be as fun.

My lead feels safe

In his first salvo of the 'Great Blog Readership War', Conor fires off

a) a stirring account of how he fixed his kitchen drawer.
b) a hard & driving story describing his purchase and plans for some computer equipment.

I expect we'll next hear about some problem with his farm tractor that he was able to repair with a USB cable and a patch made from chewed-up Cheerios paste.

Blatant attempt at targetted marketing for those searching on 'hardware'. He can have them - my readers pay their "people" to fix & install things. Much like the distinction between 'Jeopardy' and 'Who Wants to be a Millionaire' demographics.

I think I can safely take the week off from any further posts. Or the month. Maybe just start up again in January. I do need to ensure that I'm active before the Internet makes it to Ireland - Conor's numbers will jump when his relatives get online.

Note: I choose to believe that it was coincidence that Conor chose his blog address to begin with 'C O N' - the same three letters as does mine. Not intentional typo squatting I'm sure. I might have to revisit this opinion if Conor's metrics (number of linking blogs and Technorati rank) pass mine.