ConnectID

Thursday, February 08, 2007

Google uses SAML for partner SSO

My video production skills are growing by leaps and bounds.

Clearly the next step is for Google to adopt Liberty Alliance ID-WSF to allow such partners to access Google applications in a non-browser context.

ProtectNetwork.org - Public SAML and OpenID IDP

ProtectNetwork.org is a public IDP that's worth noting because it supports both SAML and OpenID as SSO protocols. Follows is my halting and awkward screencap video of the two protocols in operation.

The stumbling when I was selecting my IDP from the SAML RP (the Internet2 Wiki) illustrates one issue with this model versus that of OpenID. But, what wasn't shown was that the Wiki set a cookie capturing my choice of IDP so that, on subsequent visits, I'd get immediately directed to ProtectNetwork.org without having to manually select/indicate my IDP. Trade-offs all around.

Note to self: cookies are the bane of creating demos of SSO operations, they often hide exactly that which you want to make explicit.

A certain irony

There is a certain (some might go so far as to say 'rich') irony in a paper commissioned by the Liberty Alliance proposing a distinction between user-centric and federated identity that runs completely counter to prevailing Liberty opinion (or my interpretation of at least).

The "Digital Identity Management A Critical Link to Service Success: A Public Network Perspective" paper examines the challenges and opportunities for network operators

The study analyzes identity management and its crucial role in enabling personalized services. Identity management is viewed as a crucial element in a basket of technology enablers that will be instrumental in preventing network operators from experiencing a dreaded “bit pipe” fate.

In a discussion of user-centric identity, the authors write:

Proposed, but not agreed, definitions for the different architectures are:
User-Centric: user decides every time what identity attributes to reveal to the content provider
Domain-Centric: user approves identity attributes appropriate to specific domains
Federated: user approves transferring of identity attributes already given to other federation members

