| Following Johannes and Doc We should be able to draw out stacks for Infocard using what we know about it so far. SP and IP Infocard SXIP-MIS LID-MIS A.N.Other-MIS MIS WS.* SOAP HTTP End-User MIS WS.* SOAP Browser Extension |- Browser HTTP----| SP = Service Provider IP = Identity Provider MIS= Meta Identity System SXIP-MIS = Future SXIP that uses MIS LID-MIS = Future LID that uses MIS A.N.Other-MIS = Future Liberty/SAML/PingID/whatever on MIS So what does this mean for implementing on non-MS platforms. Well for IP and SP, you'll need at a minimum, a full WS* stack implementation. Then you'll need to reverse engineer the MIS. Then you need to convince the Identity systems who have implmented on top of that to implement on your platform on top of *your* version of the MIS. For the End User, we're going to need the browser to offload to an ActiveX or DLL. And for non-MS operating systems we need to get the browser support extension built in a way that looks the same to the browser. So the big question for me is the extent to which MS help and support people building non-MS implementations. Because without their help I just can't see anyone doing the work. And even on the MS environment I question whether anyone else will build alternate identity systems on top of the MIS. So Kim, the gauntlet is on the floor. Are you going to pick it up? Let's take this line of thinking a bit further. First the End User. Let's assume that the MS implementation of the end user part gets very wide implementation, at least as wide as the dotnet framework. In taht case on an MS OS it's actually quite reasonable to imagine extensions in Firefox, Opera and Safari to get built. We've already got extensions that interact with DLLs and local aplications so it's not so hard to see. On a non-MS OS it's all a little harder but not impossible. On the server side, the critical issue is support for the Service Provider. There's really two approaches here. The first is a native language version. This means that the WS* stack, MIS and Identity service are built in PHP or perl. Given the current state of SOAP support and the difficulty in getting the community to build it, I don't think this is going to happen. The second approach is to have WS*, MIS and Identity service written as an operating system extension or as a web server extension and then to have language extensions that talk to it so that the humble web application programmer can then just make calls in the same way you might use Expat, MySQL or Frontpage. Now we've broken the problem in two. The first part is getting LAM versions of WS*, MIS, Identity service written and deployed. The second part is getting the language extensions written. I'm repeating myself but this is not that different from Passport. And I don't see it happening unless MS puts effort into helping a community to do it. The last part is the Identity Provider as a Server side process. I'd love to see this widely distributed and a whole class of low end IPs (like Typepad) appearing. But I think the barriers to entry are just too high within this environment. If all the SP server side parts get built, then just maybe, people will then do this. But I think all the other parts have to be in place first before anyone will try. |
[ << Microsoft RSS extensions ] [ Notes on RIAA and MPAA Press Conference: Corante >> ]
[ 26-Jun-05 11:17am ] [ Identity
] 