Adventures of an Eternal Optimist

I just read about the Open Social Web API: it would seem that a bunch of the silos of the world are about to begin using a common API to talk to their apps (and maybe each other?) about, among other things, previously sequestered identities and relationships.

I’m monstrously curious about if and/or how identities will be mapped between “containers”. I’m curious about the whole thing, in fact, as both a user of such services and as an identity control freak. I can’t wait to see what mechanisms are used, and whether something with some kind of identity & privacy cachet was tapped.

Will I like what I find? This quote from Brian Oberkirch makes me wonder:

Finally, I’ve seen no mention of the fact that every bit moved through these APIs will be mapped via Gdata into a great Google graph of social interaction. A version of Brad Fitzpatrick’s master graph, but part of the Googleverse.

Call me crazy, but isn’t a “master social graph” without any reference to consent or control from the user really just internet-scale involuntary identity aggregation? I don’t care whether the “social graph” is in fashion or not, I sure as hell hope that I can opt out if I so choose. I imagine that both the terms of service and privacy agreements for any partner service involved in the Open Social API will have to to change, and I shall be very interested to see what exactly those changes will be.

No matter what, this API is still a critical first step. Inertia is being overcome with respect to opening up user community silos. The what is good – but all of us scrappy identity and privacy folks had better hasten to examine the how, too.

Paul and Gerry have been talking about levels of assurance for self-asserted vs. managed cards, loosely based on my Let’s talk Turkey entry from awhile back. Paul calls Gerry’s stance hard-line; I’m inclined to agree.

Gerry states:

… as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

1. No assurance – self-managed cards, or any managed card where the Issuer is not enforced by the RP
2. Assurance – managed cards where a particular set of Issuer(s) is required by the R[P]

Gerry also states that it’s ok to have no assurance for “low-value transactions”. This seems like a very strange statement to me. Whether you are a blog or a bank, you still want to have confidence that the the card and the data in it is correctly associated with the right account. Perhaps the bank cares more about the veracity of additional claims — but in my mind, any additional level of confidence in quality of data must first be based on a foundation of accurate identification.

Such thoughts led me to ask & try to answer the following question: Should an RP feel more confident in receiving a managed card from a user compared to a self-issued card?

For the purposes of token validation, the only thing I as an RP get in a managed card that I don’t get in a self-issued card (that I can think of anyway) is a certificate that is chained to a “trusted root certification authority”. This, of course, only gives me more actual assurance if I go to the trouble of verifying that the cert does indeed chain properly, and that it hasn’t been revoked.

As far as data veracity goes — well that has nothing whatsoever to do with the card format. It just as equally easy and possible to lie through a managed card as it is to lie through a self-issued card. The format guarantees nothing. Trusting a managed card because it is a managed card over a self-issued card is the equivalent of trusting hearsay over perjury.

A card issuer that simply parrots back what a user types into it will have certain uses, regardless of the issuing mechanism. A card issuer that adds value to what the user supplies will gain over time a different kind of reputation, and therefore will inspire a different level of confidence in both users and relying parties. Mistakes, abuse, quality of user experience, extra features – all of these things will play into trust decisions for transactions of all kinds, and of all values.  Dividing things into low-value vs. high-value classifications seem like a good way to divide things – but not with respect to identification mechanism. Think of the gmail user who becomes a Google payment user. A relying party in a high-value payment transaction involving a Google user still has to depend on the same identification mechanism used for a low-value google mail transaction. The foundations are the same – it has to work and it has to have some kind of assurance attached, for relying parties and users too.

Those Gen-Y girls get to have all the fun…

We don’t live container lives, with work and family and play muffled under air-tight lids. Our life bleeds together, and instead of a singular goal of family or career, we lead our lives as a continuum, family and career ebbing and flowing.

…

Generation Y women are high-achievers, shrewd, well-dressed and sexy, while possessing an emotional intelligence that far surpasses our male counterparts. We don’t rule by insecurities or fear, but by knowing ourselves well, and seeking connection with others. We combine “physical potency with seriousness of purpose.”

This won’t really surprise many of you, but I love the optimism of this article. I love the fact that the text has nothing to do with guilt or disenfranchisement — it is all about having and making choices that enable the future generation of women as people who can live life in whatever way makes them the most fulfilled.

I also find the term “compassionate alpha” quite interesting, I can think of a few examples of this phenomenon — but to me, such a term is not and should not be gender-associated.

Check out the original link, and tell me your view…

There have been some very significant developments in the Information Card arena in the last little while — have you noticed?

