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.
  1. Edu-Tech
  2. Bitpac
  3. GM
  4. HP
  5. Intel
  6. Sun
  7. Neustar
  8. Star Alliance
  9. AOL

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.

  1. 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.
  2. 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.
  3. 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
  1. Joe goes to SocialApp.com
  2. 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)
  3. Joe is SSOd into SocialApp.com as a result of authenticating too his IDP.
  4. SocialApp.com discovers the location of Joe's People Service, namely FriendlyFolks.com
  5. SocialApp.com, armed with necessary credentials, queries FriendlyFolks.com for the list of Joe's friends
  6. FriendlyFolks.com checks its and Joe's policies and determines that it is authorized to respond with the list
  7. SocialApp.com shows the list to Joe and says 'Who do you want to bring in?'.
  8. 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
  9. SocialApps.com sends another message to FriendlyFolks.com, this time asking for identifiers for Bob and Alice.
  10. 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
  11. Relavent IDPs either provide or create identifiers for Alice and Bob that will be unique to SocialApps.com
  12. 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
  1. Joe goes to SocialApp.com
  2. Joe provides SocialApp.com his global identifier.
  3. Joe is SSOd into SocialApp.com as a result of authenticating too his IDP.
  4. SocialApp.com discovers the location of Joe's People Service, namely FriendlyFolks.com
  5. SocialApp.com, armed with necessary credentials, queries FriendlyFolks.com for the list of Joe's friends.
  6. FriendlyFolks.com checks its and Joe's policies and determines that it is authorized to respond with the list
  7. SocialApp.com shows the list to Joe and says 'Who do you want to bring in?'.
  8. 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.
  9. SocialApps.com indexes Alice and Bob against their global identifier.
  10. 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.


Tags:

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:
  1. 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.
  2. 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.
  3. I like long walks on the beach (as long as there is some sort of cabana selling cerveza at the end)
  4. The opinions of my Japanese colleagues notwithstanding, I think I say 'Ohayo gozaimasu!' pretty damn perfectly.
  5. 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
  1. User visits OpenID RP
  2. OpenID RP prompts for OpenID
  3. User selects persona and provides corresponding URI
  4. OpenID RP directs User to OpenID IDP
  5. OpenID IDP invokes Cardspace for authentication
  6. Cardspace displays candidate cards
  7. User selects from list, maybe signs into card
  8. Cardspace authenticates User to OpenID IDP
  9. 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
  1. not used as input to an authorization decision (e.g. some role) or
  2. 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

,,,,,,,,,,,,,,,,,,,

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
  1. The client requests a service using an HTTP request.
  2. The service provider responds with a SAML authentication request. This is sent using a SOAP request, carried in the HTTP response.
  3. The client returns a SOAP response carrying a SAML authentication response. This is sent using a new HTTP request

Tags: , ,

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?

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.

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.




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?

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'.



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?

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?



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!

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?



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.




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.

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.

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.


Saturday, December 02, 2006

Self-asserted (but should it be?)

Conor's geeking out over his latest gadget.

Three comments:
  1. 4 GB? My daughter has more space on her Tickle Me Elmo! I can hum that many songs.
  2. 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.
  3. 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.

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.