| Just posted this to a mailing list. OK. I'll have one more go at where I'm coming from because we are agreeing. But I still don't think MS and Liberty/SAML are addressing what I think of as the low end for very wide implementation (of digital identity). In the key early identity functions there are three players. 1) End user (EU) 2) Service provider (SP) 3) Identity provider (IP) End User - These days, the early adopters are all using Firefox and Safari. An IE only strategy is going to alienate these people and you need them on side to drive EU adoption. So that means plain old HTTP, XHTML, Javascript and no ActiveX. Or a different strategy with Browser checking that uses different techniques depending on the browser being used. Service Provider - There is a very large population of potential SPs that are using LAMP based applications such as Movable Type, Wordpress, Drupal, phpBB, OSCommerce, Nuke, etc etc. These could really benefit from a common single signon, and account creation identity system. Either for authentication prior to comments or authentication before joining the community. Or for authentication before buying something. A high proportion of these sites are running on minimal hosting. Which means that we're looking at lowest common denominator technology (today). eg http redirect, http auth, http Get/Post, and scripting language native tools like XML parsing, XML-RPC, SOAP-RPC. And finally toolkits that are written in the native scripting language. Requiring extensions to Apache or PHP probably isn't going to be possible for most of these sites. Identity Provider - IPs have more flexibility because it's reasonable to assume that any commercial IP is going to have complete control over the server. So then we break the market into two. One is in the LAM part of LAMP probably plus Java and C extensions. The other is the MS camp. Now I want to push the system requirements for IPs downwards because ultimately I think there are a large number of the SPs that could and should provide *some* identity function with *some* level of trust. For instance, I can easily imagine a Civicspace site providing identity checking to a Movable Type site when the EU wanted to leave a comment. And there's a somewhat utopian ideal that we can push the IP even further down to personal websites which provide some *more limited* identity function with some *more limited* level of trust. But early on I can understand why the complexity of an IP may mean that we can't or shouldn't attempt to include this. So in a nutshell we have, EUs needing at least IE6 and/or Firefox. SPs need plain vanilla LAMP support as found on cheap web hosting. DPs can require full server control from the owner, but we would like to reduce the system requirements to the same as SPs. This is the market that LID and SXIP (and others) are aimed at. I'm not convinced that Liberty/SAML can address it. And the reasoning is that even if it's possible to implement the underlying design patterns as above, the current implementations all assume more technology than is available at the typical SP level. I'm not convinced that MS InfoCard can address it, because I think it will be too complex to implement at these levels of technology and because MS will feel unable to help due to commercial considerations. |
[ << The end? Or the beginning? ] [ Yet another RSS feed(s) I'd like >> ]
[ 20-Jun-05 8:36am ] [ Identity
] 