Adventures of an Eternal Optimist

I love working with smart people.  I went into the ICF schemas working group call with my set of gobbled-together proposals, and everybody seized on it and started breaking those ideas down into their separate pieces, using language with far more structure than my own words.

There were some excellent points made:

• What are the expectations of the “Display Claim” versus the actual claim in providing human-readable claim values?  Is it reasonable (or even preferable) to define a claim value that is not human-readable and trust that the STS will be responsible for mapping that value to something useful?
• Is it expected that the selector will do a metadata discovery on each and every claim passed?  I had never even thought of such a thing, so will have to learn more.

I will keep you up to date with the conversation, which is expected to continue on the working group mailing list this week.  The mailing group is:  http://groups.google.ca/group/icf-wg-schemas,  I believe anyone can read, but you have to be an ICF member to participate.   If you are keen to participate, let me know.

During IIW, the ICF Schema Working Group proposed and approved its first standardized claim definition.  I’ve been following the workings of the schema group but not closely, and I was taken by surprise at the values defined as part of this precedent-setting claim element:

Claim Name:  age-18-or-over

Proposed Values:

• 0
• 1
• 2

What?  Want to know what the values MEAN?  Sorry, you’ll have to look that up.  What you see above is what a Mother or Father will see when they view values passed between the Identity Provider they are trusting to make claims about their children’s age, and a website that may restrict content based on that value.

Do you see the problem?  Why on earth even have a selector if the standard claims we propose are not understandable by end users?  Why use a meaningless number?  To make it easier for the machines?  For the developers? That’s crazy!  Why don’t we make it easier for the people that are making selector-level security decisions on a daily basis?  These schema types have to be created so that whenever possible, the data passed is legible to those attempting to understand the context of identity data flowing around them.  Heck, if we created a vocabulary for content that could be distinctly identified and parsed by Selectors, we could even localize.

It’s taken me since IIW to really get my head around this – but I believe we need to set some very specific best practices around these schema elements, first and foremost being the primary design principle that these atomic elements should be designed for regular people, not for developers, and not for machines.

I’m going to do my best to argue this point today on the ICF working group call.   If you think this is important, whatever your stance on the issue might be, I urge you to join the Information Card Foundation and to make your voice heard.   Contact me if you aren’t sure what you need in order to join, I will put you in touch with the right people.

I think that best practices around claims schema is THE MOST IMPORTANT thing happening right now.  It is worth taking the time to get this right.  We’ll only get one shot at it.

The public version of the claim catalog is here:   https://informationcard.net/wiki/index.php/Claim_Catalog

I just got home from CSI 2008,  and I have to say, I’m incredibly impressed.  The more I speak at these things, the more I’m realizing that there are qualities in conferences that make or break the experience, and this conference has crystallized some of those qualities in my mind.

One of the qualities I saw at CSI that I now recognize as a critical factor, is that there is a core expert community who are re-occuring, recognizable faces.  CSI reminded me of The Experts Conference (formerly DEC) in this area — both conferences have this group of friendly, accessible people who are around throughout the conference, speaking but also participating.   These are the people who can transform a group of complete strangers into a community that interact with and learn from each other. You need the big names that jet in, speak, and leave – but those big names are in some sense sterile – they have no community context or history, they have no understanding of what else might have been said – they speak in their own vacuum, and generally the message is a one-way broadcast.   The message may be valuable – but it often doesn’t build on previous conversations.

From a conference organization perspective, I think that the CSI setup was revolutionary.  Every morning, the entire conference assembled for a series of short keynotes which acted as introductions and advertisements for the themes of the day.   Once the keynotes ended, attendees could choose separately-titled individual talks, or they could attend one or more parts of a multiple-timeslot “summit” created around that day’s themes.   Within those summit sessions, speakers still gave presentations, however emphasis was not on slides, but on two-way conversations.  In the summit sessions I attended, all of the speakers were up-front for all of the conversations, so it ended up being a very interesting mix of slides, panel conversation, and audience input.  The keynotes at the beginning of the day gave the speakers a chance to pique the interest of attendees in a way that a conference agenda title just can’t accomplish, and given the theme of this conference,  “security reconsidered”,  it made perfect sense that the keynotes be constructed to interrupt the status quo.  I’d like to see this kind of interruption become the focus at more of the conferences I attend.

Thank you CSI,  for the invitation and for the experience, it was extremely positive!

There are two interesting new selector features to play with in the CardSpace Geneva beta.  The first is the idea of the card tile,  where (as I understand it, no guarantees of accuracy here) the browser interacts with the selector to discover, cache, and display the image of the last card you have used at a given RP as part of the context of the Relying Party page (rather than as a separate context).  The Relying Party never sees or can access the image of your card.  This mashup-like user interface is meant to be personalized and more inviting to users.

The second new feature is the “always use this card at this site” checkbox.  If you check this box while authenticating with a card, you will subsequently see your card tile, but after clicking that card tile, the rest of the process happens without further interaction.  Web site operators can veto this convenience if they wish, by adding a new parameter called ‘requireUserInteraction’ to the information card trigger object and setting the value to true.

