Thursday, August 31, 2006
I really appreciated having to enter all the same information twice - sometimes I tend to forget my home address and like to be reminded through rote repetition.
Given that I've signed them up in years past, and will be signing them up going forward (untill they come to the realization that they've inherited my skating ability), I would have preferred an account to store the info (in the near term absence of better alternatives).
Leaving the hotel, my NTT colleague Hiroyoshi Takiguchi and I noticed what appeared to be a number of wall safes just outside the front door.
The safes are there for guests who arrive for check-in after the front desk closes at 11 pm. The mechanisms works as follows
1) Before leaving for the night, staff enters the first name of each expected guest into one of the displays
2) Guest, on arriving, enters their last name using the keypad of the appropriate (matching their first name) safe.
3) Safe lock opens, guest retrieves their room swipe key.
4) Guest uses key to enter building and then their room.
5) Hotel staff sleep throughout.
So what if two guests have the same first name ....?
Or if a guest has an easily guessed last name ..?
Or hotel staff mistypes the guest's last name ..? (comparable to somebody, in a fit of pique arrising from poor blog readership, spelling 'Madsooon')
Speaking of pique, Conor suggested that a better model would be for the guest to simply swipe the credit card used to make the booking - that would imply connectivity beyond the safe unit itself.
Nice example of token mapping. The guest exchanges one token (their last name) for another that can be used to access local resources (ie. enter the hotel and room).
Cast of Characters
- Security Screener at Washington Dulles Airport (SSWDA)
- Guy in Front of Me in Line Going Through Security (GFMLGTS)
SSWDA: (to GFML as he peers at his scanner screen) So, is this a laptop or a DVD player?
GFMLGTS: I'm in the military and it's classified.
SSWDA: Pardon me?
GFMLGTS: I can't tell you what it is in public.
Exit Paul. stage left, scurrying over to other line
Tuesday, August 29, 2006
* Ego is participant in the ego centric model.
* Claim is statement made by an ego taking credit for an idea. A Claim can be made NotBefore and/or NotOnOrAfter an idea becomes well known.
* Assertion is statement made by an ego either directly or indirectly suggesting the superiority of the subject.
* Subject is always the ego.
* Asserting Party is a gathering of two or more egos to facilitate the exchange of claims and assertions. May be phyiscal or virtual.
Note: The last confuses me, in what sense is the ID Gang an 'asserting party'?
In my opinion, any taxonomy that allows for the 'Ego' but doesn't acknowledge the importance of the 'Id' is lacking.
According to Freud, the Id is that part of the psyche that deals exclusively with the needs of the individual - the Id doesn't care about anything else. It's all me me me.
Sounds super. Consequently, I propose here
Id-centric - a model of identity management in which the user's desires and wishes come before all other factors (business realities, regulations,technical limitations, etc).
Science seems to be missing an obvious resource
Me: I need a new MP3 player
Me: I couldn't get an earlier flight home from Hawaii
Me: I read it for the articles
Monday, August 28, 2006
Kaliya wants to be known as 'Identity Woman'.
Kaliya sees a bias against such titles
I find it interesting there is such a focus on that positional title to have legitimacy in this industry. I really think it is a disservice all around there are people who contribute a lot without positional ‘titles’ who deserve to be on stage some times perhaps more then those on stage who have ‘titles’.This to me reflects the distinction between self and 3rd-party asserted identity. It's easy to make claims about yourself - but sometimes relying parties want 3rd party assertions.
"Positional Titles" (as Kaliya describes them) are typically names given to us by somebody (a boss) or something (a corporation, a coach, etc) else and, as such, present a different set of criteria for assessing validity than self-asserted claims.
There is of course supporting evidence that lends creedence to Kaliya's chosen moniker (her resume, her history of unconferences facilitated, opinions of colleagues, her Canadianness, etc). It would be hard to get all that across to a conference attendee when reading a list of speakers.
Friday, August 25, 2006
Wednesday, August 23, 2006
Currently, QR-codes are typically used to bridge between the real-world and the digital-world, e.g. a user will use a reader in their phone to scan a paper flyer's QR-code with an embedded discount coupon. They can then use that coupon for an electronic purchase. The QR-code prevents them from having to type in some ugly URL printed on the flyer.
A similar application for identity would have a QR-code printed on my business or name card. The QR-code would facilitate the extraction of the identity into digital form without typing, like OCR but with capacity beyond the text actually printed on the card.
Kaywa's identity application of QR-codes, as shown at Roger's identity page, is interesting as the QR-code is displayed on the screen and not on a paper card (although it still could be). Rather than scanning a business card, your potential contact would use their phone scanner to scan the code from either their screen (while reading your blog etc) or your phone (when face-to-face). Scanning the QR-code bridges the "air gap" between two digital channels in a way that microformats etc can't do (but Infrared can, so perhaps an advantage of the QR-code scanning model is the improved privacy from not broadcasting?).
AFAICT, Japan is leading the way with respect to new uses of QR-codes. I know I've seen some very interesting applications for identity on my visits back to the NTT Mothership.
Extra points for decoding this.
Here is the log of some random queries the extension made on my behalf
*** Log started at Wed, 23 Aug 2006 11:00:49 GMT ***
[ACTION] type: saveOptions=true | Wed, 23 Aug 2006 11:00:49 GMT
[QUERY] engine=google | query='user centric' | 200 | Wed, 23 Aug 2006 11:00:50 GMT
[QUERY] engine=google | query='whatis user-centric' | 200 | Wed, 23 Aug 2006 11:00:52GMT
[QUERY] engine=google | query='defn user-centric' | 200 | Wed, 23 Aug 2006 11:00:53 GMT
[QUERY] engine=google | query='consistent defn user-centric' | 200 | Wed, 23 Aug 2006 11:00:54 GMT
[QUERY] engine=google | query='paul madsen' | 200 | Wed, 23 Aug 2006 11:01:03 GMT
[QUERY] engine=google | query='paul madsen' | 200 | Wed, 23 Aug 2006 11:01:04 GMT
[QUERY] engine=google | query='paul madsen' | 200 | Wed, 23 Aug 2006 11:01:05 GMT
[QUERY] engine=google | query='paul madsen' | 200 | Wed, 23 Aug 2006 11:01:06 GMT
[QUERY] engine=google | query='feel insecure' | 200 | Wed, 23 Aug 2006 11:01:07GMT
[QUERY] engine=google | query='paul madsen' | 200 | Wed, 23 Aug 2006 11:01:08 GMT
[QUERY] engine=google | query='ego surf' | 200 | Wed, 23 Aug 2006 11:01:09 GMT
[QUERY] engine=google | query='britney spears' | 200 | Wed, 23 Aug 2006 11:02:02 GMT
[QUERY] engine=google | query='hide searching' | 200 | Wed, 23 Aug 2006 11:03:03 GMT
[QUERY] engine=google | query='identity manage' | 200 | Wed, 23 Aug 2006 11:03:05 GMT
[QUERY] engine=google | query='halle swim' | 200 | Wed, 23 Aug 2006 11:04:06 GMT
[QUERY] engine=google | query='marriage help' | 200 | Wed, 23 Aug 2006 11:04:07 GMT
[QUERY] engine=google | query='data encryption' | 200 | Wed, 23 Aug 2006 11:04:08 GMT
[QUERY] engine=google | query='private eye' | 200 | Wed, 23 Aug 2006 11:04:09GMT
[QUERY] engine=google | query='divorce lawyer' | 200 | Wed, 23 Aug 2006 11:05:03 GMT
[QUERY] engine=google | query='child custody' | 200 | Wed, 23 Aug 2006 11:06:03 GMT
[QUERY] engine=google | query='dating tips' | 200 | Wed, 23 Aug 2006 11:07:03 GMT
[QUERY] engine=google | query='firm abs' | 200 | Wed, 23 Aug 2006 11:07:04 GMT
[QUERY] engine=google | query='viagra ' | 200 | Wed, 23 Aug 2006 11:07:06 GMT
[ACTION] type: showLog=true | Wed, 23 Aug 2006 11:02:24 GMT
Well this isn't going to help.
Tuesday, August 22, 2006
The irony is of course that, at any one time, roughly half of the US population is skiing Alberta's hills.
It may just be that the climate in her home town is more conducive to deep thinking (after all, what else is there to do in Alberta?)
Proxy or forgery - tough call. Ultimately it would be in the eye of the beholder (the one with the gun who will likely tend to err on the side of a strict definition of validity).
A proxy for Passport, I thought that's what Windows Live ID was?
Regardless of the results, I already know everything I need to know about anybody who actually spends the time taking such a quiz. "Oh my God, you're an Apple, so am I!"
I don't think I'm unique in having trouble understanding the differences between RAND, RF on RAND Terms, and RF on Limited Terms. I love to argue but that doesn't make me a lawyer.
I created the following table to help me. As I see it, the two most important parameters are whether or not the patent holder may be able to charge royalties, and whether or not any terms (other than royalties) are left open to possible negotiation between the patent holder and the licenses or explicitly called out. So, at its most basic (and surely glossing over important subtleties), a 2 by 2 table.
Does beg the question, why was RAND on Limited Terms ruled out?
And if you base any real business decision on this interpretation then the title is a good fit ...
Breaking News: I was very proud of this table. At least until I saw OASIS's version. I swear it wasn't there the last time I looked.
When I saw Kaliya Hamlin at Gnomedex, she told me about the Liberty People Service. This is the kind of thing that would be very useful to integrate into Chandler, so I made sure to attend Paul Madsen's session on the People Service. The session was dominated by technical content as people tried to understand how the service actually worked. Despite being unfamiliar with most of the Liberty specs, I found that I had no trouble following the discussion. I spent a year or so doing some consulting on the WS-* web services stack, and that experience made it possible to follow along. I had also read the People Service whitepaper. which probably also helped. I was disappointed to hear that there are no implementations (other than private prototypes) of the People Service that someone could get a hold of and play with. In this day and age, I expect a spec to be accompanied by a reference implementation or something. Maybe I've just been hanging out with the wrong people.
1) I'm glad Ted got something useful out of the session - his criticism of the lack of an implementation is valid, hopefully the emerging Liberty Open Source initiative will address this.
2) I can't believe I looked this confused this early in the session - later sure but I've only drawn a single user at this point and I look stuck.
Identity systems are an example. They are sufficiently complex that to adequately model and differentiate different systems, three 'axes' seems the bare minimum (4 would be better but ...)
These three seem useful:
Axis 1 - Control Mechanimsms - whether the system enables the user with direct (in the flow) or indirect control (through defined policies enforced by a trusted 3rd party) over the release of their identity.
Axis 2 - Relationships - the nature of the relationship (e.g. trust, legal, etc) between the entity releasing some piece of identity and the entity consuming it. DIfferent systems assume different degrees of coupling.
Axis 3 - Identity - the nature of the identity being shared, e.g. is it an identifier for a subject or other less discriminating attributes.
Different identity systems can be plotted against these co-ordinates. As an example, SAML's Web SSO Profile, when using persistent name identifiers and the HTTP Form POST Binding, can be characterized as:
- having the identity flow through the user-agent, and thereby enable direct user-control over its release
- typically sharing an identifier for the subject and not extra attributes (although possible)
- a symmetric relationship between Identity and Service Provider (the IDP 'knows' the SP as well as the opposite)
Others to follow.
Monday, August 21, 2006
It's the little badge in the above, the text and colour of which I chose (private joke).
From the FAQ:
What if I don't see my sign-in seal?Given this sort of guidance (essentially "do all those other checks that this mechanism was designed to replace"), a phisher would be crazy to try and simulate a seal, just don't display anything and count on the user being appropriately conditioned by all the valid exceptions listed above.
You could be on a fraudulent site, but there might be other reasons why you can't see it. For example, someone else using your computer may have deleted or changed your seal, your cookies or files on your computer may have been deleted, or you're using a partner or international Yahoo! site (like BT Yahoo! or Yahoo! India). To be safe, look for these other clues to make sure you're on a genuine Yahoo! sign-in screen.
If Yahoo! had any guts the above guidance would have been 'Play it safe - do not attempt to log-in'.
I searched for 'identity card art' (motivated by this and this) and discovered the Identity Card Concept Project an interesting exploration of possible future variations on today's business card - organized into themes of true identity , digital identity, control, memory, ritual, and branding.
Two of the control proposals, the Perforated and Onion Card feel very user-centric, the owner of a business card would be able to customize his/her card in real time to the context (who, what, where, why, when) in which it was being presented.
For the perforated card, each bit of identity could be punched out if inappropriate for a particular recipient. The idea could be taken one step further with some sort of punch table (like for 3-ring binders) that would, upon appropriate configuration (e.g. turn the 'When' lever to 'Friday Night' and the 'Why' lever to 'Dating'), remove all irrelevant identity. People would want to tailor their 'IdentiStampers' (Copyright Pending) to suit their tastes I'm sure.
I found the description of the Onion Card particularly interesting - it paints a picture of negotiation and progressive disclosure - each participant sharing more information as their partner does. A "You show me yours and I'll show you mine" model. It also implies a connection between the physical world in which the card is presented and the digital world in which the identity is stored (and a market for compact bar code readers). I do think the cards would look much cooler if they used QR-codes.
While in the Perforated model the user holds their identity themself (under the mattress as it were); in the Onion Card model they carry only pointers to the identity, the actual data is held elsewhere on their behalf by some trusted 3rd-party and released upon successful request (with the bar codes acting as bearer tokens).
Sunday, August 20, 2006
Makes me think of something like the following for identity transactions, with some typical identity operations thrown in (with a little but not much thought to logical organization). The purple keys are meant to represent operations performed at the user's Identity Provider. The greeen, yellow, and red keys for responding to identity requests (with some representative answers). Other "non-identity" keys are greyed out, reproducing the visual effect of the similar Cardspace behaviour.
When not warranted by some request for identity, the keys would show whatever other letter/function/operation was appropriate.
When I was in Oxford last month for the XML Summer School, in between dodging gangs of colour-coordinated teenagers in the city for English instruction , I picked up a 3-pack of Antonia Fraser biographies of English notables.
I started with Cromwell, Our Chief Of Men (warts and all) and am now thoroughly enjoying King Charles II (still anticipating the debauchery - you're a King man, use the power!).
A conversation between Charles (post-Restoration) and his advisor Clarendon jumped out at me. The two are discussing (through notes passed during a Council meeting) an upcoming trip of the King:
Clarendon: I suppose you will go with a light Train
Charles: I intend to take nothing but my night bag
Clarendon: Yes, you will not go without forty or fifty horse?
Charles: I count that part of my night bag ...
There, but for the medium, is an IM log (wit and all). I'm sure Charles felt the lack of a smiley for his last :-)
Oxford was good (but not good enough) to Charles's father, as it was to me. I do hope the Royal apartments had air conditioning though.
Friday, August 18, 2006
.... you're getting ready for a mountain bike ride and you can't find your water bottle and you think of an alternative.
Thank God we're past the bottle stage, who would burp me out on the trails?
Kim Cameroon responds and clarifies.
Kim had previously showed a Ping ID demo that he asserted nicely demonstrated how 'user-centric' and 'federated' were compatible but orthogonal.
I think the demo is undeniably cool and shows a perfectly valid use-case. What I question is Kim's claim that it displays some clear and fundamental distinction between user-centric and federated identity.
According to Kim, the user-centric piece of the demo (where the user authenticates to the portal with Cardspace) helps 'people get through their day' and the federated piece (in which the user is SSO'ed into various services) is 'tieing portals together'.
For the demo, this seems an accurate description. It is only when authenticating to the portal that the user appears to have any control over the release of their identity (by selecting and reviewing an Identity Card). Once signed-in to the portal, the demo suggests that the 'user-centric experience' is over, from here on the portal and the services decide what identity gets shared, and the user's ability to control this boils down to clicking on the relevant service 'Sign On' button or not. This piece of the demo doesn't appear very user-centric at all.
But of course the demo could well have shown the portal offering the user the same sort of fine-grained control over identity release to the various services - what gets shared needn't be a done deal between the portal and the services and out of the user's control.
Put another way, if user control over the sharing and use of their identity is the prime criteria for user-centricity (which I believe is the case), then there is no reason why user-centricity cannot extend into the identity exchanges between the portal and the services - the user can have meaningful control over these exchanges just as they did for the exchanges between their local IDP and the portal.
Hubert has another demo that shows "federation" technologies used in this manner.
I take the following from this thread (and another that Kim engaged in with Conor).
User-centric identity requires:
1) a philosophy of user-empowerment +
2) technology (protocols, UI, consent mechanisms, etc) in support of #1.
If an identity system has the first(who would claim anything less), but the technology can't back it up, then it's not user-centric. Conversely, technology (any) can always be applied in a non user-centric manner if not deployed in a manner consistent with the philosophy of empowerment.
Amazon's Real Name mechanism goes to the other extreme. In order to establish confidence (dare I say 'trust') in people's online activities at Amazon (e.g. reviews), these activities are bound to their real life identity (as verified by the credit card infrastructure). Presumably, I'm less likely to do a hack job on some book if I have my real identity attached to the review.
Interesting that such real name attribution is given less weight than reputation in determining the score for a given review.
I guess the old saying "It's not who you are but who knows you" holds true.
Don Park proposes generalizing the email mechanism (email gets sent to provided address, user clicks on embedded link) often used at registration and/or password recovery time into a true authentication mechanism.
Rather than do this only initially and then subsequently as occasionally necessary, the user would authenticate this way every time (or at least when cookie expiry made it necessary). No password necessary at the site, and so it's a kind of SSO based on the authentication to the email server. Nice.
Message delivery lags and spam filters could make the system impractical. In my experience, the 'Confirm Account' mail can arrive long after I try to register, which isn't an issue if the site lets me proceed in the interim, but would be an issue if it prevented me signing-in.
More fundamentally, it seems a step backwards. Current reality is that just about every site already has my email, and so Don's scheme wouldn't change the nature or scope of the info that I need share with sites in order to get service. But, I don't like this current reality. I don't want to have to give my email(s) out to all these sites, constantly doing the mental computation 'I'm never going to be back here so I'll use an email address with a high disposability factor'. Don's model reinforces this status quo.
As an aside, Don's model fits the pattern of challenge-response authentication - the site's challenge is 'Can you access this email account?' and the user's response is 'You bet (and proves it by clicking on the link)'. I'm surprised to see that SAML doesn't appear to provide an Authentication Context to describe this basic pattern. The only support for challenge-response in the Authentication Context schema is the SharedSecretChannelResponse element, and in Don's scheme, the email address is probably no secret.
Thursday, August 17, 2006
"User-centric" music sounds too much like I'd be listening to my neighbour's twangy rendition of blue grass classics. No thanks.
It sounds like iMeshToGo and BearShareToGo will offer a long awaited solution to the problem of illegal file-sharing, and the other problem of no way for people to buy music in an effective way that is user-centric.
It fills an important niche in the SSO space, namely the 'Monthly SSO system claiming to be simpler than SAML' niche.
The idea of sharing your Identity Provider account password with random Service Providers seems attractive. After all, if I'm presenting it to every site I interact with I'm less likely to forget it. As they say in the Guiness ads, "Brilliant!".
The following sentence particularly caught my attention.
The Liberty Alliance has churned out a number of PDFs but that seems to be the extent so far of their effort.
I don't know why people are constantly scoping the Liberty Alliance down to the publication of just PDF documents - we are far more than just that. It seems that just because the best known examples of our published material are in PDF, then somehow we get typed as only publishing in PDF.
Fundamentally, the Liberty Alliance defines a marketing framework, a platform on which can be built systems capable of publishing in a variety of formats appropriate to different marketing applications. Any particular publishing run is able to use the Liberty framework in a manner that suits the sort of marketing campaign being targetted. Examples of particular file formats supported by the Liberty framework include Powerpoint, HTML, JPEG, Flash etc and of course, yes, PDF.
There are lots of publishing frameworks that support one or two of the above formats, LAP is, AFAIK, unique in its "publishing format breadth".
Update: Conor reminds me that Liberty has also published in plaintext. I also forgot WML. This just reinforces my point about the flexibility of the Liberty publishing engine.
Conor also implies that, in my eagerness to deride, I missed the point. Ah my constantly green-clad Irish friend, I knew full well that others would make the 'billion Liberty-enabled identities' & 'countless deployments' argument (as well as dig deeper than I did in an actual security & privacy assessment of the proposed SSO solution).
Wednesday, August 16, 2006
I think of the stated criteria (e.g. demonstrable ROI and benefits, etc) as loose 'best-practices' for judging rather than normative MUSTs and SHOULDs.
Any deployment that uses a spec I have an emotional attachment to might just have an advantage. Show me a People Service implementation, even if only sketched out with lipstick on a cocktail napkin and coded in Fortran, and start planning what you'll wear on stage when you accept (assuming I can sway the others).
Monday, August 14, 2006
I've experimented with permanent markers to identify the replaced jets - it seems 'permanent' doesn't apply to hot chemical baths. Tape gums up. I'd lose any record on my PC. Consequently ....
I've been popping for similarly over-priced key chains for Sophie at every location I've since travelled to. Her first question when I return from a trip is inevitably 'Did you get me a key chain?' She has even created a taxonomy for the different styles, e.g. the 'turny' ones are her favourites (three of them visible at lower left below).
As Liberty Technology Expert Group is returning to Paris next month, it seems an appropriate time for a status report.
Sunday, August 13, 2006
Kim asserts that the demo illustrates (paraphrasing) "user-centric technologies like Information Cards are not in any way counterposed to federation technologies".
I completely agree with the sentiment, but question whether the scenario portrayed by the demo actually demonstrates it.
In the demo, a user authenticates to a portal using CardSpace. Once authenticated, they are presented with a list of applications available to them for which SSO is possible (this presumably dependent n which I-Card they selected). For Kim, the user-centric piece (CardSpace) somehow ends at the portal, and from then on federation (SAML etc) takes over.
So, user-centric and federated technologies are shown as working together - but not at the same time. The user-centric piece hands off to the the federation piece. Federation is presented as a lower-level piece of infrastructure (which it can be) that doesn't seem to touch the user.
This interpretation is reinforced by Kim
To my way of thinking, you have two more or less orthogonal technology efforts - that oriented around federation issues, and that oriented around the user’s experience.
This ignores the possibility for SAML-based technologies to provide the very same user-experience (i.e. real-time identity sharing control, IDP selection etc) that I-Cards enables. Is SAML's Enhanced Client or Proxy (ECP), as it enables similar control mechanisms, then user-centric?
Probably not, as Kim also hilites the common UI of Cardspace and its relevance
Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system
If the phone manufacturers (or those of set top boxes) were to come together and agree on user-interface standards - would that be user-centric?
Friday, August 11, 2006
Makes the Google OS model more and more attractive. Maybe they should be marketing a $100 laptop at business travellers rather than the masses.
Tuesday, August 08, 2006
On the Identity Trail
If this title doesn't push my stats through the roof (i.e. 20/day) I will be very disappointed.
Sunday, August 06, 2006
In MySpace's FAQ, the answer to 'Someone is pretending to be me - what do I do?' includes:
In order to verify your identity, please send us a "salute". This means we will need an image of yourself holding a handwritten sign with the word "MySpace.com" and your Friend ID
Beyond the environmental trajedy of the trees that will be cut down to supply paper for these signs, Kim points out the difficulties with this scheme, arising I think from the fact that the MySpace staffers aren't at all qualified to say which face (unless some celebrity) goes with an identity. The people who are qualified to make this distinction are those that know the person outside of MySpace and so can say 'Uhh, Bob doesn't have red hair and breasts ...'
Maybe the mechanism should require that there be two people in the picture, one claiming 'I am Bob' and one attesting 'I am Tony and this (pointing) is indeed Bob'. But, then who attests to the attestor's identity? Ok, three people in the photo ....
I have to wonder why they stipulate that the URL on the sign be hand written. To prevent automated machine salutes?
Saturday, August 05, 2006
Wednesday, August 02, 2006
Will the fact that 'There was no XML in the response' be helpful to Roy in Saskatchewan?
'Ahh, yes, that makes sense, I thought the problem might be the XML response status ...'.