Information Cards on Drupal

Finally! I’ve got what I hope to be a decent prototype for a Drupal Information Card module.    I’ve made huge changes to the user interface on this one, and as a result, I hope to have streamlined the process for framework owners.   What I haven’t yet got, is a lot of eyeballs from a lot of people on different platforms, in different situations, and with different frames  of mind.  If you have 5 extra minutes, please check out my example site.   There is a poll there to let you give extra-fast feedback, and there is a feedback form if you want to address a specific finding.

Here’s a quick summary of the new features:

User Card Management

• Once authenticated, users can add and remove cards from their accounts, as well as seeing when the card was associated and when it was last used.

Lost Card Recovery

• Users can now use an email-based recovery process to attach a card to an account that they’ve lost credentials to.  This is incredibly important in a case where all passwords have been turned off for the site.

Purple “i” means Selector launch

• Everywhere you see a purple “i”, you should see a selector launch immediately – no more intermediate pages.
• (Note there is a purple “i” in the card mgmt console, that card will eventually launch the selector to verify the Friendly Identifier)

Minimum clicks

• The goal is to get the job done in the smallest number of clicks.   There is probably even more to be done here, but we’ve made progress.

Developer Improvements

• Code is now documented with a standardized, doxygen-compatible format
• Much more consistency in approach
• Lots more to do 😉

WordPress users:  I’m upgrading that plugin right now to use the same flows — so if you don’t like them, speak now!

Microsoft Live – say it is not so.

I hear you’ve been going back on your word, Microsoft Live.  I hear you’re talking behind people’s backs, giving away all their secrets.

If you want to change your current policies on accepting anonymous comments, fine.   But when you promise a user that the comment they are about to submit is anonymous,  that promise should mean something.  Forever, not just until your next TOS change.  You shouldn’t have even stored information about who made a comment if they asked you to keep that comment anonymous.

People trusted you and believed in you, and they acted according to their trust and belief.  They didn’t know that anonymous really meant “tracked, stored, and correlated, but hidden only until we decide otherwise”.

Those of you out there who think anonymous comments are only about making nasty retorts or spamming- think again.  Sometimes, anonymity enables people to talk about their health, their relationships, their issues, their innermost thoughts, things they would otherwise be afraid to reveal.  Sometimes, anonymity enables an intimacy that can be a lifeline in rough seas.   Anonymous comments can be as deeply personal as any church confession – imagine if your confessions were taped, played to the world, and associated to you forever more.

I suppose the only moral of this story is to assume the worst about any technology that makes promises around secrecy.  Perhaps this will encourage pseudonymity – at least then you’re known to be tracked, but you can control what correlation might exist to your real name.  If nothing else, this should call into question the practices of any service that supplies that little “post as anonymous” checkbox.

Lowest Common Denominator

Yesterday Friend Connect added Twitter to their list of accounts that can be used to authenticate and to communicate friend data between cooperating sites.

From a social graph perspective, this makes complete sense, although I’m not sure what is supposed to happen when a twitter user with 5,000 followers and following 5,000 logs into a site for the first time.   I have to assume that you get little dribbles and drabbles of friend links over time, in the background.  Still,  if the website operators are using an elastic, as-needed payment model, it could be rather expensive for true twitter addicts to visit for the first time.

From an authentication perspective,  I can only laugh, the irony is too much for me.   Twitter as a provider of identity information.    This is a site with an unbelievably cavalier attitude towards the credentials of users, as evidenced by the fact that they force their entire partner community to ask for and resend usernames and passwords, and as evidenced by the fact that they encourage their users to type their credentials into any input box that might present itself with the short introduction of “Twitter API”.

You may say that Twitter was never intended to be a highly secure service,  and I’m sure you’re right.  What so many people in this industry are trying to do, however, is to provide a way for services like Twitter to no longer have to badly manage their user data,  but instead to rely on the services that DO care about security,  and do actually take the security of user credentials seriously.

In the short term though, convenience wins out over security. It’s bass-ackwards, but it’s still progress.  Gotta crawl before we can run.  Anything that connects sites and propels application and service owners to start considering externalized Identity is good in my book.   We need to get in there, mix it up, and hope that something reasonable emerges from the fray.

On Aggregation

Do you remember this quote from the movie “The Incredibles”?

… And when I’m old and I’ve had my fun, I’ll sell my inventions so that *everyone* can have powers. *Everyone* can be super! And when everyone’s super– [chuckles evilly]  –no one will be.

Sometimes I think that this is the end game we’re looking at with Social Media.  Right now, we’re so busy hooking every acquaintance we ever had to every other acquaintance as virally as possible on every site everywhere, that we forget who it is we’re going to end up talking to, and to whom our words have meaning.

It’s great that we’ve gotten to the point where I can broadcast a single thought simultaneously to all of my many services – but what happens when everybody does that?  What happens when the majority of the people you know are on two or more of the sites you visit and all of them are broadcasting across services? I like seeing tweets from people I know.  But when I see the tweet on twitter, then the next time I get onto Facebook the identical tweet shows up as a status update, and then I see it yet again in a weekly digest of tweets that shows up in my RSS reader from that person’s blog –  it gets old fast, and it takes away from the unique character of any one service.  As a very subjective judgement, I personally start to feel more like I’ve been spammed than confided in.

Right now, I would choose an aggregation service not for the combination of what’s different so much as the elimination of what’s redundant. As all these services bleed into each other, the ratio of new to redundant will become very pronounced;  I imagine that creative solutions to this problem will be an important future differentiator.

TEC 2009

Thanks Axel for highlighting my TEC 2009 talk abstract — you’re much better at publicizing my upcoming speaking plans than I am, something I need to improve upon!

My plans for TEC 2009 are indeed to talk about a Survivalist’s Guide to Identity Management.  In my years working in this space, I can’t help but note that most of the things that companies pay me to unravel are things that a little foresight and planning could have rendered unimportant – often they come down to configuration decisions made arbitrarily in the absence of any guiding principle.  I believe that if you can introduce some simple discipline into IT practices early on in a company lifecycle, you can drastically reduce the complexity, and therefore the cost of automating your processes and applications when the time comes.  My goal is to document that discipline in very simple terms, and then to demonstrate how  a pragmatic IT department can go on to derive benefit from that discipline.

I can’t tell how much I’m looking forward to this presentation – It is a topic very near and dear to my heart, and something I hope to enlarge upon whenever I can, for a long time to come.

Just got off the Schemas WG Call

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.

We MUST get this Right

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

Home from CSI 2008

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!