Cache Economy

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

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

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

Tags: Cardspace, caching

Waldo deserves privacy too

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

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

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

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

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

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

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

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

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

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

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

The Power of Language

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

using the power of language to move around your system

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

Why not applied to identity operations?

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

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

For those who want identity operations to be as difficult as possible, before proceeding with the requested transaction, the system could require that the user

• answer a math question
• compose a haiku
• define user-centric identity
  

This way we keep out the riff-raff.

Tags: Humanized Enso

Liberty & Silos to Wed

In an objectively titled post 'Liberty Loves Silos', Ben writes

Liberty thinks you need discovery because they think it is both inevitable and correct that all your data should live in silos, beyond your control, and ideally where you can’t see it.

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

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

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

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

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

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

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

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

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

Update 2: Pat uses assonance to good effect.

Provider Metadata

Mark Wahl looks at

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

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

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

Tags: ID-WSF, metadata

Putting meat on meta

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

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

So far, I see categories of

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

Tags: Liberty Alliance, metasystem

A friend indeed

A friend of mine, knowing what I do (and almost certainly trolling to get this blog post) sent me the following message

I have recently developed an interest in remote control planes. I joined an electric RC flying club and was invited to their Yahoo chat group. I had to register as a new user. I thought the idea of a ‘seal’ as an anti-phishing mechanism was quite clever. I had never heard of that before. Allowing the user to personalize their seal with a picture of their choice is also a good idea as it gives the user the feeling that they have some control in the whole matter. Overall, a very good experience.

With typical insight, I replied

yeah, but see
http://connectid.blogspot.com/2007/02/absence-of-evidence.html

His hurried response

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

My closing argument

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

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

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

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

OpenOpenID

A central tenet of user-centrism is typically expressed along the lines of

users choose their identifiers, it's not handed to them by Da Man.

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

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

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

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

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

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

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

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

Tags: OpenID, SAML, Sun Micro

IDDY

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

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

• Google Search Appliance
• Google Apps - SAML-based Single Sign-On
  (see video)

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

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

XML Summer School 2007

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

The 'Web Services & Identity' track has the following faculty members

• Eve Maler (Chair)
• John Chelsom
• John Kemp
• Paul Madsen
• Jeff Barr
• Marc Hadley
• Paul Downey
• Rich Salz

I'll be adapting my deck from last year to reflect the identity industry's progress over the last year, i.e. incorporating the latest buzzwords, acronyms, and FUD.

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

History T'ID'bits

Overheard in the Privy Council in January 1587.

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

No man (or provider) is an island

I'll go out on a limb here and say

Interoperability between A and B is simplest when there exists only a single mechanism by which the two can achieve X.

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

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

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

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

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

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

Most complex is a situation in which the choice of a SSO protocol is not pre-determined by either provider identity or particular application context, but dynamically established by the two providers at run-time. This would imply that the two parters had means to

1. determine the SSO protocol capabilities of the other
2. indicate their own SSO protocol preferences
3. negotiate/select within the available mechanisms
4. fault out in case of failure
   

The above list describes the type of functionality SASL provides for authentication, and that ID-WSF provides for security of SOAP messages.

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

Tags: SSO, SAML, OpenID, Concordia

The signs are clear

The apocalypse draws nigh.

Identity for Dapper

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

I became especially interested when I came across the line

The problem that these applications will face is identity.

Their interpretation of identity is a little different than mine.

How can you know that two movies - one at IMDB.com and another one at Netflix - are actually the same movie?

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

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

Dear Sun Microsystems

Hubert Le Van Gong
Sun Micro

Dear Mr Le Van Gong.

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

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

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

In order of preference, here are my desired URIs.

- MyOtherUriIsASamlAssertion.sun.com
- ScottMcNealy.sun.com
- YouCanTrustMeCuzImFrom.sun.com

Yours Federatedly

Paul Madsen

Tags: OpenID, Sun Micro

A James by any other name

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

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

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

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

Well that's it then

James McGovern predicts:

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

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

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

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

Hopefully Fozzie Bear can make it

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

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

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

More IDM for Indoor Rowing

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

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

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

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

Identity as Relationship Precursor

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