• MS has support in their next-gen CardSpace client for non-SSL Information Card transactions
  • This completely removes the financial barrier to entry for this technology, by removing both the cost of a certificate and a static IP address for low-assurance transactions.
  • We now theoretically will have three different assurance levels going, based on three different ssl certificate levels (no certs, regular certs, and HA certs).
• I’m not sure if you’ve all noticed the excellent work that Axel Nennker is doing over at the openInfocard project, but if you haven’t bookmarked his blog Ignis Vulpis, you are missing out on some great technical entries, and documentation of very necessary work.
  • He’s made huge strides with the Firefox Selector (in conjunction with team members like Chuck and Ian)
  • He just updated Kevin Millar’s Firefox plugin
  • He will be participating in person at the Interop in Barcelona
  • Not sure if I can mention how cool and forward-thinking his employer is, but I’m going to anyway :)
• I haven’t really said anything about digitalMe yet – I could say a lot, or just say wow.
  • I love the name. It has everything I ever wanted in a name. It is easily searchable. It is memorable. It is evocative. It is singular. The more I use that term, the more I like using the term. It has the capability of becoming as much of a household name as CardSpace does — a worthy match. I can’t tell you how impressed I am that this name has been put to such a good use, and I can’t tell you how happy I am not to have to talk about a horrible, forgettable acronym with no sex appeal or stickiness when I demonstrate that Information Cards can run on my Mac regardless of which OS I happen to prefer at any given moment. It is a gift horse, and as someone who throws these terms around a lot, I am extremely happy to embrace it and watch it take new life.
  • I love the Macintosh ease of installation. I’d love to just be able to trigger digitalMe from Kevin Millar’s Firefox plugin one day. Kudos to Andy Hodgkinson at Bandit — another name to watch.

What haven’t we seen that I would like to see?

• Agreement on a JavaScript standard for detecting the presence of an Identity Selector
• Cohesive recommendations from OSIS regarding grey areas in the current Infocard protocol specifications (I hope this will come from our Interop work)
• A fix for that damned CardSpace bug where there is no persistence in a user’s choice to send optional claims to a given RP.
• A better way to specify issuers.
• A few other missing things that I intend to rant about soon.

So much work done. So much work to do. It makes my geek-girl heart beat faster, just to think of it all ;)  Ain’t life grand?

It has been a while since I’ve meandered through my thoughts on where the world of the Identity Metasystem is going these days.

A few entries in the blogosphere have examined what this system is not – which is in common use. I can’t deny the truth of such statements. However, what I do see, is a growing number of people who are contacting me, because they are working hard to change this fact.

I can honestly say that I don’t worry about whether Information Cards will succeed. What I worry about, is what happens when it does. To me, this is why it is critical to run interops via OSIS, and not only that, but to create a body of work that anyone can use to understand, test, and create correctly operating components. We are in the lull before the storm.

Have you ever heard the term ‘victims of our own success’? This is what we will be, if the wave of mass adoption comes, and we haven’t made it easy to be a GOOD member of the Identity Metasystem. If we don’t set community consensus on edge cases, abuse cases, some common standards for basic user interface, and other such things now, if we all don’t get busy implementing and learning from our mistakes and fixing them while it is still easy to do so, it is going to be chaos when suddenly the big thing is for every site out there to accept Information Cards.

My view is, that user-centric technology in general is a massive tsunami moving towards the coast. It doesn’t look like much now because the wavelength is long — but once we get close to shore… If I’m right, there will be a sudden, immediate, and critical demand for architects, sys-admins, and developers with experience in this space. The more mistakes we make now and learn from, the less mistakes these future techies will have to make en masse.

… and if I’m wrong about the tsunami — well I guess we’ll all have stories to tell around the campfire…. :)

On Facebook (which I haven’t been checking at all):

“Suddenly, when all your friends have been reduced to teensy avatars, canned quotations, and endless ‘favourites’ lists, they don’t seem quite as special as you may have once remembered them.”

– Phil

On strange things written on pub rafters:

On my pre & post DEC vacation time:

“You’ll have to excuse me, I’m not at my best
I’ve been gone for a month, I’ve been drunk since I left
These so-called vacations will soon be my death
I’m so sick from the drink I need home for a rest.”

– Spirit of the West

On British condiments:

- You have ketchup & brown sauce.

- You have mayonnaise and salad cream

- You have English Mustard and French Mustard

(btw English Mustard tastes differently from French Mustard, but English butter is identical to Irish butter it just happens to be made in a different place. Go figure. )