I think the always use feature really works well in combination with card tiles, as the user retains context without having to push more buttons.  I don’t know how to non-destructively change my mind about always using a given card at a particular site though. I tried restarting the browser, restarting the machine, and clearing “private” data from the browser without effect.  I tried going to the control panel and opening CardSpace directly, but nothing there helps.  Short of deleting & reinstalling the card, one click of that checkbox and I become permanently committed to a silent transaction with the Federated Identity demo website forever more.  I’m sure this lack of choice is temporary (after all this is a beta) – but if possible, I would love to see more on the CardSpace blog about the planned persistence model for this feature, and about what the plans are for letting people manipulate it or even disable it.

When I first heard of card tile feature, I hated it.  Now that I see it in use, I understand the value proposition, but I still have to point out that this little picture represents a critical piece of user context information.  I can’t help but think that to allow the card tile image to be manipulated by the browser is to eventually serve it to the bad guys on a platter.   I hope I’ll be proven wrong.

Other thoughts:

• Visually, I worry that the card tile feature lacks a strong enough branding consistency for people to easily identify where on a given page the information card trigger form is — if, for example, I happen to use a card which blends into the page, it might be confusing.  Even with the example site,  it isn’t immediately obvious that the picture placed front and center is also intended to be a control.
• Along that same line, I wonder how much control the web designer has over the size, style, and placement of the card tile.  Is there a standard form factor or is the sky the limit?
• I hope that a card provider could also have the power to disallow the “always use” feature for certain types of cards.
• Will there be some kind of maximum limit to how long that little checkbox lasts?
• Currently the beta card service and RP service appear to be a closed circle – I’m very excited to see the beta get to the point where I can start to play with these features using my own code base.

Check out the blog entry from the CardSpace Team:  http://blogs.msdn.com/card/archive/2008/11/18/the-cardspace-geneva-selection-experience.aspx Mike Jones also blogged on this: http://self-issued.info/?p=94

• If you play with this beta,  remember YOU NEED TO GET THE CARD FIRST, as it is a managed card, and self-issued cards aren’t part of the beta yet.
• If you aren’t seeing the card tile, check Mike’s blog entry above for a link that explicitly asks for that feature.
• When you click on the card link to import the card,  nothing happens; the card installs, but the selector doesn’t open or even give you a popup.  I’m not sure if this is by design, or if the acknowledgement of successful install just hasn’t been put in yet — but I hope it is the latter, because without some kind of feedback, people like me assume that it either didn’t work or that it is still running and that I therefore have to wait.  I only discovered that my work was done when I clicked the link a second time & was asked if I really wanted to install a dupe.

Today was an interesting day for the Identity geeks of the world.  A viral outbreak of concern broke out among twitter users over site called “Twitterank”.    Twitterank asks for your credentials and displays a number theoretically outlining your theoretical socal viability in the twitterverse.

Once the word “phishing” became attached to the service, people became fascinated.  I have no idea of the order of it all – but several things happened:

• A ridiculous number of people decided to try out the alleged phishing site.  Some of them even changed their password afterwards.
• References were passed around to a site called “Twitterawesomeness” that appears to exist as a very pointed statement about how easy it is to phish a site like twitterank. The disclaimer states:

I’m in ur Twitterz, stealin ur credz!
It’s ok, 178 other people gave their passwords too!

• The author of Twitterank came out with this statement:

I’m not out to steal ur twitterz. Frankly, I wish I didn’t have to ask for your account info, but Twitter doesn’t offer APIs using any other authentication mechanism (according to the docs). So blame them.

So let’s see then:

1. twitterank is right.   The best way to protect the passwords of the users of your service is to provide alternatives to giving away your password.   Granting permission for another entity to see your data is something Twitter can securely enable – or ignore.  We know where they stand so far.
2. twitterawesomeness is right too.  It doesn’t matter whether twitterank is crooked or honest.  Anyone who wishes to spend the 10 minutes to emulate twitterank’s main page can harvest passwords, if they can get people to click on a modified link.  Obviously not a difficult task – especially when people only see a “tinyurl” for most of the links they click.  Heck, just register “twitterrank.com”.  People will come to you.
3. To all you folks who changed your password — do you use that password anywhere else?  Cause if I were going to steal username/password combinations, it certainly wouldn’t be to read a twitter stream.  But I’m sure nobody would be crazy enough to use the same combo at twitter and at their bank…  what about the password you might have had when you tried the service a month ago?
4. In fact – even if you don’t use that combination at your bank, I might be able to still get there. I would use the credentials to harvest your email address from twitter, and then try to login to that email account.    If I was lucky and got a hit, I could then start putting your email address into password recovery pages for all sorts of interesting places.  Once you have email, you have the keys to the kingdom.

Of course, I could also just phish your bank site.  Occam’s razor applies here.  Still, the point has been proven.

Mashable Link

ZDNet Link

Go ahead.  Have fun without me…

*whimper* *pout*

I’ll just stay home and feel sorry for myself while you all solve the worlds problems.  Maybe leave a few just so we can meet again in May, ok?

The least you can do is take lots of pictures,  and write GOOD NOTES so us remoteys can keep up.

Enjoy,

Pamela