Let’s Make Some Capabilities!!!

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:

  1. All capability identifiers are written in lower case.
  2. I only ever use the “-” sign for subtraction purposes (ie no “-” sign can exist within a capability identifier).
  3. If duplicates are banned in capability & group identifiers, the capabilities string does not have to be sorted.
  4. As Dale pointed out in our meeting, once we set the definition of the isip:v1.0 group, we have to stick with it, as we have to have an exact set of subtractable elements to develop to.
  5. In the case where an identifier (or its group) is not explicitly listed, it should not be assumed that the identifer doesn’t support the capability.
  6. I have replaced Axel’s “issuerpolicy” capability with the “rpsts” capability; this is because according to this blog post, presence of issuer policy alone is not sufficient to differentiate between a specification of IP/STS and RP/STS (you can specify issuerPolicy if the issuer is an IP/STS, it is just pointless because the endpoint will later be taken from the card itself). Therefore, because issuerpolicy might still signify IP/STS issuer policy and not RP/STS issuer policy, I thought rpsts might be a better choice.
  7. I haven’t added Axel’s “javascript” identifier, because I wasn’t sure how an RP might react differently based on the addition or subtraction of that capability – Axel, please feel free to add it.
  8. The “nocassl” capability is dedicated to RL Bob :)
  9. If I’ve interpreted what should be in the isip:v1.0 identifier correctly, CardSpace v1.0 would have this capability string: “isip:v1.0” and CardSpace .NET 3.5 would have this capability string: “isip:v1.0 +nossl” (unless there are more standalone capability identifiers to add for .NET 3.5).
  10. WS-Trust and WS-SecurityPolicy support capabilities won’t be useful until the self-issued card spec starts to support them, since in the managed card case, the selector just passes that stuff through. As such, perhaps we should leave these identifiers out until they are needed.

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.

Capability List (image)


Futureshopping the Metasystem

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?

Where does Philosophy end and Problem Solving begin?

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.

New version of CardSpace is officially out

.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.

Turkey Hash

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 :)

Turkey Soup

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.

So much going on!

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?

Let’s Talk Turkey

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…. :)

Catalyst 2007, gone by in a flash…

Well alrighty then:

Yes Travel to San Francisco for the Burton Group Catalyst Conference.

Yes See presentations from Jamie, Bob, Mike, Lori, Gerry, Jonathan Schwartz, Jim Harper, and of course Dick.

Yes Learn a whole bunch of new vocabulary, like decisioning and LLP and digital natives.

Yes Have a great time giving my talk (entitled “What I learned when I stopped thinking about information cards and started using them – a Drama in 3 acts”).

Yes Participate in the the long-awaited & highly successful OSIS/Burton Group User-Centric Identity Interop.

Yes Meet all of the great people who have been collaborating via email and conference call for the last several months in person.

Yes Spend large amounts of time in the Hilton sports bar with all my favorite Identity people.

Sum Total: A ripping good time!

So. What’s next? How do we keep up this kind of momentum?

  • we need to collaborate on identity schema and raising the profile of the work to be done in that area.
  • we need to continue to use OSIS to communicate interoperability problems within the community.
  • we need to do the interop thing all over again, but at the next level of sophistication.
  • we need to create a body of knowledge around best practices, industry expectations, and minimum security/validation requirements for Relying Parties.
  • we need to keep enjoying ourselves, this time of day-by-day discovery and learning won’t last forever, eventually the marketing people will get involved and the fun will truly end :)

I think we demonstrated a vibrant, growing community this week. I can’t wait to see where we go next.