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.

Thursday, November 30, 2006

I demand a(nother) recount

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





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

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

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

Viral (with no redeeming qualities)

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

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

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

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

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

Wednesday, November 29, 2006

A marriage of convergence

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

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

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

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

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

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

Just listened to Aldo interview Pat about Project Lightbulb

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

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

Unfortunate coincidence

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

Many of my posts should return 203.

AQE - SAML/OpenID Convergence Opportunity #1

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

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

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




Tuesday, November 28, 2006

Complete transparency isn't always appropriate

A perfect example.

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

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

Action Item # 23 Status - complete

I received this email from FutureMe.org yesterday.


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



Monday, November 27, 2006

2 out of 3 ain't bad

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

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

Now that's a protocol

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

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

Service Providers and Relying Parties

Are they always synonomous?

SAML uses SP, OpenID uses RP.

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

Friday, November 24, 2006

Rebalancing

SAML

We'll always have Paris

I believe the term is "You go girl"

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

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

Semi-Modal dialogs

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

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

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

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




What could be more user-centric?

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

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


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

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

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

Thursday, November 23, 2006

Mea culpa

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

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

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

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

On the Google results page for 'user-centric'


and on OpenID

and at Project Liberty


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

Recombinant paper folding

This guy cloned himself - in paper.

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

Wednesday, November 22, 2006

Fair dinkum

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

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

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

Many are called but few are chosen

These are the Pauls I know

Paul Squires

Paul Toal

Paul Trevithick

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

My life flashed before me

When I saw this rendering of Google Calendar

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

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

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

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



Tuesday, November 21, 2006

Knit one, perl two



Hey XMLGrrl, consider this a challenge.

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


What if you are ordering dinner online?

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


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

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

Shades of ACLU Pizza of course.

A video is worth a million statistics

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

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

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

Masters thesis anyone?

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

OpenID and i-names

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

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

Comment-nary

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

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

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

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

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