Towards the end, in a discussion of the value of VRM for the vendors, somebody (I'm pretty sure it was Chris Carfi) said something like

They (the vendors) will never see a better qualified sales lead

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

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

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

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

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

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

If identity sharing comes first, as the precursor to (possible interaction), the question is how:

• a service provide can retrieve identity of a users when not initiated by some interaction of that user
• once identity is retrieved, how can the service provider initiate the interaction (if appropriate)
  

For the first requirement, there would appear to be 2 alternatives

• broadcast - the user makes their identity publicly available for service providers to find
• filtered query - the service provider sends a query for desired identity to designated identity providers, specifying their request abstractly in terms of the identity they seek rather than in teh context of specific users (e.g. 'who do you have that's looking for a Sony PSP?')
  

The second requirement presents privacy challenges. How do you make contact information available (so as to enable interaction) without throwing privacy out the window?

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

Tags: VRM, Liberty Alliance, ID-WSF, identity

Let's all agree to not enable this

When self-asserted ain't enough

Robin questions his performance.

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

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

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

I guess the old saw is true

It's not the size of your assertion, it's what you do with it.

Drake's Equation

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

I propose the following modification

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

where:

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

and

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

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

Tags: cosmology, Drake's equation, passwords

More on OpenID bootstrap

In posting this, I forgot a couple of things:

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

Tags: OpenID, bootstrap

I'm literally drooling

Alerted by this, I installed the following two Thunderbird extensions

• Lightning - a local calendar integrated into Thunderbird
• Provider - an extension to sync Lightning with external calendars

Once both were installed, I added new calendars to Lightning, each of which pointing at one of my Google calendars.

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

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

I need a moment.

Tags: Google calendar, Thunderbird

Consenting Adults

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

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

Jeff writes

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

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

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

Tags: Liberty Alliance, consenting adults

Liberty Alliance Technology List

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

The archive of past messages is not being opened, the decision was made that we could not justify the expense and effort of scouring out the many occurrences of:

• references to questionable parentage of other contributors
• variations on 'WTF was BMEG thinking?'
  
• plans for global domination of the IDM market
• tongue-in-cheek proposals for as yet unseen WS-* specs (e.g. WS-NeedsHeavyProfilingForAnyChanceOfInteroperability)
• 'You're talking about the %$#*^&@! Attribute Broker!'
  
• the phrase 'A) - you're wrong, B) - ....'

The first topic under discussion is the definition of 'privacy event types' to be used within the Reporting Service (spec currently not released). The use case is a centralized Citizen Dashboard to which particular events (e.g. the release of attributes, federation establishment, SSO, etc) could be sent by the various government agencies that a citizen might interact with - and so provide the citizen easy 'privacy transparency' into such dealings.

Wonderfully panoptical. And yet powerfully user-centric.

Message in a bottle

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

OpenID bootstrap to ID-WSF

In last week's Brussel's IOS session called 'Metasystem - Slice & Dice', the group identified that a meaningful piece of work towards a 'Concordic' (love the word, I'm even using it to scold when my kids fight) metasystem would be to define the 'OpenID bootstrap to Liberty Alliance ID-WSF' (the scenario diagrammed here).

So what would this entail?

OpenID is (primarily) a front-channel SSO system, ID-WSF is (primarily) a back-channel attribute sharing system. The work being proposed would define how you segue from the former to the latter, e.g. how an OpenID RP, once an authenticated OpenID user has arrived, can transition into the ID-WSF world in order to discover and obtain other identity attributes of the user (this seen as an alternative mechanism to having the attributes delivered inline through the OpenID protocols).

To play in the ID-WSF world, the RP needs two things:

- the SOAP endpoint at which the relevant user's Discovery Service is located. The Discovery Service is like a personalized search engine for identity attributes. It's the Discovery Service that will be able to tell the RP where the user's various identity attributes (e.g. profile, calendar, presence, geolocation, wallet, social, VRM, etc) are located.
- a security token that, if presented to the Discovery Service, will serve to identify both the user in question and the RP asking the question (so that permissions can be applied).

In Liberty's architecture, the container for the above pieces of information (there are other bits as well) is an <EndPointReference>, an XML data structure defined by the W3C's WS-Addressing spec.

If an OpenID RP can obtain the EPR for the user's Discovery Service, then it has the necessary information and credentials to start participating in the ID-WSF world because, with the DS EPR, it can search for and retrieve the EPRs of other identity services (like calendar, etc) that it is ultimately interested in.

So, the challenge for connecting OpenID and ID-WSF is 'simple', define how the OpenID RP can obtain the DS EPR and, so armed, start discovering and invoking the identity services of interest. Liberty has always referred to this step as the bootstrap, and so the title of this post.

In our Brussels' IOS session, we discussed two broad options for making this work.

1. Having the OpenID protocol response carry (in an extension) a URI at which the DS EPR could be retrieved.
   
2. Having the DS EPR available as part of the user's Yadis document.
   

The first is aligned with how the existing bootstrap from SAML SSO works, the second perhaps more consistent with the existing OpenID model. More later on the pros/cons of each.

Tags: OpenID, Liberty Alliance, ID-WSF, metasystem, bootstrap

Marcus Brittanicus

BT's Mark Nijdam is blogging.

Refreshing to see a European with the same internal thermostat as my own.

Finnish participants notwithstanding, I'm very grateful that not all aspects of the typical sauna process were observed.

Strange

From a March 2007 German IDM conference, a paper from Microsoft entitled 'Microsoft's Identity and Access Management Strategy' that does not mention, even in passing, Cardspace.

Contents may have shifted in flight

On a flight from Brussels to Heathrow I noticed the following diagram in the back of BMI's in flight magazine.


It describes the permutations in the process for passengers connnecting at LHR - the options distinguished by where from & to the passengers are connecting.

I can see something similar for guiding deployers of interconnected identity systems.

• For users arriving through SAML SSO and not arriving with 'carry-on' attributes, for connection to ID-WSF, please proceed to the bootstrap. Otherwise, please join the queue for Attribute Processing.
• For users arriving through OpenID SSO and not arriving with 'carry-on' attributes, for connection to ID-WSF (either SOAP or AJAX bindings), please proceed to the bootstrap (either SAML & YADIS-based respectively). Otherwise, please join the queue for Attribute Processing.
• Should any user arrive through WS-Federation SSO, please contact an agent on arrival for specific instructions. Expeditious processing will be enabled by removing all jewelry, belts, shoes, and inhibitions about cavity searches.
  

Consent Context Markup Language

How tricky/tough/political would it be for proponents of various identity systems to agree on how to phrase a consent query, if not necessarily how/where/when to present such a query to users? As trivial as picking the text for

"X is asking for Y, wadda ya think?"

Beyond the simple yes/no, accept/deny, proceed/stop options (I've seen them all), there could be agreement on phrasing of the 'remember this decision' prompt and its options.

Alternatively (and far more work), how about a CCML 'Consent Context Markup Language' - a syntax describing how consent was obtained, comparable to SAML's Authentication Context and OpenID's Authentication Quality Extension for describing how authentication occurred.

Quick list of contexts.

• Who obtained consent? For what?
• How was the question phrased (as per above)?
  
• How was the question presented, e.g. by directly asking the user when they were 'at' the provider, or indirectly a la Liberty's Interaction Service , or by direct user-mediation of the flow a la Cardspace or SAML ECP? (hopefully avoiding the complexity of describing authentication because there would be no temptation to try and say that one consent mechanism was 'better' than another for ranking.)
  
• When was consent obtained, e.g. a priori, real-time?

Basic W5 stuff.

Of course, the question is who would care? It would be the provider making the access control decision for a particular bit of identity that would need to know about consent, so in what scenarios is it relevant for the details of said consent to be recorded? Audit would be one. Supporting a 'User Dashboard' where a user can see past identity transactions (and the specifics of the corresponding consent) would be another.

No identity system does this, so nobody should (you'd think) have resistance to collaborating.

Brussels Front-Back-Channel Users Group Meeting

For solid meeting results

Notwithstanding the name of the meeting room, we had a very useful IOS session this afternoon on the topic of 'Metasystem - slicing & dicing'.



From my viewpoint I saw only the normal amount of evasiveness.

Details of discussion to follow on the IOS wiki.

When convergence goes bad

The restaurant at which we had dinner last night in Brussels had an interesting 'washroom convergence model'. The Gals & Guys rooms' shared a single wash basin - this located in a hole in the wall between the two.

Art by Alex.

Was this a result of customer complaints about duplication & redundancy in sink infrastructure?

And the clear privacy compromise was deemed an acceptable trade-off?

Metasystem-schmetasystem

Premise: a single identity 'session' theoretically (a real instance would be unlikely to have them all) consists of the following stages:

1. Authentication
   
2. Single SignOn
   
3. User-agent mediated attribute exchange
4. Server-to-server attribute exchange
5. Single Log Out

Our various identity systems can be categorized as to whether they address the 5 stages. My best guess

Authentication

• Cardspace
• ID-WSF

Single Sign On

• OpenID
• SAML
• Cardspace (smart client)
  
• ID-WSF (smart client)
  
• WS-Federation

User-agent mediated attribute exchange

• SAML
• Cardspace
• OpenID (Attribute Exchange)

Server-to-server attribute exchange

• ID-WSF

Single Log Out

• SAML
• WS-Federation

Only 60 combinations to work out. Easy peasy.

Not being boastful

In yesterday's Liberty Alliance eGovernment workshop, a representative of an EU government made a distinction between 'claim' and 'assertion' - the impression he gave was that the semantics of the latter are stronger, e.g. anybody can make a claim, but you'll want to be sure about your facts before you make an assertion.

The 'Castle Team' mulled on this over iced tea at the day's end.

While the group agreed that there actually was no such distinction (claim and assertion used interchangeably) our discussion did hi-lite what seems to be a gap in today's taxonomy - this being the distinction between 3rd party and self-asserted identity.

The feeling was that something so fundamental as the relationship of the actor making the assertion to the subject of the assertion warranted more than merely an adjective. Additionally, we felt that the nature of the assertion, (i.e. positive or negative) should be explicit.

We came up with the following taxonomy

• brag: an assertion made by X in which some attribute(s) of X is enhanced or exaggerated
  
• boast: an assertion made by Y in which some attribute(s) of X is enhanced or exaggerated
  
• pity: an assertion made by X in which some attribute(s) of X is accurately described
  
• slag: an assertion made by Y in which some attribute(s) of X is accurately described
  

Feedback is welcome. We will have a call to review any such comments. Who knows, we might even attempt to account for it.

Standardized naming

In listening to various governments describe their online initiatives at today's Liberty Alliance organized eGovernment workshop, I've extracted the following shared requirements and/or patterns.

1. Security.
2. Privacy.
3. Categorizing risk/confidence levels into 4 types.
   
4. No centralized database.
5. A citizen portal name starting with the language appropriate equivalent of 'my' (e.g. MonServicePublic in France and MyPage in Norway.)
6. A claim that their country's culture, geography, politics, & history present unique requirements for e-services.
   

Military Intelligence

My father has always said that 'military intelligence' is a contradiction in terms (and he should know because that was his business).

Nevertheless, I'm enjoying reading John Keegan's Intelligence in War which describes the history of how different sides have tried to learn what, when, and where the other guys are doing.

Keegan describes the 5 fundamental stages of the intelligence game

1. Acquisition - collecting or finding it, whether from public or secret sources.
   
2. Delivery - once collected, the intelligence data has to be sent to its potential user.
   
3. Acceptance - intelligence has to be believed - this likely only after the bona fides of the source are verified.
   
4. Interpretation - scraps of intelligence have to be pieced together into a consistent whole.
   
5. Implementation - ultimately, you have to act on the data for it to prove valuable.
   

Two thoughts

1. This must be easier with everybody, from grunt to general, blogging. Do a Technorati search on posts tagged with 'enemy strategy' and you're halfway home.
   
2. Identity and intelligence data share a very similar lifecycle.
   

Twittervision

Twittervision is a cool application built on an exceedingly silly premise.

Individual twits display on a Google map. Not only can you learn the most trivial details of what people are doing, but also where they are doing it!

As posts appear and disappear, the map repositions. Most fun is seeing the focus shift back and forth from one side of the globe to the other - from somebody in Singapore describing what they ate for breakfast to somebody in Hoboken describing what they ate for dinner.

I plan on getting up early tomorrow so I can see the 'breakfast horizon' pass over the globe - from miso soup in Japan, through the UK's black pudding, ending up with a West Coast fruit cup and Espresso. Now that's a global community.

Tags: Twitter, Twittervision

Just to be perverse

I created a TinyURL for my ProtectNetwork OpenID paulmadsen.protectnetwork.org.

I was fortunate enough to be given an abbreviated url from the very prestigious '323' series, namely http://tinyurl.com/323zms.

18 characters compared to the original's 29 characters - that will add up.

Temple 2.0 bubble

It's clear from this that they were just waiting to be acquired.

You have to have an exit strategy.

SAML 2.0 Enabling a Wiki

Andreas posts a PDF on how they used SAML 2.0 for SSO to the PHP-based DokuWiki.

Whoa, using something as 'heavy' as SAML for a wiki? Is this legal?

Tags: SAML, Dokuwiki

At least one

Kim Cameron writes (actually wrote, it's quite an old post)

I think the SAML protocol suffers from having a single-token design.

A snippet from SAML 2.0's protocol schema seems appropo

<element name="Response" type="samlp:ResponseType"/>
<complexType name="ResponseType">
    <complexContent>
        <extension base="samlp:StatusResponseType">
            <choice minOccurs="0" maxOccurs="unbounded">
                <element ref="saml:Assertion"/>
                <element ref="saml:EncryptedAssertion"/>
            </choice>
        </extension>
    </complexContent>
</complexType>

In the same vein, from the SAML 2.0 profiles.

the <Response> element MUST conform to the following:

    - It MUST contain at least one <Assertion>.

Kim's post discusses delegation, specifically (for him) better support for delegation in WS-Trust/WS-Fed than in SAML because of the ability to carry multiple tokens.

The above makes it clear that there is no such distinction in the browser SSO case - a SAML IDP can return as many assertions as necessary, each of which with a different subject identity.

What's more, in a SOAP service invocation scenario, WSS/STP don't constrain how many SAML Assertions would be included in the security header either.

So, go to town. You want an assertion for your Aunt Ida? Sure, toss it in.

Identity cataclysm

Well, not quite. But weird nonetheless.

I was registering for Burton Catalyst. Had to ask for a password reset, received the following.


Great, perfectly normal. I had to leave before my registration was complete, so I 'saved' it. Received this email.


Ok, not sure of the point but fair enough.

The above was immediately followed by:


They gave me a (another) new password solely because of my saved registration. Do they bill clients by the message?

Early Social Networks

Two identity standards die in bizarre circumstances

Des Moines - In a freakish coincidence, two top-ranked identity protocols have died as they travelled separately to the 'Me 2.0' identity conference.

SAML, widely regarded as the top contender for federated identity management in the masters age group, perished when the single-engine Piper Cherokee it was travelling in crashed into a densely-wooded hillside soon after take-off from Topeka Municipal Airport. Forensic data experts are currently attempting to process the 'artifact' sent out by the pilot just before losing contact in order to determine the cause of the crash.

In a bizarre twist, one of SAML's colleagues, scheduled to fly on the same flight, cancelled at the last moment - narrowly avoiding even greater tragedy. Liberty Alliance, citing concerns over the insurance, declined to travel. Unconfirmed reports say that Shibboleth was also scheduled to be on the flight but was denied boarding after attending a frat party the night before.

The youthful OpenID, well-known on the celebrity party circuit, was seen by many as SAML's main competition. At almost exactly the same time as SAML's accident, OpenID died when the Kombi Van in which it was a passenger veered off the highway and crashed into a sign for a home security vendor. Toxicology results are pending. Also in the van was Attribute Exchange, who suffered severe injuries and is in critical condition at Topeka General Hospital awaiting a token transplant. Police attempts to contact OpenID's partner XRI are being hampered by uncertainty as to just exactly what it is.

Remaining identity specification WS-Federation, when contacted at her Redmond estate for comment, read from the following prepared announcement:

"This is sad, sad, news. Very sad. I personally am sad, saddened even. Even though they had both the market & mind share that I desperately wanted, and were crushing me in deployment numbers, I thought of both SAML and OpenID as true friends. I am completely confident that my friends, now dead and no longer a threat to my success, want me to continue on as before. Consequently, my 'response' to this tragedy is to say there will be 'No change'. Thank You."

When asked about the rumour that WS-Federation was seen in the vicinity of the aircraft maintenance shed in the hours before the flight, Detective Cameron Shaft of the Topeka Police Department replied 'We are investigating a number of promising leads at the moment. WS-Federation and her 10 lawyers are cooperating completely. No further comment.'

Playoff Hockey

A handshake and a smile?

From Boing-Boing, an article on an FBI proposal for unnerving would-be bank robbers with kindness.

What's the best way to make a bank robber turn around and walk out the door empty-handed? Try a handshake and a smile.

I can see this model working against identity hackers and thiefs. Make your protocol so inviting that they turn away either out of courtesy or because they suspect a trap.

There are even existence proofs.

Identity Management for Indoor Rowing

I've had a Concept 2 indoor rower for over 15 years. It's been an on and off again part of my fitness program - an excellent full body workout but a hard sell compared to a nice run through the woods. Lately however, as my knees degrade, the low-impact nature of rowing has become more and more attractive.

As partial motivation to get back into it, I upgraded the rather basic speedometer that came with my rower to a new model with more bells and whistles for tracking workouts and progress.



One nice feature of the new monitor is the ability to connect to a PC through a USB cable so that rowing data (e.g. time, distance, pace, frequency of vomiting, etc) can be analyzed. Once on your PC, analysis can provide clear confirmation that your rowing technique and fitness level has plateaued as expected.

A software program called Row Pro takes advantage of this connectivity by providing real-time visuals of your workouts - as you row you see all your numbers as well as a nice animation of a boat on an scenic course. You can even race against a pre-programmed pace boat, a previous workout of your own, or somebody else through the Net.



Row Pro also allows you to upload your rowing workouts to an Concept 2 online logbook so that you can compare your results and distance to others. When I saw this option within Row Pro I expected that I'd be presented with the normal Web 2.0 style prompt of 'Please enter your email & password, we promise not to share with anybody'.

Instead all I had to enter was a 6-digit 'Ranking ID' that I had previously been given by Concept 2. No password necessary for the desktop software to enter rowing workouts to my online log.

I could really screw up a good rower if I were able to guess their Ranking ID as I'd be able to push my workouts into their log. Imagine the shock of some competitive 20-yr old female sculler to discover that she's actually a 43-yr old identity standards architect with poor technique and no stamina.

Clear need for standardized secure & privacy respecting identity web services and a 'rowing workout service interface'.

Tags: concept 2, indoor rowing, Row Pro, identity

Race Registration

I was registering my wife for a 10K run (lately, with my knees, I register 'em, she runs 'em)

After entering the requested profile data, I was presented with the following (numbers manipulated to create the illusion of a much younger wife)

The Birthday that you input of 1978/08/17 (y/m/d) would
indicate an age on race day May 26, 2007 of 29.

This does not match the age on race day May 26, 2007 that 
you input of '28'.

Please go back and change the one that is not correct.

Use Your browser's back button to return to the form page 

If you already know the answer, why ask the question?

Dear 216K

Canada provides the Canada Education Saving Grant (CESG) program to encourage parents to save for their children's education. For every contribution you make to a Registered Education Savings Plan (RESP), the government will match 20% (with a whole bunch of constraints and limitations).

In practice, the CESG mechanism is that the investment company at which you've created an RESP makes a purchase on your behalf for the appropriate amount (i.e. 20% of whatever you've contributed yourself). You can see this in the pic of a transaction confirmation I received below



I plan on inviting 'Representative 216K' to my child's university convocation. If they can't attend I'm sure they can send a proxy.

Tags: CESG, RESP, designation

Proposed Response

No change is required

History T'ID'bits

Overheard on the shores of Lake Tanganyika

"Dr Livingston I presume you are aware that it's been over 6 years since I invited you to join my LinkedIn network? Don't mean to sound stuffy old chap but you could have saved me this rather tiring trip if you had just given me the courtesy of a reply what?"

User-centric tax filing

Yesterday evening, I used an online service to do the family's Canadian personal income taxes.

The mechanism for electronic filing of the returns to the Canada Revenue Agency captures both the benefits and issues of the 'user-mediated' channel for identity flow through the user-agent.

The process is illustrated here:


You download the special .tax file to your desktop, and then in a separate browser session, upload it to the CRA site. Repeat for spouse.

How very empowering! I am in complete control of transfer of our tax/identity information from the tax provider to the CRA. In fact, without my explicit consent and actions, the info just will not flow.

For me personally, I would have much preferred for the tax service provider to interact directly with the CRA to submit the files 'on my behalf' - saving me

• the effort
• the security risk of having such sensitive information sitting on my laptop.

One of these things is not like the others,

One of these things just doesn't belong,
Can you tell which thing is not like the others
By the time I finish my song?




Did you guess which thing was not like the others?
Did you guess which thing just doesn't belong?
If you guessed this one is not like the others,
Then you're absolutely...right!

Would that I was this happy

about anything, much less my keyboard or mouse settings.

Plausible deniability

Webkinz is all the rage for my kids and their friends. It's inane and senseless but I try not to judge it as simply juvenile because, well, Twitter.

From the Webkinz site

Webkinz pets are lovable plush pets that each come with a unique Secret Code. With it, you enter Webkinz World where you care for your virtual pet, answer trivia, earn KinzCash, and play the best kids games on the net!

The 'lovable plush pets' are $2 stuffed animals that sell, when you can find them, for over $10.

The animals are quickly forgotten - it's the 'Secret Codes' that the kids want. Without the code that comes with the pet you can't enter the fun exciting virtual world. Consequently, kids place great value in the codes. Search on the Web and you'll see a whole marketplace for them.

That explains why, when my 7-yr old son was playing at a friend's house the other day, and they were logging into the Webkinz site, my boy left the room when his friend entered the code (as reported to me by the Dad). I asked my son about it before he went to school today. I asked him if he left the room because he wanted to, or because his friend has asked him to. His reply

I wanted to, I never want to know somebody's else code in case something goes wrong and they might think I did it.

Smart boy. I'm all verklempt from pride.

What was I about to say?

Short Attention Span System (SASS) does for radio what Cliff's Notes does for literature, condenses.

The value proposition is simple, radio listeners can't pay attention to the epic 4 minute pieces that some artists currently create.

Radio SASS. (Short Attention Span System) takes the playlist and musically condenses songs to their essence. Through time compression, you get the memorable heart of each song, with an average length of aproximately two minutes with NO self indulgent guitar solos, NO long intros, NO repetition of choruses again and again. Radio returns to the snappy song length of the 1960s.

I'd love to see the abbreviated model applied to airline fare rules - an example of which has me currently stumped as to whether I can upgrade or not

Fare rules and restrictions
Please review the rules and restrictions listed below.
When you purchase your ticket, you agree to these rules and restrictions.
Please note that the most restrictive set of rules below applies to your entire itinerary.
 1  Rules and restrictions
Air Canada
From: Ottawa, ON (YOW-All Airports)
To: Brussels, Belgium (BRU-All Airports)
Fare Basis Code: Q0MSLWBE

YOWBRU-AC 28MAR07      *RULE DISPLAY*     TARIFF 0101 RULE 9422
* ADD APPLICABLE TAX * FED INSP FEES *
   -FARE BASIS         CAD       NUC                PTC  FT  GI
Q0MSLWBE        R    940.00    820.76               ADT  EX  AT
Q0MSLWBE        R    960.00    838.23               ADT  EX  AT
Q0MSLWBE/CH25   R    705.00    615.57               CNN  EX  AT
Q0MSLWBE/IN25   R    705.00    615.57               INS  EX  AT
Q0MSLWBE/IN90   R     94.00     82.07               INF  EX  AT
BOOKING CODES        Q
FIRST TRAVEL    -12AUG06             LAST TRAVEL     -30APR07
LAST TICKETING  -30APR07
SEASONS     - ORIG BELGIUM   01JAN-12JUN
              DEPARTURE FIRST INTERNATIONAL SECTOR
              19AUG-15DEC
              DEPARTURE FIRST INTERNATIONAL SECTOR
              ORIG CANADA
              FURTHER RESTR APPLY SEE TEXT RULE
PENALTIES   - ORIG CANADA   CANCEL-200.00 CAD
              CHANGE-200.00 CAD
              ORIG AREA 2   CANCEL-100.00 EUR
              CHANGE-100.00 EUR
              FOR ALL CONDITIONS SEE TEXT RULE
DAY/TIME    - TO CANADA   FRI THRU SUN ALL DAY
              DEPARTURE EACH TRANSATLANTIC SECTOR
              FROM CANADA   THU THRU SAT ALL DAY
              DEPARTURE EACH TRANSATLANTIC SECTOR
ADV RES/TKT - TKTG WITHIN 72 HOURS AFTER RESERVATIONS
              WAITLISTING NOT PERMITTED ALL SEGMENTS
              MUST BE CONFIRMED
MIN STAY    - RETURN FIRST SUNDAY AFTER
              DEPARTURE FROM ORIGIN
MAX STAY    - 12 MONTHS AFTER DEPARTURE FROM ORIGIN
BLACKOUTS   - NO RESTRICTION
SURCHARGES  - 10.00 CAD   7.00 USD SECURITY
              ADDITIONAL RESTR APPLY SEE TEXT RULE
STOPOVERS   - ORIG CANADA
              PERMITTED-2 OUTBOUND 1 INBOUND 1 AT
              50.00 CAD EACH
              DEPARTURE FIRST INTERNATIONAL SECTOR
              ORIG BELGIUM
              FURTHER RESTR APPLY SEE TEXT RULE
TRANSFERS   - UNLIMITED PERMITTED
FLT APPLIC  - NO RESTRICTION
CHILD DISC  - CNN 2-11 YRS 25 PCT ACCOMPANIED
              INS UNDER 2 YRS 25 PCT WITH SEAT
              INF UNDER 2 YRS 90 PCT NO SEAT
OTHER DISC  - NONE
COMBINABLTY - SEE TEXT RULE
ELIGIBILITY - NO RESTRICTION
ACCOM PSGR  - NO RESTRICTION
TRVL RESTR  - NO RESTRICTION
SALES RESTR - SEE TEXT RULE
              EXTENSION OF TICKET VALIDITY PERMITTED UNDER
              GUIDELINES SET FORTH BY CARRIER.  CONTACT
              CARRIER FOR DETAILS.
NEGOTIATED  - NO RESTRICTION
TKT ENDORSE - ORIGINAL TKT - VALID AC TRANSATLATIC ONLY
              REISSUED TKT - NON-REF/NON-END
              MUST APPEAR IN ENDORSEMENT BOX
APPLICATION - SEE TEXT RULE

A new art form

Serialized twitter's (or is it twits?)

Tags: Twitter, inane

You have to feel for the guy

On the Identity Trail reports that 'someone has their identity stolen every 4 seconds'.

They don't provide a name so we can't know for sure what it is that makes this particular individual such an attractive target. Is it just a case of this someone being unusually trusting?

Science is Truly Amazing

Scientists Discover New password in Alaskan Ice

JUNEAU, AK - Alaskan computer scientists are today reporting tentative evidence that they have discovered a new password - extending the number of known unique passwords to 47.

Dr. Peter Lyndstrom and his team of computer scientists at Alaska Tech University have been looking for the so-called 'X password' for 3 years now, using millions of dollars of expensive computer equipment. 'It's been a really long slog', said Dr Lyndstrom 'Sometimes I've even questioned whether the thing actually existed.'

In the end, it wasn't through expensive computers that the new password was discovered. Instead it was good ol' fashioned luck. “We were at a team party and somebody came up with the idea of just sticking existing passwords together, specifically 'm y' onto the end of 'm o m'. And well, after that it just kinda all came together” said team member Gail Svenson. “The frozen daiquiris definitely helped” she added.

Dr Lyndstrom's team is not stopping here. They plan on moving onto variations of the 'first car' theme, historically a rich ground for new passwords but relatively untapped since the car makers trend towards silly names.

Product Placement

This time he's gone to far.



The untampered-with Advanced Client overview is available here.

Tags: Liberty Alliance, Advanced Client

Charity Begins Online

Also available here.

Putt's Law

Putt's Law was pointed out to me yesterday

Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

Madsen's Corollary to Putt's Law

Putt's Law applies even when the people of the first type are 'promoted' to become people of the second type.

Just one Number

GrandCentral does for phone numbers what i-names would do for online identity - with the same advantages and risks.

I remember the previous incarnation of the 'Grand Central' identifier - completely different business model. Good thing names can be bought and sold.

Liberty Alliance Advanced Client

The Liberty Alliance Advanced Client specs were actually released for public comment some time ago but the press machine (Hi Russ) has caught up.

Most notable pieces of functionality are IMHO

1. the over-the-air/wire provisioning of 'root' credentials and other identity into a client
2. supporting a model of credential presentation in which the IDP need not be involved at run-time (relevant for both privacy value and in support of offline modes)
   

In the spirit of 'tail-wagging-dog', lots of attention.

I'm thankful Conor wasn't able to slip in his blog URL in his supporting quotes (I guarantee you he would have been thinking about how to do it).

Tags: Liberty Alliance, Advanced Client

History T'ID'bits

Overheard in Philadelphia

Oh absolutely President Hancock, digital signatures are wonderful technology. But we were actually expecting the old-fashioned ink-and-pen style for the declaration. It's the press you see, they want something nice and visible for the papers.

A says B can do X to Y

Lately, a model whereby some Entity A assigns certain privileges to Entity B with respect to the resources of Entity A is getting lots of discussion.

There are flavours of the above, depending on where the above logic is defined, where it's enforced, and whether all actors are cognizant of what's going on.

If the logic is captured and enforced at the provider hosting the resource in question, then it's a local affair and effectively boils down to an authorization rule at that provider. (Liberty People service is an enabler of this scenario, allowing such local authorization policies to be defined in terms of non-local identities.) In this scenario, even were Entity B to appear at the SP as a result of an SSO from an IDP, that IDP need not be aware of the policy.

If however the resource in question is Entity A's IDP account, then there are potential non-local ramifications should Entity B attempt to use the privileges to access Entity A's resources at other SPs. As an example, if I've specified to my bank that my wife has full access to my account, and that bank account has been federated with other SP accounts (e.g. mutual funds), then 'full access' might mean my wife could access my mutual funds investment account through my bank account if and when she authenticated to the bank.

In this latter case, if the bank IDP creates an assertion for the mutual fund SP that claims my wife is me, that's an impersonation model.

If instead the assertion carries both my wife's identity (even if anonymous) as well as my own and expresses the privileges that have been granted by the latter to the former, then that's delegation.

And of course, depending on the technology, A can always give their credentials to B.

The following lays out these 4 models (the blue dot represents where the 'A says B can do X to Y' rule is enforced.)

I never forget a ...

Of Passfaces, Paul Toal writes

It is common knowledge that the brain can remember images better than anything else.

For myself, better than my ability to remember faces is my ability to remember ways in which I've been slighted - I never forget an insult.

Give me a login system that prompts me to choose particular past snubs from a broad list and I'll never call the Help Desk again. The only difficulty would be in choosing my 'challenge slights' - there are just too many choices, a representative sampling of which is

• Kindergarten - Eli made fun of my toque.
• Grade 8 - Keenan mocked my choice of favourite Kiss song.
• University - Weird Julie claimed I had no physics bona fides in questioning her 'faster than light theory'.
• Career - Conor (as a category).
  

History T'ID'bits

Overheard in the Sistine Chapel

Oh yes Maestro, I fully agree that His Holiness stipulated in your contract that you have full artistic control of the project. I am merely suggesting that the sweeping scope and magnificent colours of the work are signature enough, and your blog address in 5ft tall characters might actually be unnecessary? Additionally, I wonder if some of the cardinals might misinterpret the depiction of God reaching out with with His finger to create the URI?

Strange Loops

I wanted to try out Highrise - an online contacts manager.

In creating my account, I was given the choice of using an OpenID rather than provide a password. Great! I provided my ProtectNetwork.org OpenID.

After the account was created, I was asked to sign-in.

Saw the normal OpenID screens and redirects etc.

The login failed.

Current situation:

• I can't use the ProtectNetwork.org OpenID to access Highrise because of above error
  
• I can't use another OpenID because Highrise has a record only of the ProtectNetwork one and so refuses to accept another.
  
• I can't get in 'locally' because I set up no password at registration time
  

My huge network of contacts, aching for management, languishes.

History T'ID'bits

Overheard on Tower Green

Yes Mistress Boleyn I do understand that this is not the best time but I'm afraid I have no choice in the matter. It turns out that Lady Seymour is unable to sign-in to the royal account without the password you set. So, it would really make my job much much easier if you could find your way to just writing it down for me. Oh, true, your hands are indeed tied together ... perhaps you might just whisper it then? And, um, the sooner the better I think ...

History T'ID'bits

Overheard on the banks of the Delaware

Yes General, once again I do apologize. I know I promised that you would be able to use the bridge. Unfortunately however the ice has jammed up the card reader for the gate and we're on hold with customer support trying to get a technician out here to get it fixed. Are you absolutely sure there is no other way you can get across?

History T'ID'bits

Overheard under the walls of Troy

C'mon Odysseus, put down the hammer would you? I'm not saying that the horse isn't a really great idea. But maybe, before we spend 3 months building the thing, we could just have a few shots at guessing the password for the gate? I'm thinking 'H E L E N' would be worth a try? or 'H E E L' maybe?