Higgins 1.0 is out today!  Congrats to all the folks who have worked for a long time to make this happen – and thanks to the companies and individuals who have commited time and $$ because they believe that Higgins make a difference.
Check out Higgins 1.0!
All of the OSIS folks have been debating a method for selectors to advertise their supported capabilities to Relying Parties (perhaps with a selector-selector inbetween).
Axel started us off nicely with a proposed string format, HTTP Header name, and syntax (using + to specify explicit support and – to specify explicit lack of support). His example is listed below:
version='urn:osis:infocard:2008-04'; name='urn:osis:infocard:names:openinfocard'; capabilities='+nossl+javascript-issuerpolicy'
I like Axel’s definition; I’m happy to deal with any format & advertisement method, so to augment this beginning, based on feedback given at an OSIS meeting where a number of people debated this issue, I’m going to propose an initial list of 21 capability identifiers, 16 of which can be rolled up into a bulk identifier called “isip:v1.0” and optionally subtracted from that identifier, and 5 capability identifiers which stand on their own. I’ve based this setup on a few assumptions:
My list is below; I recognize it is nothing more than a starting point. I’ve put it into the OSIS Selector Capability Advertisement Wiki Page under “Proposed Capabilities”, which is open for anyone to read & contribute to. As others act to augment, alter, and strike down bits of my initial list, the wiki page will change to hopefully reflect a list that we all can live with.
Yes, I do think that this technology will have a SKU Paul. It will have a million of them. I believe one day you will buy a cell-phone at Future Shop and the first thing that you will do when you turn that new phone on will be to import all your contacts — and all your information cards. Same idea when you buy your Tivo/PVR – 
the first thing you’ll do is specify what information cards are authorized to view content. Same idea with your wireless router. Same idea for your set-top box, and for your video game console. That is my personal vision for information cards. They will be commodotized, integrated, a taken-for-granted part of our daily lives. They will be futureshopped — or they will be forgotten.
But that wasn’t really your point, was it Paul?
Your actual point corresponds with one of my major takeaways from this month’s IIW conference: 
we have critical problems with our ontology (or lack thereof)- and for several reasons. There appear to be serious misunderstandings about which terms Microsoft has trademarked and which ones they haven’t. There are also some very literal minded folks who just can’t handle the use of a semantically loaded but generic term as a proper noun. And then there are the people like me; I’ve been using the term ‘Identity Metasystem’ as a synonym to the stack of protocols described by the Identity Selector Interoperability Profile (ISIP) v1.0 — while at the same time using it to describe all information card systems. I realize now that I need separate names to describe the visual metaphor, the technical paradigm, and the specific protocol stack for which I write software.
Seems to me that if our community can’t describe what information cards are or what they do, in simple terms that nobody argues about, we certainly aren’t going to get anywhere close to daily use by millions of people. This is a starting-gate hurdle. So where is the sweet spot of terminology that will let us move forward?
I’d say I don’t care what the names are as long as they are consistent, but of course I do care. Quite a lot really. Here are the things that I perceive to be useful during this debate:
1) There are two and only two terms that I am positive cannot be used generically: they are “CardSpace” and “digitalMe”. To my knowledge, these terms are trademarked, copyrighted, and backed by bloodthirsty lawyers. Calling the whole system ‘the CardSpace system’ is a no-go. Period. I can’t see why anybody would want that in any case – and yet I’ve heard it proposed.
2) Shortening the “Identity Selector Interoperability Profile 1.0” to ISIP 1.0 is very very useful. It is probably the least contentious way to describe today’s prevalent information card system. Calling it MS ISIP 1.0 seems to me to just be adding more letters to an already clear acronym but hey – fill your boots. Calling it MS ISIP ™ is just silly, imo.
3) Using the terms p-cards and m-cards to describe the two types of ISIP cards currently out there makes no sense to me, since in my vocabulary, personal and managed mean very simple things: personal means you make the card yourself, and managed means somebody else makes the card for you. As such, I believe there will be personal and managed s-cards, personal and managed r-cards, and so-on.
4) I’m tired of the metasystem debate. I find it divisive and pointless. To me, it’s like not being able to accept the term “the Internet” because you are morally and ethically opposed to the fishing metaphor. I’m happy to let the term die, in the idealistic hope that we never ever have to play semantic table-tennis with the word meta again.
Instead, how about I tell you all a new story, containing some different words that might make everybody happy?
Once upon a time, there was a metaphor called information cards. In the same way that web pages are manipulated with a browser, information cards are manipulated with a selector. Information cards can be cards you create yourself – those cards are called personal cards. Information cards can also be cards that somebody else creates for you – such cards are called managed cards.
Every information card is part of a “cardsystem” – the set of protocols that enable cardsystem-specific components to communicate with each other. The first cardsystem implemented was created by Microsoft and uses the ISIP specification. Other cardsystems include r-cards, where the set of protocols include RSS, and s-cards, where the set of protocols uses SAML but not ISIP. Currently the cardsystems supported by the CardSpace and digitalMe identity selectors are limited to ISIP v1.0, but in the future we expect other cardsystems to mature and become supported among information card components.
Does this work?
This is my response to a current blogosphere conversation on user centricity in the Enterprise, started by Patrick and carried on by myself, Nishant, Johannes, and Matt…
I have a lot of passion about the tools I choose to work with. I believe in working on and with tools that further us as a democratic society. I believe in using tools constructed such that the easiest way to implement are ways that by default tend towards preservation of user privacy, minimization of data retention, and smallest attack surface.
I also, however, believe that the tool has to fit the task at hand. Part of choosing a tool in an Enterprise is deciding whether the tool is capable of adherence to internal policies – this may include privacy controls, platform support, cost, improvement in end-user productivity, regulatory compliance, and so on.
If you take all of the tools out there that have had the ‘user-centric’ tag associated with them, and try to shoehorn any one of them into an Enterprise based on the moniker alone, I will laugh at you, as one IT professional to another. Really, I will. The idea that ‘user-centric’ has to mean anything at all in an Enterprise context, just makes no sense. My advice to Enterprise decision-makers is simple: take the tools and find out if there is a story that those tools can tell that brings value to the organization. If the story is there, adopt the tool. If the story isn’t there, walk away. Whether or not the marketing term applies is, to me, utterly inconsequential.
I can tell you a story for OpenID in the Enterprise. I can tell you a story for the Identity Metasystem in the Enterprise. I can tell you a story about Liberty in the Enterprise. If any of the stories match your goals for your business, fantastic. If they don’t – no problem. There are a large number of stories, but there are infinitely more business scenarios to match them to.
If you try to tell me that using a tool such as the Identity Metasystem to accomplish something other than a user-centric philosophy is wrong, I will also laugh at you. If these tools were built properly, the philosophy should be inherent, not resultant – in other words, you should get user centricity as part and parcel, the kernel of the technology that makes it user-centric shouldn’t be subtractable — but user centricity doesn’t have to be the actual problem that is solved along the way.
I would like to see Enterprises adopt technologies such as the Identity Metasystem for no other reason than because it helps their business to succeed. The fact that as a welcome corollary we lay the plumbing for users to also have greater control in other aspects of their internet life, and for future developers and/or administrators to perhaps begin to be able to architect their applications around a claims-based security architecture, thereby perhaps one day furthering the beliefs I spoke about at the beginning of this entry — well that’s just gravy. I feel it is possible that we can get to a place where such a thing just might work, which gives me faith that maybe we can begin an organic upwards security spiral, with identity at the center and acting as a foundation and inspiration for other areas of this industry.
.NET Framework version 3.5 is now out of beta and in production – this means that the new version of Windows CardSpace is available too.
Based on the v3.5 download page, it looks like .NET v3.5 will co-exist with, not replace .NET v3.0 — so I’m not currently expecting any Windows Update surprises to be coming down the pipe, although I am guessing that .NET 3.5 would be part of Vista SP1 whenever that comes out. If I get more details, I will let you know. My big question is — if the .NET 3.0 version was v1.0 of CardSpace, what do we call this next version? v2.0? v1.1? v3.5? CardSpace TnG? I need something short so I can be simultaneously precise and lazy.
If you hadn’t heard about the new version and wanted to hear about some of the changes that have been made to CardSpace, you should check out the official CardSpace blog.
I hate to be a stickler here — but I still hate all of these generalizations. Sorry Gerry, Paul — I’m not trying to be mean, but my Implementer spidey-sense won’t stop tingling here. I hope I can explain some of my concerns here – and then I think I’ll have to put my money where my mouth is and write something in response that has a bit more meat to it.
If my bank were to one day allow me to associate an information card with my account, I see absolutely no reason why I would hesitate to associate a self-issued information card. If I’m reading Gerry’s taxonomy correctly, in doing so I would be doing my daily banking via a pseudonym-based, no assurance, low-value transaction. If I read Paul’s taxonomy correctly, there would be technical confidence but no legal confidence, even though I as an end user do indeed have a contract with my bank.
Let’s go past an authentication-only scheme and say that my bank will trust everything I assert from my self-issued card. That boils down to contact information — the same stuff that many websites let me change already. I can use a web form, the telephone, probably even a fax machine to do this already, and if I were to change my name on my bank account to “Mindy the Marvelous Mouse”, using any of those methods (including any kind of card), the consequences (legal or not) of doing so would be identical regardless of the actual mechanism I used to make my claims. So – in my mind, legal confidence with respect to fraud on the part of the claim originator should have nothing to do with the delivery mechanism. On the other hand, legal confidence with respect to impersonation of the claim originator may have a very different look and feel. Depending where the blame lies for the impersonation, the RP may not even be able to sue the claim originator, because they may not be at fault or even involved (or their terms of use may disclaim all liability, not sure if that really sticks legally or not). All of this points to the fact that you definitely do want to consider the delivery mechanism when deciding what mechanisms you allow in the first place — but if the system compromise happens at a low enough level, it no longer matters who you trust to say what (theoretically the big difference between self-issued and managed cards), because you can’t even guarantee the who, let alone the what. I don’t see an obvious reason why it would be easier to compromise an Identity Selector than an IdP — either way, there is certainly no reason to malign either card mechanism until proof exists that either one is more vulnerable than the other.
But wait, you say, how about data with real legal teeth? What if my bank allowed me to use my self-issued card to make claims about my own credit score?
Self-issued cards can’t make claims about credit score or SSN number or bank account number. They are incapable – by design. For what they can do, I believe they can do it well. For the rest, they are simply not applicable – which to me is very different from being low in assurance.
In summary, the only situation I can see where use of a self-issued card means a possible legal or technical setback of any kind for an RP (within the normal uses of such a card), is in a case where normal contact data is changed by the user to be fraudulent. I don’t think this case is much of a big deal — because people can do that now, via other channels, and it is a known risk that websites already seem to accept. If there are other cases which I’m missing, please let me know.
I apologize for continually throwing rocks at other people’s glass houses – I realize it’s a lot easier to criticize than to create. As soon as I have a free moment, I’ll try to write out all of what I consider to be valid factors, so that everyone can have a chance to throw rocks at my glass house 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:
- No assurance – self-managed cards, or any managed card where the Issuer is not enforced by the RP
- 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.
There have been some very significant developments in the Information Card arena in the last little while — have you noticed?
What haven’t we seen that I would like to see?
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…. :)
Well alrighty then:
Travel to San Francisco for the Burton Group Catalyst Conference.
Sum Total: A ripping good time!
So. What’s next? How do we keep up this kind of momentum?
I think we demonstrated a vibrant, growing community this week. I can’t wait to see where we go next.