These are strange criteria. The first would suggest that the (many) Liberty use cases where the user is not actively mediating (either because the identity does not flow through the user agent or because they are not otherwise involved) identity flow are not 'user-centric' - this is absolutely not the accepted Liberty view (in fact it's the definition of user-centric that Liberty argues strongly against).

The 'already given' in the last definition implies that a federated model deals only with the flow of data once it has already been shared at least once, perhaps through 'user-centric' active mediation?

For me, federation is a set of tools (e.g. SAML, Cardspace, OpenID, etc) user-centric is a philosophy for applying those tools.

At least the definitions are qualified by 'not agreed'.

Wednesday, February 07, 2007

Speak now or forever hold ...

My marriage counselor says that a good marriage is one in which the partners complement each other - where one is weak, the other is strong and so forth (she also said something else about listening closely and being attentive but I can't recall the specifics).

The same is true of identity systems. If you integrate them together, the 'marriage' is much stronger if their respective strengths address weaknesses and limitations of the other.

Consider the following table. It attempts to lay out (very coarsely) the relative scope of 4 key identity systems, SAML, ID-WSF, Cardspace, and OpenID. Each system is characterized by whether or not they have something to say regarding 3 different interactions:

that between the user and the IDP (i.e. how the user authenticates to the IDP)
that between the SP and the IDP (i.e. how identity attributes are communicated/requested from one to the other)
that between the SP and some other AP (i.e. how the SP finds and invokes sources of identity information other than the IDP)

SAML and Liberty Alliance ID-WSF are in a marriage, and you can see why it's a strong one. The interactions that SAML covers (e.g. between IDP and SP) are those that ID-WSF doesn't and vice versa. The two are like those old couples who are able to successfully ignore each other and stay together forever (SAML's drinking is admittedly a problem but it is getting help).

Cardspace and OpenID got engaged yesterday and, based on the table above, it should be a beneficial arrangement for both. It was the first column that motivated getting hitched - namely that Cardspace authentication could serve to address OpenID's vulnerability to phishing. Maybe the third column might be relevant in the future as well, this would involve a Cardspace RP using OpenID Attribute Exchange to get attributes not availableo from the Cardspace IDP.

But, if I was an 'identity system therapist', it would be the second column that might give me concern and have me set aside some 2 hour sessions for serious counselling. Both Cardspace and OpenID define mechanisms by which the assertions an IDP makes with respect to a user can be communicated to the RP - essentially, they both 'do' SSO. So, when is it appropriate to use OpenID, and when to use Cardspace?

One way for the two newlyweds to reconcile this overlap would be 'Well honey, OpenID is the right choice for low value transactions, and Cardspace for more sensitive applications' (I think this is how Jessica and Nick lasted as long as they did).

Ignoring questions of who decides what is valuable etc, this model might work - until such time as OpenID sees a self-actualization episode on Oprah and decides that it needs to 'grow spiritually'.

In the mean time, SAML and ID-WSF have been known to 'swing' - if you catch my drift.

Informed & controlling RPs

Informed Control's Mark Wahl discusses the range of possibilities by which an RP might come to the conclusion that a particular IDP was 'worthwhile'.

In a closed community in which a relying party only trusts the validation of credentials to be performed by a single identity provider, typically run by that same organization, then this is a non-issue. Other environments, such as in a federal government medium security infrastructure, a relying party may have an enumerated set of identity providers that it recognizes. In other environments, it is not clear how a relying party should choose the identity providers that it trusts.

I explored a similar set of options in a previous post, options that would support the full range of RP selectivity from promiscuous to prim.

Mark makes the point that the RP will probably make its decision to trust an IDP (or not) just once in order to establish the relationship, with that decision subsequently manifested in the IDP being placed in a white (or black) list or some other more easily assessed mechanism (when you hire a new employee, you examine their resume and references at the interview, not every time they show up for work).

Ping Metasystem Paper

I wonder if the timing of this metaystem paper from Ping is coincidental to yesterday's Cardspace /OpenID announcement?

The second integration scenario described in the paper could have come direct from yesterday's PR (albeit with an interesting SAML twist)

signon.com has implemented phishing resistant authentication and supports Self-asserted Card Space authentication. Alice uses her CardSpace Identity Selector to authenticate to signon.com.
After successfully authenticating Alice, signon.com use the OpenID protocol to redirect Alice back to isp.com

Or is this related to Kim's last-paragraph teaser from yesterday.

Really great news coming on Ping Identity.

I have a few of these

I'm seeing a ranking system whereby account holders can rate the 'usefulness' (and it's not simply how often it gets used) of an account - giving those considering establishing one some input.

Maybe I can even define policy so that I don't even see 'Register Now!' prompts unless a certain threshold is met.

Tuesday, February 06, 2007

I rink therefore I am

At least that's how many Canadian (not those from Vancouver, maybe some Northern States, probably Finnish) fathers feel.

What better way to demonstrate your devotion to your kids and their nascent NHL career than by building a rink for those first halting steps (and subsequent falls)? Also, what better way to get out of the house to avoid that busy post-dinner homework period?

Come to think of it, what other sport allows a parent to actually build the 'playing field' for their kids athletic aspirations? You ever see a Dad in India leveling out a cricket pitch by the rhododendrons? Or one in the US putting down chalk lines for a baseball diamond amongst the tomatoes?

In years past I built a rink in our backyard. I spent many a peaceful hour pacing slowly across the ice in rubberized boots, pulling a hose behind me, watching the water spread across the ice and slowly congeal into a smooth 'flood'. There is a certain satisfaction derived from such slow, almost mindless, repetitive operations working towards a distant and uncertain goal (e.g. the standards development process).

Unfortunately, due to the suburban sprawl of recreational equipment in our yard, there is no longer sufficient room for a reasonably sized ice surface. To satisfy my urge for nocturnal outdoor watering, I've taken to peeing on the neighbour's garbage cans. When challenged, I just say "It's for the kids".

Cardspace inside (OpenID)

The identity world is a flutter due to the announcement of Cardspace-OpenID integration (Johannes described it as a marriage, I wonder if there was a pre-nup?)

If I'm reading correctly between the lines, the announcement puts some meat on the integration scenario that was described by Kim a few weeks back - namely how Cardspace authentication could mitigate the much discussed OpenID phish attack.

For this to work, OpenID providers need to support Cardspace self-asserted cards (thus the commitment from OpenID vendors to add Cardspace) so that the OPs can bridge between the two worlds. Ping already demonstrates this working (importantly, as Ashish points out, if Cardspace authentication is going to be of value to an OpenID RP, there will need be mechanisms in OpenID to differentiate such an authentication from a lesser form. AQE is one option).

Interestingly, this is pretty much the same scenario (Cardspace authentication embedded within a SSO sequence) as previously portrayed in Ping's demo showing Cardspace and SAML integration (as commented on by Kim). Strange, no keynote announcement for that integration, I guess it didn't sufficiently excite Bill?

Identity Cocktail Party - Chat #2

Monday, February 05, 2007

Only in horseshoes and big bombs

does 'close' count.

I searched for a song on Pandora. The system found it, but queued up another similar song instead of the one I asked for. The reason - their license does not allow them to immediately serve the particular songs that are searched.

Interesting model. When applied to identity, it might resemble

Requestor: Can I have Joe's shipping address?
Provider: As requested - here is Joe's email address.
Requestor: Sorry, you must have misheard, I asked for his shipping address.
Provider: My hearing is just fine, thank you very much.
Requestor: Didn't mean to offend, but you gave me his email address when I asked for his shipping address.
Provider: Indeed I did.
Requestor: Glad that's cleared up, could I get the shipping address then?
Provider: It's a perfectly good email address.
Requestor: I'm sure it is, but I don't need his email, I need his shipping address.
Provider: Seems a shame to not use it somehow.
Requestor: (sighing) OK, I'll take the email address. But I do need his shipping address.
Provider: Say hi to Joe from me when you use the email.
Requestor: I will most definitely mention you, but the shipping address ....
Provider: Oh, you need his shipping address?
Requestor: (pause) Yes, yes I do.
Provider: Are you going to ship something to him?
Requestor: Yes, but I don't see what ...
Provider: Did he get the flat screen? He's been wanting one for the longest time.
Requestor: I'm sorry but that's really none of your business.
Provider: Oh excuuuse me, what he bought is none of my business but his email address is yours?
Requestor: I didn't even want his email address!
Provider: Then why did you ask for it?
Requestor: Just forget it, I'll send him an email telling him to pick the parcel up from the store.
Provider: Hah, so you needed the email after all!

silence

Provider: Hello? Hello?

silence

Provider: Did you know he was a Sagitarius?

Friday, February 02, 2007

SAML =/= SOAP

While acknowledging the 'sensitivity/value' advantages it has over 'lighter' alternatives, Eric Norlin incorrectly describes SAML as SOAP-based.

its still important to realize that SOAP-based systems of identity (SAML and WS-Federation) are still much more adept at maneuvering through high-risk transactions that take place online

SAML does define a SOAP Binding as one mechanism for moving messages and assertions around. It also defines a number of other bindings that have nothing to do with SOAP.

I understand the mistake. SOAP is 'complex', SAML is 'complex', it just makes sense that they must be inextricably intertwined.

SordID Thought

If I could teach people just one thing about identity, I bet they would all be coming up to me at the front of the class saying "Hey, I want the money back that I paid you for the 'Detailed Overview of Identity Management' course".

Thursday, February 01, 2007

Atomic VRM

I have a pretty good idea of the business trips I will take this year. Current best estimate (will certainly change) is

March - London
April - Brussels
June - Dulles
July - Oxford
September - Wellington
October - Tokyo
December - Santa Clara

By default I will fly Air Canada or United (or other Star Alliance partners) to ensure that I get the miles for Aeroplan and the perks associated with my status. But, for any one trip I would definitely consider another airline if the price were right - I'm loyal only up to a point.

I would even consider switching loyalty programs if it was worth my while. It wouldn't be for a single trip, it could be for a year's worth of travel.

A rough estimate of the cost for the above trips is $9-10K. Is this a big enough number for other airlines to want to proactively court my business by quoting me a number for the complete set? Is it large enough for them to throw in some status perks?

VRM should account for such dependencies between individual items - either an airline bids on the package or not at all.

Pseudo-XML might look like


<vrm:rfp>
 <pol:all>

  <vrm:item>
   <air:flight return="1" maxConnect="1">
    <air:from id="yow">YOW</air:from>
    <air:to id="lhr">LHR</air:to>
    <air:itin>
      <air:day start="#yow" end="#lhr">07-07-07</air:day>
      <air:day start="#lhr" end="#yow">14-07-07</air:day>
    </air:itin>
   </air:flight>
  </vrm:item>

  <vrm:item>
   <air:flight return="1" maxConnect="2">
    <air:from id="yow2">YOW</air:from>
    <air:to id="wel">WEL</air:to>
    <air:itin>
      <air:day start="#yow2" end="#wel">10-09-07</air:day>
      <air:day start="#wel" end="#yow2">24-09-07</air:day>
    </air:itin>
   </air:flight>
  </vrm:item>

 </pol:all>
</vrm:rfp>

I'd love to see the equivalent microformat.

Wednesday, January 31, 2007

TSOOI(AOBOOS) - The Story of OpenID (and occasional bits of other stuff)

By rough count, of Aldo's last 9 podcast interviews, 6 have focussed on OpenID.

Nothing else going on I guess?

This post is dedicated to "Big Bro", who never stopped believing.

Saturday, December 23, 2006

Nothing fishy in Denmark

Hubert shows a table comparing SAML and WS-Federation, the analysis performed by the Danish government.

James McGovern feels that the analysis is flawed, somehow suggesting that the Danes are either stupid or biased (or maybe both).

Maybe, those Danish folk need to talk to us Americans and learn something

What a novel phenomenon, an American who feels that the world simply needs to pay closer attention.

To claim that the US is the only place that understands either identity or enterprise use cases and requirements is neither 'thoughtful' nor 'leadership'.

P.S. And yes, SAML success is indeed limited to outside the US.

Friday, December 22, 2006

Putting a place to the reader

Google analytics tells me that somebody in Kamakura, Japan reads (or at least did read once) this blog.

Notable only because I visited Kamakura the second last time I was in Japan.

Windiest beach I've ever seen.

Nice walk-in Buddha.

Identity Oracle

In a post from the summer, Bob Blakley argues that IDPs should play their cards close to the chest, never answering directly to identity requests, but instead obliquely.

Q: Where is the Joe's location?
A: He's within 300 m of your store. I'll say no more.

For Bob, doing so means that the IDP doesn't give away the bank the first time it answers an identity request from an SP, and thereby makes viable an IDP business model.

I question Bob's use of 'meta' to refer to this sort of reply. While the answer 'The user is over 18' is 'data about data' and technically deserves the descriptor, 'meta' is taken in the industry, both to refer to how providers advertise their capabilities and endpoints (e.g. SAML metadata and WS-MetadataExchange for instance), and by the more nebulous identity metasystem.
For dynamic data such as geolocation or presence, even were the IDP to share the actual data, the IDP remains relevant because, like the weather, wait long enough and things will change.
Bob acknowledges the privacy advantages of the model but for him they are secondary to the business value.
It was the privacy advantages (namely enabling the privacy principle of minimal disclosure) that drove the Liberty Alliance to ensure that we could support such a model. ID-Web Services Framework defines a test mechanism by which an SP can pose such questions to an IDP.
An example of how a test would be expressed within a request.
```
<TestItem objectType="profile">
<TestOp>//Age >= ’18’</TestOp>
</TestItem>
```
the test here uses XPath.

Thursday, December 21, 2006

A single social network?

A while back, Phil Gyford lamented on the burden of his repeatedly having to

tell computers who my friends are

Amen to that.

Phil is somewhat equivocal on what he is looking for

I really, really want a single service where I can say “these people are my friends” and then when I sign up to any new website I can sync it with my previously-defined social network.

This is exactly what the Liberty Alliance People Service is designed to provide. In the People Service model, registration at the new social application would go something like this

Joe goes to SocialApp.com
SocialApp.com and Joe's IDP establish an identifier by which they will refer to Joe (in a B2C scenario, this identifier will likely be unique to these two providers)
Joe is SSOd into SocialApp.com as a result of authenticating too his IDP.
SocialApp.com discovers the location of Joe's People Service, namely FriendlyFolks.com
SocialApp.com, armed with necessary credentials, queries FriendlyFolks.com for the list of Joe's friends
FriendlyFolks.com checks its and Joe's policies and determines that it is authorized to respond with the list
SocialApp.com shows the list to Joe and says 'Who do you want to bring in?'.
Joe selects Alice and Bob from his list - presumably based on the nature of the community that SocialApp.com supports, e.g. stamp collecting etc
SocialApps.com sends another message to FriendlyFolks.com, this time asking for identifiers for Bob and Alice.
FriendlyFolks.com, works with the IDPs of Alice and Bob (they are likely different) and asks them for an appropriate identifiers to present back to SocialApps.com
Relavent IDPs either provide or create identifiers for Alice and Bob that will be unique to SocialApps.com
From here on, SocialApps will either map Alice and Bob into an existing account, if one exists, or create a new one (obviously maintaining the connection with Joe)

The multiple steps in the above come from Liberty's assumption that it should be possible for no two providers to share the same identifier for a given user - and so the complexity of the People Service mapping identities between the various actors.

If all providers share the same identifier for a user (as in default OpenID, and as Liberty People Service can support) , either for Joe or his friends, it becomes relatively simple, something like this

Joe goes to SocialApp.com
Joe provides SocialApp.com his global identifier.
Joe is SSOd into SocialApp.com as a result of authenticating too his IDP.
SocialApp.com discovers the location of Joe's People Service, namely FriendlyFolks.com
SocialApp.com, armed with necessary credentials, queries FriendlyFolks.com for the list of Joe's friends.
FriendlyFolks.com checks its and Joe's policies and determines that it is authorized to respond with the list
SocialApp.com shows the list to Joe and says 'Who do you want to bring in?'.
Joe selects Alice and Bob from his list - presumably based on the nature of the community that SocialApp.com supports, e.g. stamp collecting etc.
SocialApps.com indexes Alice and Bob against their global identifier.
From here on, SocialApps will either map Alice and Bob into an existing account, if one exists, or create a new one (obviously maintaining the connection with Joe).

Persona-able

Dave Kearn's Christmas homily on personas got me thinking.

For which identity attributes are personas most relevant, i.e. for which characteristics (e.g. profile, calendar, wallet, social network, etc) would it be most useful for a User to be able to manage duplicate views into the data - each used in appropriate contexts.

My Google calendar is a perfect example. I have calendars for work, for conference calls, for travel, for my sons' hockey teams, and for my wife's work, etc. If asked to share my schedule, I'd choose whichever of the above calendars was right for the context of the request.

Being able to slice and dice in this way would clearly also be relevant for my social network (were I to maintain the full pie in a single place as I do for my calendar - which I don't because no SNS allows me to compartmentalize in the same way). My work persona would define one set of 'friends', my family persona another, and so on. I'd either group these different sets into persona URLs, or group or tag them under some shared API endpoint.

What would personas mean for a wallet? Simply the analogy of how we currently choose a credit card appropriate to the situation, e.g. a company or personal card.

How about for a personal profile? Would I provide the cottage address when I was in 'Summer' persona?

Presence and geolocation (and any other such dynamic identity attribute) seem least amenable to the persona model. I might define different policies over their sharing, or level of detail/accuracy depending on the context, but I wouldn't maintain multiple sets.

Kaliya on Liberty People Service

Kaliya Hamlen appears to be looking forward to the Liberty Alliance's "Liberty 2.0" day.

Of the People Service, Kaliya writes

as far as I can tell is the only good way to move social graphs around that respect privacy.

Thanks Kaliya, that was the goal so it's nice to hear. In my talk I will attempt to put the PS into context of other social mechanisms like FOAF and the microformat-based XFN, citing pros/cons of all.

Separately, googling "Liberty 2.0" results in

Liberty 2.0R provides some excellent value

Finally, some recognition.

A modest proposal

A colleague (who shall remain nameless), complained to another about the lack of a link from the second's blog to that of the first (while there was a link to mine). Childish and immature yes but it does point to an issue.

The second colleague's defense was tardiness in updating his blog roll (tactfully dodging the far more likely reason of preferring to be associated with erudite insight rather than gadgetry).

Blog roll management is a serious problem. Many rolls lie static and out of date, their owners unable to keep them current and fresh.

I propose the following: I will maintain and manage a shared roll here on this blog. My colleagues, instead of taking on the burden of social identity management themselves, can outsource this responsibility to me and merely link to my blog with a 'Click here for my Blog Roll'. If and when they wanted me to add a new entry to the list they need only shoot me a mail. After suitable vetting of riff-raff I would make the edit. Easy for all.

If I had any coding ability at all, I could even support an API.

easier XML Sig (or none at all)

Jeff points to a number of scripting packages for dealing with XML Signature, historically a hurdle for SAML adoption in that community.

Of course, you could ignore XML Sig entirely and still use SAML.

Hurdles are falling down faster than for a Canadian female sprinter.

Wednesday, December 20, 2006

Never would have guessed it

John is actually not from Louisiana, he's English. Wow.

And Pat is Scottish!

I wonder if their accents might have given it away - I should really pay more attention when they are talking.

Cinqo

Eve challenges, I respond:

I was born in the former USSR. My father was stationed in Moscow for the Canadian military (he was the short one). He tells great stories about our car being followed, our apartment being bugged, and of plain-clothed KGB agents sweating in the hot sun while watching our family swim in the Volga.
I'm just now learning to play hockey. Embarassing for a Canadian but a vagabond childhood (see #1 above) does not always lend itself to sports careers.
I like long walks on the beach (as long as there is some sort of cabana selling cerveza at the end)
The opinions of my Japanese colleagues notwithstanding, I think I say 'Ohayo gozaimasu!' pretty damn perfectly.
In Grade 5 I desparately wanted a nickname. I started referring to myself as 'Mudman'. This identifier has proven completely impervious to adoption as a global pseudonym amongst my friends.

Robin, Hubert, Peter, Andre, Carolina (oh wait I forgot, she doesn't blog), my apologies.

Ambi-identitrous

Seed magazine has an article describing research that claims to have identified a correlation between ambidexterity and bi-sexuality. The article doesn't say so but it seems clear that the explanation of the linkage is that there must be a gene for 'Ability to handle multiple choices'.

Anybody with DNA so characterized will do well in the new 'identity metasystem', this because they will presumably deal better (e.g. faster log-in, less mental stress, etc) with the multiple online authentication options (e.g. SAML, Cardspace, OpenID, etc) than another without the gene. Consequently, we should see this gene favoured in those populations that see multiple SSO options because having it will engender a small but nevertheless significant Darwinian advantage relative to not having it.

Expect to see numbers of cross-dressing, ambidexterous individuals grow accordingly.

The former

In response to Johannes (unless you count consistently arguing that Liberty Alliance ID-WSF provides necessary privacy and security functionality for any non-trivial Web 2.0 app as 're-positioning').

OpenID and Cardspace (and a smidgen of SAML)

Drummond follows up on a comment from Microsoft's Mike Jones on the potential of OpenID and Cardspace integration.

In response to your question “How can we help each other?”, the first step to me seems to be for the OpenID providers to allow people to sign into their OpenIDs with InfoCards, rather than username/password. Then OpenID users will automatically gain all the benefits of the CardSpace user experience ceremony.

If Chuck Mortimer's proof-of-concept is OpenID within Cardspace, then this scenario (i.e. using Cardspace to authenticate to an OpenID IDP, at the behest of an OpenID RP, such that the OpenID IDP is a Cardspace RP) is OpenID followed by Cardspace - a weaker form of integration (and one of course possible with any other SSO system like SAML, as hilited by Ping).

As I see it, the defining characteristic of both OpenID and Cardspace is how identity persona selection occurs. In the default (but not only) OpenID sequence, the user selects which persona to present to the RP by providing the appropriate URI at the RPs' prompt. In Cardspace, the RP indicates its requirements and Cardspace displays a list of candidate cards, from which the user then selects. Both are selection operations, but differing in where they occur.

So, would integrating Cardspace and OpenID in this manner imply the user having to select a persona twice, e.g. something like the below

User visits OpenID RP
OpenID RP prompts for OpenID
User selects persona and provides corresponding URI
OpenID RP directs User to OpenID IDP
OpenID IDP invokes Cardspace for authentication
Cardspace displays candidate cards
User selects from list, maybe signs into card
Cardspace authenticates User to OpenID IDP
OpenID IDP directs User back to OpenID RP with assertion

or would the OpenID IDP be able to express its requirements so uniquely (just authentication) that no card selection (Step 7 above) would be necessary? (I've never actually seen a demo of Cardspace used solely for authentication so have no experience with this part of the 'ceremony').

Tuesday, December 19, 2006

How can this be?

The OpenID extension for MediaWiki allows for differentiated trust. Configuration options include

$wgOpenIDConsumerAllow -- an array of regular expressions that match OpenIDs you want to allow to log in. For example, "@^(http://)?wikitravel.org/@" will allow OpenIDs from the Wikitravel domain.
$wgOpenIDConsumerDeny -- an array of regular expressions that match OpenIDs you want to deny access to. This is mostly useful for servers that are known to be bad. Example: #^(http://)?example.com/#".
$wgOpenIDServerForceAllowTrust -- an array of regular expressions that match trust roots that you want to skip trust checks for when the user logs in from those sites.

Isn't this breaking some unwritten OpenID Best Practice for IDP selection?

Can an OpenID RP be anything other than completely promiscuous? If not, what happens to 'internet scale'?

Can't get much lighter than this

phpMyID is a single user OpenID IDP.

Perfectly appropriate for any identity request for which a RP would accept whatever identity (transferred through an identity protocol or otherwise) the user provided, i.e. any data either

not used as input to an authorization decision (e.g. some role) or
not verified somewhere else (e.g. credit card)

A cry for convergence

There is serious duplication and divergence in the identity industry, and it must end.

David Recordon posts a picture of his white-sock clad feet stretched out.

According to a (self) recognized expert in the field

he's in business class (middle column (2-3-2)) of a 3 class of service airplane... perhaps a 777

Update: It's a 767, the overhead bins are the give away.

David, I beg of you, join TrayTable for such pics.

Let's stop the insanity and move forwards together.

No particular subject

Authentication,Canon,Dulles,Federation,gadget,IAD,identity,Identity Gang,Identity Theft,iiw2006b,Liberty,Liberty Alliance,openid,SAML,scam,Security,Spam,UAL,united,Web Services

Is this a script - #2

In a comment to a post from Conor, James McGovern writes:

Curious if Liberty has decided to keep in (sic) simple strictly in the short-term or have decided to avoid tackling any of the issues surrounding the business scenarios and deferred it to the indefinite future...

"Mildly obscene acronym starting with 'W' expressing complete bafflement"?

James should know that if any one thing distinguishes the Liberty Alliance, it's that we, far more than other identity architectures, have acknowledged the critical importance of the business (and policy) issues - and created corresponding guidance output. Indeed, we are often pigeonholed into enterprise relevance only as a result.

Monday, December 18, 2006

Raise a Leg

If a dog had a blog, would it urinate on it so other dogs would know who owned it?

And me without a prepared speech

You like me! You really like me!

Oh wow, I'd like to thank my agent, my incredible team, and above all, He who makes everything possible.

What tripe

Sunday, December 17, 2006

SAML Inside

Last weeks's Liberty Alliance meeting at Intel in Portland was an opportunity for many a snide muttering of 'Intel Inside' anytime there was a glitch in the technical infrastructure (the screen in particular).

Such references got me thinking about the key role SAML plays in the emerging identity infrastructure and key deployments.

Dare I suggest

I guess this would be more speculative

Saturday, December 16, 2006

Request/response trickery

From Don Park, a description of how Skype fools firewalls into allowing inbound messages by convincing the firewall that the request is actually a response to a previously sent request.

Feels sort of like SAML's PAOS (SOAP backwards) binding, in which

The client requests a service using an HTTP request.
The service provider responds with a SAML authentication request. This is sent using a SOAP request, carried in the HTTP response.
The client returns a SOAP response carrying a SAML authentication response. This is sent using a new HTTP request

A blank slate

I was helping my 7-year old son set up an account at a game site.

He chose an account name that he will remember, and then I asked him to choose a password. His reply?

" 'Madsen' - that's what I always use"

Some might think grounding him and having him write out 'I will not reuse passwords' a 100 times an over-reaction.

Thursday, December 14, 2006

Nice try eh

I began the checkout process for an Xmas gift for my son at an online toy store but did not complete - disgusted at the inflated price charged me solely on the basis of a Canadian address.

My hesitation did not go unnoticed.

The fact that retailers will offer discounts to hesitant closers has not gone unnoticed by myself.

Nevertheless, picked the gift up at Target with Conor and Taki.

Stepper-up authentication

Ashish posts on the new Firefox extension through which Cardspace can be invoked.

Not sure what to make of the graphic Ashish uses. The dual escalators leading to a fitness club might be interpreted as suggesting Cardspace is the lazy man's option, as opposed to the morally and physically superior low-tech 'password as stairs'.

Overused Meme 2.0

Within the span of 3 days from a single RSS feed, I saw 3 profiles of the '2.0 Descriptor' standard.

4 if you consider 'Top 20' a typo.

Wednesday, December 13, 2006

Push me Pull me

Shekhar takes me to task for what he perceives as a bias towards pull-based authorization (and against push-based models).

I am disappointed that Paul missed another approach mentioned in the document ( or may be I am missing something). Pat rightly identified the 2 typical models that can be implemented and Paul extended it by coming up with all the permutation and combinations using various components. But all the model discussed look to be various permutation of just one model i.e. Authorization Pull Model where the resource is resposible to connect to the Decision Point to get the result. I think a hybrid of the "Authorization Push Model" and Local policy evaluation is more appropriate for the federation model where along with the identity the authorization of subject itself will flow to the other domain.

Actually, in listing out the permutations, we explicitly called out that we were not making any assumptions about the actual mechanism by which authorization data was transferred

It’s important to note that the above diagrams are intended to show configurations of components, not information flows. For instance, for any configuration that involves the sharing of subject attributes, these may be included in the actual request to access a resource, or they may be requested by the AEF (or other component) from the subject after receipt of the access request,

Sunday, December 10, 2006

Be prepared

After NBC airs their new show, all identity bloggers should be prepared for a barrage of (inevitably disappointed) visitors.

I can see it now

Hey Darlene, is one of them contestants named 'SAML', no wait, they must mean Samuel. Is there a 'Samuel' on the show?

No? well how 'bout a 'Uri'? Jeez, why are they putting one of those damn Russkis on the TV?

You're so vain

Who will be the first to have XRI vanity plates for their car?

Is the '=' an approved character?

Saturday, December 09, 2006

A love story

Friday, December 08, 2006

And you need this info why?

I signed up for Sirius radio.

In the middle of the registration I was asked to indicate the primary place of installation. And then I was presented with this

How nice, save me the effort of remembering my model by allowing me to provide the VIN and have them do the work. It's only been 5 hours and I'm already impressed by their customer service.

If I bothered to read it I bet their privacy policy would have a clause on the order of

We may use your vehicle VIN at some point in the future, for reasons as yet undetermined but nevertheless still governed by your acceptance of this policy.

I also quite liked the 'Please be sure to click Next to proceed to the next screen'. Did usability studies show that people lost track at this point? 'Now what was I here for .....?'

Was this a script?

James McGovern posted the exact same comment to a post of mine, one of Conor's, and one of Pat's.

Does Federated Identity sometimes require Federated Authorization? If so, how come this isn't ever discussed. Maybe you could address in future blog entry...

As ever, Eve is special, she rated a slightly modified version.

Not sure about the mechanism, but my thoughts regardless.

If you look at the P*P (PDP, PIP, PEP, PAP) model that SAML popularized, in theory you can distribute them any which way across the boundary between two policy domains. Typical federation models allow for the PIP (or at least one of them) separate/distant from the PEP and PDPs guarding some resource - the PIP supplies information (typically in the form of user attributes) to the PDP that feeds into the authorization decision. Shibboleth is a good example of this model.

In principle, you could have the PDP also distant from the PEP (which necessarily has to be 'close' to the resources its protecting) but its a special kind of PEP that will listen to such a PDP. This is what I expect James is referring to when he says 'federated authorization'.

In a previous life, my Entrust colleague at the time Carlisle Adams and I looked at the different permutations - the work can be found in an appendix to a GGF paper called "Conceptual Grid Authorization Framework and Classification".

The permutations we identified are shown below (with terminology aligned to the Grid world - the paper explains).

health.google.com

From Johannes, hints of Google's plans for health identity.

The kicker:

Patients also need to be able to better coordinate and manage their own health information. We believe that patients should control and own their own health information, and should be able to do so easily. Today it is much too difficult to get access to one's health records, for example, because of the substantial administrative obstacles people have to go through and the many places they have to go to collect it all. Compare this to financial information, which is much more available from the various institutions that help manage your financial "health."

Currently, Google has no credibility here. They could buy some though.

Thursday, December 07, 2006

What the SP knows (and when it learns it)

It occurred to me that there are 2 distinct points at which the SP 'learns' something about the user in basic SSO - the first is whatever bit of information is provided to the SP to enable IDP discovery, and the second is whatever the IDP, once discovered, asserts to.

Our various identity systems differ in both steps, as shown below.

Time is the horizontal axis, the vertical is a representation of how 'much' the SP knows at any one time

Normal caveats about over simplification, not drawn to scale, etc.

I was hoping this would lead to some sort of "Madsen's Privacy Law of Minimal Area" - expressing the premise that, all else being equal, the area under the curve should be minimized for optimal privacy but can't quite reconcile that with Credentica's tech having greater area than others. Maybe I should just ignore it - I wouldn't be the first researcher to do so for data that didn't fit my theories.

Reverse Reverse Turing Test

Anybody who lasts longer better than 2 seconds the first time they try this can't be human.

Tags:

captcha

Turing Test

Mapping Cardspace to OpenID (and then back)

Chuck Mortimore posts a movie of a login sequence in which an OpenID identity is represented by an Infocard in his Firefox Cardspace. When the user selects that card (after the Cardspace RP requests login) his extension uses the OpenID protocol to retrieve the necessary claims from the OpenID IDP, and then dynamically maps them into the Cardspace format for delivery down to the Cardspace RP.

Very nice PoC. It seems anything is possible when clients can translate between protocols.

Despite the data within originally coming from a 3rd party IDP, I guess the card that gets created will necessarily be self-issued - this because the step of translating from OpenID to Cardspace format would destroy any means by which the Cardspace RP would (reliably) determine origin.

The UI initially gave me the impression that the user actually presented their OpenID IDP credentials to the Identity Selector (and that caused great confusion for a bit) but its just how the OpenID HTML login page is embedded within.

Tags:

Cardspace

OpenID

Wednesday, December 06, 2006

Where's the Porschaaaa?

If not for a certain video, this comment would be meaningless - context really is everything.

My boss is a
Canadian
from BC
specifically
Vancouver
where they'll hold the Olympics
in Gastown
who's male
42-years old
which means he's over 25
and under 65
who went to UBC
and is a CEO
and founder
and bartender
and belongs to the Vancouver Entrepreneur Forum
and is a blogger at blame.ca
who banks at HSBC
and flys Air Canada
and is a Star Alliance Gold member
who likes Macs

Is it true Dick drives a Pinto? and he's actually *A Prestige?

Tags:

Sxip

Dick Hardt video

Vancouver

Real world Authentication Context

Responding to a challenge by Dave Kearns, Symlabs responds on the topic of real-world application of SAML's Authentication Context.

Symlabs writes

At Symlabs, we see our customers using AuthnContext for information about how a user was provisioned in the first place, and also how the user was authenticated for the current session.

and

Symlabs was instrumental in getting the mobile authentication contexts defined, because our wireless operator customers requested our participation in this area.

Indeed, I remember well the after-hours session (Paris?) with Sampo thrashing out the mobile classes for ID-FF.

Separately, Sampo should blog, it would be ... 'interesting'.

Tags:

Symlabs

SAML

Authentication Context

Ponderings

Lots of very smart identity people subtlely diminish their blogging as 'My X on identity', where X is some noun denoting esoterica or inconsequentiality etc

A short list:

Roger Sullivan - musing and meanderings
Ben Laurie - blatherings
Robin Wilton - esoterica
Andre Durand - ramblings
Conor Cahill - musings
Ludovic Poitou - sketches
Julian Bond - a pointer to nothing

Me, I'm searching for a noun for 'semi-authoritative pontification'.

'Pompousity' comes close but doesn't quite capture the essential sense of deep insecurity.

Identity-based Greeting Cards

This might be the only non-spam you get today.
Sorry to hear about your ID theft.
Congrats on your new persona!
Don't think of it as getting phished, but rather a chance to start your life over with a clean slate.
You can scan this card in order to install me into Cardspace.

and bumper stickers

If it ain't user-centric, it's crap!
How's my driving? (you probably wish my URI was here for complaints right?)
If you can read this, you can read my blog.

Cardspace Localization for Japan?

Hopefully the vacuum-packing process kills the smell.

I wonder if the Cardspace ceremony will ever be able to replicate that of meishi?

Tags:

Cardspace

Japan

meishi

PATYADISXRISAMLSSOPHP

Pat has a very nice screenshot movie of the YADIS/XRI support he added to his SAML SSO PHP library.

Pat uses the OpenID favicon in the URL/XRI prompt.

I think this is perfectly appropriate as the ceremony he provides is exactly the same were the protocol OpenID and not SAML. Put another way, it's in the XRDS doc that the fact that the IDP speaks SAML and not OpenID is advertised, and not in the UI.

I do wonder though if an anarchist might resent having the "Big Business Driven" SAML (even ignoring the fundamental contribution of higher education) serve as the underlying protocol supporting their identity transactions?

Tags:

YADIS

SAML SSO

Thunderbolts and Lightning

Very very frightening me.

I'm not one to armchair compose, but I think Eve chickened out on the whole 'user-centric/tantric' rhyme possibility.

Before she sold out to "The Man", she would have gone there. It used to be about the music girl!

Tags:

Eve Maler

Tuesday, December 05, 2006

Here boy

I don't yet know everything that it is doing, but Sxipper is definitely cool and slick.

From what I see, I'd describe it as a client-side OpenID persona manager, simplifying for users the choice and use of different personnas at different sites. Sxipper also stores profile data, and form fills as appropriate. There are hints that it does some cool 'semantic maps' for forms, somehow my actions on a form (but not data?) are recorded and aggregated for good of commmunity?

Kind of similar to the Cardspace model. A request from an SP for an OpenID wakes up Sxipper, which then prompts user to choose an appropriate persona. Blurs the supposed distinction between card-based and URI-based identity.

I'm confused by the OpenID demo though.

How did Sxip determine that my wife calls me "joesixpack"? Is appending 'et' designed to inhibit correlation?

Tags:

Sxipper

OpenID

Unfortunately

my sons will not be "Skating with an NHL star".

The registration form is ridiculous. I particularly like the fact that the only non-mandatory piece of info is the kid's favourite menu item.

They'll have to get into professional hockey the same way I did - through countless hours of practice, complete commitment, and learning how to sew those nice skirts.

Tags:

hockey

identity form

An inconvenient truth

Conor takes exception to Johannes's 'Identity Triangle' diagram.

Conor's meta-objection seems to be that the diagram slots the three identity systems into a nice clean and seemingly intuitive model, but does so based on only on those criteria that ensure the fit - the reality of the blurry lines that distinguish the different systems are an inconvenient truth to be shuffled aside.

The 'user-centric' dotted line that excludes SAML is of course an old standby. I could just as easily draw a dotted line around SAML & Cardspace labelled 'privacy respecting' - a gross over-simplification but one with a kernel of truth when OpenID is used with global URIs.

Shouldn't it be What 2.0?

If anonymity is the appropriate default identity model, Who 2.0 implies an inappropriate level of precision.

Many service providers don't need (or eventually will want) to know 'who' you are, but rather 'what' you are.

Tags:

2.0 meme

Wet fish

Must spam be only a nuisance? Can it not also provide opportunity for childish amusement?

William Donaldson's "The Henry Root Letters" are a wonderful example of the comic potential of hoax communications.

In that vein, I recently received the following:

Lotto - Zo werkt Lotto Government Accredited Licensed lottery promoters. International Promotions/Prize Award Department.

This Lottery is approved by the Netherlands Gaming Board and also Licensed by the The International Association of Gaming Regulators (IAG international emails. held on the 29th November, 2006.all winnings must be claim not later than Decembre 7th, 2006, after this date,unclaimed funds will be returned to the Lotto.

Your email won the lottery.For a total pay out of €1,000,000. no tickets were sold but all email addresses were assigned to different ticket numbers for representation and privacy.

Please remember to quote your reference number and batch numbers:
1, Batch 9484-9116-0076
2, Ref: 637405467-Nll
3, lucky numbers 1-0958-31-444
To file for your claim, please contact
**************************
Advocate Faber Dutchs
Tel: +31 -619 255 080
Fax: +31-84-728-9656
email- bejesbejes200@aim.com

I replied with the following (from a suitably disposable address and after obfuscating above indices):

From the desk of Renry Hoot

Dear Sirs, thank you very much for the good news, I am ecstatic to hear about my good fortune. I have never won anybody before (Mrs. Hoot as the exception of course), much less 1 million Europeans!

Before we proceed I do have some questions on which I would appreciate clarification:

1) for those Europeans I have won, am I responsible for their travel costs from their respective homelands to mine? I do acknowledge that, even with this expense, I stand to benefit greatly from their subsequent labours, but I do need to budget accordingly.
2) To what standard of living are my prizes used? I do plan of course on providing them the base necessities but don't see the sense of spoiling them with luxuries beyond that to which they are accustomed. For instance, might a typical European find soap and similar toiletries an unexpected and unwelcome oddity? I'm sure you'll understand why I'd prefer to save this expense if possible.
3) Canada can be a cold country. Perhaps you could begin the conditioning process by occasional walk-in freezer sessions? If you could simultaneously broadcast French language programs to them that would be extremely helpful - it is that unique combination of shivering and strange vocalizations that typifies my country.
4) Related to above, any French language skills would be a welcome bonus (unless of course you are shipping me Frenchmen. If this is absolutely necessary please keep them to a minimum - Canada is already quite socialist enough Ha-Ha).

Thanks again. I'm very excited and happy to be the new owner of so many Europeans (although the task of choosing new names for them is daunting!)

Gratefully yours,

Renry Hoot

p.s. I wonder if your lottery might be affiliated with a similar one in Asia? Is there any precedent for trading some or all of my Europeans for Asians? I would be of course be willing to consider a considerable exchange rate, perhaps 5 to 1? Please advise if this is a possibility (and whether a donation to a 'charity' of your choice might expedite the process).

Let's see if they are even set up to deal with responses.

Tags:

hoax mail

spam revenge

Monday, December 04, 2006

Pillar of Salt

Doc's wife must already be well versed in SAML and the Liberty Alliance because he mentions neither a single time in his "Let's go bust some Silos", an expanded description of a conversation Doc had with his wife discussing current identity developments and the importance of 'default anonymity'.

Or is because neither contribute to identity silos and therefore don't deserve the title? That must be it because both have support for anonymity built into their fibers.

Tags:

SAML

Doc Searls

Liberty Alliance

anonymity

Saturday, December 02, 2006

Self-asserted (but should it be?)

Conor's geeking out over his latest gadget.

Three comments:

4 GB? My daughter has more space on her Tickle Me Elmo! I can hum that many songs.
Bryan Adams? I know that questionable music can sneak into a collection. My niece recently used my iTunes to purchase a Jessica Simpson song - it was immediately purged (but I did keep the Jo Jo song, she's, like, way cute). But Conor's willingness to advertise this Canadian's place in his library indicates that it's no accident.
The thought of Conor stretched out in Business Class tapping his toes to Sheryl Crow's 'Soak up the Sun' is disturbing.

Diffie-Hellman Example

Johannes recent comment hinted at alternatives to Diffie-Hellman in OpenID for situations where the shared-secret nature of DH would be a limitation - specifically mentioning the potential relevance of non-repudiation.

Brian Ellin has previously discussed Diffie-Hellman in the context of OpenID but, for me, real numbers make things real. So, a work through of how an OpenID RP and IDP would use Diffie-Hellman alorythm to generate a secret that could be used for securing OpenID protocol messages.


p    = 7 (a small prime number)
p- 1 = 6
g = 2 (OpenID default)

RP chooses x = 5 (smaller than p - 1)


X = g ^ x mod p
X = 2 ^ 5 mod 7
X = 32 mod 7 
X = 4 (the remainder when you divide 7 into 35)

IDP chooses y = 4 (smaller than p - 1)


Y = g ^ y mod p
Y = 2 ^ 4 mod 7
Y = 16 mod 7 
Y = 2 (the remainder when you divide 7 into 16)

RP and IDP exchange X and Y in the open (no need for secrecy)


RP calculates        IDP calculates

s = Y ^ X mod p      s' = X ^ Y mod p
s = 2 ^ 4 mod 7      s' = 4 ^ 2 mod 7
s = 16 mod 7         s' = 16 mod 7
s = 2                s' = 2

Both RP and IDP have calculated the same secret, namely the integer 2, based on information publicly shared between them. They can then use this secret to sign and/or encrypt subsequent communications. OpenID refers to the establishment of this secret as 'association'.

Any eavesdropper, armed only with the public info shared between RP and IDP, would be unable to calculate the secret (if the integers were chosen appropriately large) - this because only both RP and IDP have the necessary additional info (the choices they made but not shared). It's Diffie-Hellman's support for establishing secure communication without any existing trust relationship (excepting SSL) that makes it relevant to OpenID's promiscuous providers.

But, because RP and IDP use the same secret, it doesn't allow the provenance of any particular message to be established. Even if 'signed' with the secret, it could have come from either of the two.

It's worth mentioning that nothing precludes a SAML SP and IDP using the same technique, i.e. establishing a shared secret through Diffie-Hellman and then using it to protect SAML protocol messages.

Tags:

Diffie-Hellman

OpenID

association

Friday, December 01, 2006

In triplicate

Pat appends to Johannes's list.

Pat asks the question:

how do IdPs and SPs decide which flavour they prefer?

I don't know, but I bet they log their choice for future audits.

I confess I thought LID was subsumed.

Standard or proprietary?

An interesting read from Texas Tech

Do Markets Prefer Open or Proprietary Standards for XML Standardization? - An Event Study investigates the market value of standardization initiatives, based on a variety of XML schema standards.

Proprietary standardization seeks to increase a firm’s market share (pie sharing).

Open standardization seeks to increase the size of the market (pie expansion).

The conclusion?

The results show that financial markets respond positively to announcements of proprietary XML schema standardization, but not to those of open XML schema standardization.

How encouraging.

A poor description of OpenID

Ma.gnolia.com has added OpenID support.

Their single-line description of what OpenID provides is going to scare (or a least confuse) some.

Most user already sign-in to different sites with the same password. Is 'safely' sufficient distinction?

The 'Get an OpenID' link goes to MyOpenID, the URL parametrized by an affiliate ID. Playing around with different values for this gives an interesting sense of who is using OpenID. Such an open and accessible listing of SSO partners creates for me a uneasy feeling though.

Tags:

OpenID

MyOpenID.com

Thursday, November 30, 2006

I demand a(nother) recount

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

with this legend

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

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

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

Tags:

Liberty Alliance

Japan

Viral (with no redeeming qualities)

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

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

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

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

In the Liberty Alliance People Service model, the sequence could work something like:

Store sends me above email (unlike my friends, I've opted in to receive them)
Message contains a number of custom URLs that I can choose to send onto whomever I wish
When my friend receives the message, clicking on link takes them to etailer where they are given options of a) federating an IDP account of theirs with the etailer, and b) joining my People Service (so that future interactions between ourselves can be facilitated)

Key implications:

I don't give away the email addresses of my friends indiscriminately
Interesting social applications between them and I (like above) can be enabled without requiring them create an account at the etailer.
I rely on more traditional mechanisms to inconvenience Conor.

Tags: