It took quite a while, but by now it is out. Please welcome the Windows CardSpace Information Card extensions for OpenSSO:

https://opensso.dev.java.net/source/browse/opensso/extensions/authnicip/

When I started working on this last spring, I was not even hoping to see this released in open source and part of the OpenSSO extensions family in less than a year. It took the goodwill and talent of quite a few people to get this off the ground, but with the public release of this code and the upcoming OSIS interop during the RSA onference, OpenSSO is now "speaking ISIP" ...

tag: CardSpace, OpenSSO, InfoCards

This is seriously groundbreaking: Clemens (also here) just finished an example of a Metro client accessing Microsoft's BizTalk Services (aka Internet Service Bus). "Well", you might ask, "what is so groundbreaking about this? Isn't this what this whole web services thingy was supposed to achieve? Interoperability?!"

Yes, indeed. However, this is the first time ever (to my knowledge) that Microsoft is releasing JEE code, built with Metro within NetBeans, as part of an SDK. Getting there took quite a while, and was largely enabled by Sun and Microsoft working very closely together in a series of interop-plugfests. The latest installment of these got (especially) WS-Trust interoperability to a point where you can now use the client implementation in Metro to access the STS provided by the .NET Framework.

Congrats to Clemens, but also the Metro team (namely Jiandong and Harold).

tag: Interoperability, WS-Trust, Metro, BizTalk Services

Eve was kind enough to link to my earlier article on our CardSpace Deep Dive. In that post she mentions our whiteboard notes, that I took at picture of, after all:

Cards based on X.509 authentication are almost working ... there is still a small issue with identifying the right certs based on the thumbprint. Overall, a fairly good result, I'd say

tag: Interoperability, Identity, CardSpace

Not about SCUBA this time: we are right now visting in Redmond so we can test our implementation of a Windows CardSpace compatible IdP against Microsoft's implementation. Eventually, we will (hopefully) make this code available to the OpenSSO community through an OpenSSO Extension.

At the core of the integration, we (Paul, Jiandong,Mrudul, and I) have integrated the Metro/WSIT WS-Trust STS into OpenFM and created a simple cardfactory to produce CRD files (a big thank you to Chuck from here for letting us use some of his Openinfocard code). While we are not quite done as of yet, we have made some very significant progress towards full interoperability while supporting the username/password token, as well as X.509 client authentication.

Overall, this project has already helped quite a bit to improve interoperability between the underlying technologies (i.e. WSIT and the subset of WCF that is being used by CardSpace) and I expect that we will be pretty much done with the core code base in the RSA 2008 time frame.

Many thanks from here go to Mike Jones, Nigel Watling and the entire Microsoft CardSpace team.

tag: CardSpace, OpenSSO, Interoperability, Identity

Here is a small update on available .NET FastInfoset (X.891) libraries:

• Noemax FastInfoset.NET - I have been talking to them from very early on.
  
• Liquid XML Compression - a relatively new (at least to me) implementation that supports .NET 2.0 and the Compact Framework.
  

There is a trial available from both vendors.

If there is still interest in the community, I would be happy to revisit my FIFI code and release it publicly. Please send me a message if this was important to you.

tag: FastInfoset, .NET

Through Nico Williams a real interoperability story:

Alan Wright reports that the Solaris team recently completed the Solaris kernel CIFS service. That's right: CIFS (i.e. Windows networking) is now on par with NFS and other kernel-level system services. To be able to achieve this goal, the Solaris folks had to create some really innovative pieces of technology:

• To allow Windows style SIDs in the process credentials, they are now allowing negative and ephemeral UIDs and GIDs.
  
• ZFS now supports all kinds of DOS attributes and full NTFS ACLs, i.e. ordered ACEs with SIDs.
  

All persistent data (like filesystem records) are dealing with actual SIDs, while non-persistent kernel and memory objects are using the ephemeral negative UIDs. The later are not stable across a reboot, but an ID mapping daemon performs the necessary translation between the SID and its UID.

With this new technology on the horizon, my new home project on a Solaris storage appliance for the basement ("Codename Filer") looks brighter than ever ...

tag: interoperability, cifs, solaris

Paul Trevithick just announced that Higgins will start developing a SAML 2.0 compliant card selector, that will - in addition to Windows CardSpace compatible i-cards - support SAML 2.0 compatible "s-cards"^[1]. This will be quite interesting to follow, in particular if Higgins really supports the SAML 2.0 protocol (not only the token format). In that case it would really step up to be part of the identity meta system (actually: the Aleph 0 Identity System ).

PS: Welcome in the blogosphere, Paul!

tag: saml, identity, higgins, liberty

[1] Paul Madsen made some interesting remarks about that name...

Well, this is over ... and on to the next.

The last week was quite busy since Mrudul Uchil (from the OpenSSO team), Jiandong Guo (from Metro) and I were scrambling to teach OpenSSO to issue InfoCards for Windows CardSpace and respond correctly to WS-Trust STRs. Overall, it went quite ok and this excercise uncovered a few issues that will help us make the product better. The idea is to make this code accessible to the general public as soon as we can - but please bear in mind that we had to make changes to WSIT/Metro and OpenSSO, and some of these are not (yet) considered critical for the products. Nevertheless, I will be working towards a release for the IIW 2007b timeframe, so that we can progress.

Eve posted a couple of thoughts and some nice pictures of the interop session ... go check it out.

tag: identity, interoperability, InfoCard, opensso

Kim writes about the recent Beta announcement^[1] at Windows Live! about them accepting Windows CardSpace InfoCards for authentication. Having gone through rolling out an extensive public new and experimental Identity System deployment myself (Lauren is currently writing about that), I can appreciate the work that Kim and his colleagues are putting in.

In the interest of distilling use cases for Project Concordia and other venues it seems worth pointing out that - in this deployment - Windows CardSpace is being used solely as an authentication system: You can associate any Windows CardSpace card (only PPID is required) with your account - all other attributes are still being handled by the backend systems of Windows Live!. Any additional attributes that your Windows CardSpace card can provide will not be used for authentication or authorization.

This is very much in line with my description of the "glorified HTTP Redirect" use case of Windows CardSpace: here the secure UI on the client can actually help in preventing phishing attacks. The biggest competitor for this use case is OpenID which offers (roughly) the same features, but employs a radically different approach at solving the authentication problem. With PAPE it is somewhat more phishing resistant, but at this point, the CardSpace-based identity systems have - from my perspective - a clear lead in this area over OpenID.

Both authentication technologies face however that same issues: they allow delegation of responsibility for authentication and a rudimentary attribute exchange mechanism. But they do not address the need of service providers to maintain ownership of attributes about their users, except in trivial cases. For these - business driven - issues you need a framework that allows advanced models of federation and account linking and  - most importantly - goes beyond protocols and addresses the non-technical aspects of identity management as well.

I think it will be quite interesting which authentication technology (OpenID and Windows CardSpace) will get how much market space. OpenID has a head start as far as IdPs and community acceptance goes, but Windows CardSpace has the backing of Microsoft and - starting with Windows Server 2008 - a REALLY large number of relying parties.

tag: identity, OpenID, WCS, interoperability

[1] The service has been available for some time now.

Just to satisfy myself that the Solaris 10 U4 iSCSI target is working well, I fired up a few file system stress test processes to see if the Solaris machine (and the iSCSI initiator) hold up.

For the test itself, I took an old but reasonably reliable SQL Server hard drive test (can be downloaded e.g. from here). I took the default parameters with medium workload (100MB files), especially since my test drive was a virtual machine on my laptop. Write caching was off. The purpose of this test was not to create a performance evaluation or a real stress test, but much more a proof-of-concept that the two systems would work together.

Here is the final result:

The next step would be a full stress test, preferably with at least 3 or 4 high-powered drivers. That might take some time, though. Meanwhile: happy SAN building.

tag: windows, iSCSI, Solaris

... but it seems that the marketeers at Microsoft are finally getting interoperability: Dino Chiesa blogs about how SCA is an endorsement for WCF. That in itself might be a questionable statement, but he makes a very good point about what makes interoperability a reality:

"The WS-* work the industry has pursued since 1999 shows that we (vendors, customers, developers, pretty much everybody0 recognized that protocols were the sine-qua-non for interop. PROTOCOLS people, not programming models. Protocols, Protocols, Protocols, Protocols, Protocols, Protocols!

And let 1000 flowers bloom! Given a standard protocol, the world can support a myriad of programming models, and they can look like anything they want. As long as each implementation produces the same on-the-wire protocol, they can all intercommunicate. Glory be!"

One is tempted to say: "Finally!" or "Words of wisdom!" or even "Took 'em while, but they finally got there." Yes, Dino: I could not agree more. To enable full interoperability between particular software components running on different machines (and perhaps even operating system - and I mean to go beyond Windows 98, 2000, XP, 2003, Vista, CE, and mobile) you need full protocol disclosure. And just to clarify: this would mean syntax and semantics of all network communications between two systems that are meant to be interoperable.

So, if we are talking about OS level interoperability like "samba" or "PC NetLink" (yes, I've been that long at Sun) and "NT-SAM" or "Active Directory", this would also apply, correct? Can we expect a gesture towards the samba community in the near future?

Hoping for a positive answer on this one ...

tag: interoperability, interchangeability, WCF, J2EE

Here is a really nice add-on that got shipped with Solaris 10 update 4 (08/07): starting with this OS release, Solaris supports iSCSI targets. Together with the Microsoft iSCSI initiator for 2000/XP/2003, this allows building a very comprehensive and compelling SAN (Storage Area Network). Here is a screenshot:

Now, in order to get this to work, you need to do the following things:

1. Install Solaris 10 08/07 (update 4)

2. Install Windows and the Microsoft iSCSI initiator 2.05 build 3392

3. Follows these guidelines to configure a target

4. Read up on the MS initiator on how to discover and mount an iSCSI target

Overall, this procedure is not very difficult and you will have a system running within a few minutes. 

Please note that I did not (yet) test CHAP authentication or Vista compatibility, but - given some time - I will try this later.

tag: windows, iSCSI, Solaris

There has been quite a bit of discussion about SXIP's recent OpenID Infocard token profile: Johnny Bufu, Peter Williams, and I had some email exchanges, Eve commented on Eric's blog, and Dick made some comments about his view on the IPR status.

All this is great, exciting, or anything else you might want to use for describing conditions of euphoria. And I do acknowledge the work that Dick, Johnny, and Mike put into this effort. However, the big questions that are still unanswered (at least for me) is: who cares? And: are we hurting ourselves?

The Bigger Picture

If I take a look at the deployment rate of new-identity-protocol relying parties, i.e. mostly OpenID and Infocard, the picture is rather sobering: there is little activity^[1] and currently also few signs that this might change. One of the interesting results of the recent OpenID project at Sun was that successful web property owners have little or no interest in outsourcing their identity system, or even only the authentication part of it (which is the only established role of OpenID or Infocards at this time).

The same kind of behavior can also be seen on a larger scale where the big application and service providers like Google, Facebook, or Yahoo! have little or no real interest in a truly federated/distributed internet-wide identity system, since it is not compatible with their respective business models^[2].

So overall, it seems safe to assume that any effort directed at convincing web property owners to adopt a particular identity system is an uphill battle. Especially, if they have to invest time and money into equipping their web server with a compatible relying party.

OpenID Tokens, Anyone?

Now, what would be required to use the OpenID Infocard token profile? In addition to the entire OpenID infrastructure (OpenID Auth 2.0 et al.), you would also need a - more or less - complete Infocard infrastructure. In addition, you would need to make sure that the respective parts are tightly synchronized ^[3].

In addition, none of the OpenID specifications have passed extensive peer review in an open standards process, have IPR issues plastered all over them, and are - pretty much - all in beta (or pre-alpha) at this time.While these issues have been discussed in the past, it still seems reasonable to point out in this context.

Rolling out a complete and fully supported Infocard infrastructure is somewhat easier, since Microsoft is providing de facto reference implementations for the card selector and the relying party. Also, the IPR situation is less confusing, since the OSP covers - as far as I can see at this time - a pretty large chunk of the complete Infocard identity system.

Who cares now?

For a potential deployer, the question is now: "If I have an (almost) shrink-wrap identity called Windows CardSpace, why should I start to dabble with the deployment and replace the built-in SAML tokens with OpenID tokens?" Besides the technical difficulties, there is also the issue that an OpenID token based Infocard deployment only allow what is called "auditing mode". Add to that, that most clients will probaby not have Infocards with the OpenID tokens installed, my initial questions come up again: who cares? And: are we hurting ourselves?

Most end-users do not care at all. In an Infocard-world, they just want to use the Windows CardSpace selector to login. If a given site does not support self-signed cards or a managed card they already have, chances are that they will simply go away.

The relying parties do not care either: most of them want to attract users to their sites. If there is a simple SSO/identity system they can deploy and buy support for, they probably will as long as it fits their business model. Many successful Liberty deployments attest to that. If it involves unreleased or unsupportable technology, potential patent disputes, or simply a lot of additional work, they will likely shy away from such a solution.

There are also no benefits to the IdPs: having to run a combined OpenID/Infocard infrastructure might attribute only to a little administrative overhead, but it does not really add a lot of additional benefits either.

Are We Hurting Ourselves?

My answer to this would be a decisive: "yes". While the OpenID Infocard token replaces the HTTP redirect with the much more phishing resistant Infocard scheme, it will lead to some significant confusion in the marketplace. Educating customers and end-users might help to some extent, but explaining the differences between auditing and non-auditing mode is going to be very difficult. This is why Kim is rather careful about not advocating it: it breaks his own 7 laws.

At the end of the day, relying parties will have to decide what they want to do - and it seems to me that the decision for or against a particular identity system (such as Liberty, Infocard, or OpenID) will not be based on tokens, but rather on the entire package, including vendor support, reachable customers, and overall acceptance.

tag: identity, OpenID, Liberty Alliance, SSO, InfoCard

[1] Especially when comparing this with the rate of IdP rollouts for these protocols.

[2] In fact, I would argue that the interoperability debates of the 90s - WindowsNT/Active Directory, eDirectory, LDAP, etc. - were focused on the same issue of identity. At that time, it was the software suppliers fighting over identity WITHIN the enterprise, since control over the user database was the key to influence a lot of strategic decisions.

[3] To be fair, this is true for all complex interoperability scenarios.

Just a quick update: OpenSSO is now using the WSIT/Metro STS for WS-Trust protocol transactions. Congratulations to the team (and especially Mrudul) for getting this done!

tag: identity, opensource, opensso, ws-trust

During last week's Project Concordia call, we had an interesting discussion about cross-protocol identity use cases and scenarios. Ashish made a very good observation during this call: many times when we are discussing identity protocol transitions or cross-protocol use cases, we are not so much dealing with protocol interoperability, but rather with a protocol mashup.

Proper interoperability - in this definition - requires the ability to interpret foreign protocols and have full access to the semantical content. I have sometime referred to this level of interoperability as interchangeability. An example of such high level of interoperability would be the ability to extract authorization data from a Microsoft Kerberos ticket and use the NT-PAC data to create a SAML attribute statement.

A protocol mashup on the other hand would only require very limited knowledge about the semantics of another protocol, but instead it simply profiles the use of one protocol (or in this case: identity system) with another. A simple example would be the use of self-signed InfoCards to authenticate to an OpenID Provider.

tag: interoperability, identity, Liberty Alliance, OpenID, InfoCard

Both Paul and Robin beat me to this ...

The recently published report by Burton's Bob Blakley summarizes the result of an interoperability testing fest at the Burton Catalyst conference earlier this year. This venue was a great success for the Windows CardSpace identity system, since it was the second OSIS event where a variety of open source projects and closed source commercial products demonstrated a significant level of interoperability. Given the early and evolving state of the InfoCard system, this is a great success for all parties involved.

However, Bob is somewhat mistaken in parts of his article:

"The interop participants accomplished in two months of concentrated effort what it would probably have taken them a year to do working independently without the looming deadline provided by the Catalyst demo."

This is not quite correct - the Catalyst interop fest was the second such event organized by OSIS. The first one was held earlier at the Internet Identity Workshop 2007. Results and blog reports on this can be found all over. Having been a member of OSIS for some time now, I find it a little unfair that this interesting (un)organization - that certainly had its ups and downs - is not given the credit it deserves.

"While it is still fair to say that user-centric identity technology is in its infancy, if progress continues at this rate the technology should be ready for enterprise adoption within a year."

I am surprised to see such a bold statement, especially since even some of the core developers and architects not quite happy with the term "user-centric identity". Let's just step back and start to count how many glossaries, lexicons, and lists-of-used-terms define digital identity, identity system, user, and user-centric in different ways with sometimes completely different semantics. Predicting enterprise adoption within a year seems a little overly optimistic to me, especially if we consider that there are still a number of significant issues even within the reference implementation of the InfoCard identity system.

As Mark Wahl has pointed out earlier, most of the issues encountered during the second OSIS interoperability fest are related to the lack of proper schema management for attributes and their semantics [1]. The only project in the Infocard system currently working on these issues is Higgins, with their use of OWL (although some people might argue that this is technological overkill).

Outside of the InfoCard system, there have been other efforts to get to at least some standardization of attribute interpretation (SAML attribute profiles, which work nicely with LDAP/X.500 and XACML and other likely sources) and work is being taken up by Liberty to standardize identity attribute sharing rules (e.g. the IGF/IDG work, based on CARML/AAPML).

At the end of the day (closing the loop and coming back to Paul's and Robin's point): Even though there have been a number of different products and projects that successfully worked together, this technology is a far cry from being an identity meta-system. Multiple-protocol interop on the wire would be a true metasystem, and is a goal that various systems -- Liberty, OpenID, and Windows CardSpace included -- would need to work on together. Concordia is (probably more than) a first step towards this goal.

tag: identity, IIW2007, interoperability, InfoCard, WCS
 
[1] Obviously a lesson well learned through the LDAP and - even worse - LDUP discussions.

Today, we (pre)-announced at the IIW 2007 a non-assertion covenant (NAC) for OpenID. What does this mean?

First, the NAC is a short (three paragraphs) legally binding document that licenses all of Sun's patents (and not only necessary claims) to anybody for the purpose of implementing OpenID 1.1 Auth and Simple Reg 1.0 ... in perpetuity ... royalty-free. This license will only be withdrawn, if someone decides to sue Sun over this technology.As far as I know, this is the first covenant like this around OpenID.

Sun has issued already some of these - one on ODF and another one on SAML. Everytime, this prompted similar licenses and promises from other companies. Note that this move is so far totally unilateral - we (Sun) clear the way for the OpenID community as much as we can. Now it is up to other companies to do the same thing and show their commitment to the open source community.

The official announcement of this NAC will appear soon on the "On the Record" marketing blog at blogs.sun.com.

Finally, here is a picture by David showing Eve, Bill and myself making the announcement:

tag: OpenID, sunopenid, IIW2007, opensource

Marina Fisher and I will be presenting on AJAX interoperability here at JavaOne on Thursday at 5:30pm in Esplanade 302. We will be covering jMaki, WCF, Silverlight/ASP.NET AJAX and Java REST API interoperability. For more details, go here. 

tag: AJAX, jMaki, Silverlight, Interoperability

Here is a nice short article by Scott Hanselman on what is currently happening in .NET land - especially at MIX07. I find his graphic on the evolution of the various .NET technologies quite interesting and helpful. A couple of interesting take aways and comments:

- Silverlight 1.1 alpha, along with the "CoreCLR" will be interesting to disect. According to Scott, there is nothing "micro or tiny" about this runtime, only sane refactoring. That might be so, but the Base Class Library amounts to somthing of a Micro/Mobile edition ...?!

- The Dynamic Language Runtime is interesting - but I am not quite so optimistic to believe that the Microsoft Permissve License will really win the "hearts and minds" of the hardcore open source community...

- The JavaScript/CLR (in process?) integration sound *really* interesting.

Ultimately, the success of Silverlight and the CoreCLR program will probably depends on platform support. And as Sun has learned very painfully, sufficent platform support can only be achieved with truely open source software.

The next two weeks (three weeks really) are going to be interesting: first I will present at JavaOne on AJAX interop, together with Marina Fisher. This JavaOne should get really exciting for a whole number of reasons, especially for the open source identity community ... stay tuned.

After that, Phil is inviting again to IIW 2007 which will certainly be interesting and entertaining. I promise to post frequent updates on what is going on there, as well.

tag: iiw2007, javaone, Identity, Open Source

This morning (PST), Roger Sullivan announced Lberty's new project called openLiberty.org. This community oriented website aims at providing developers and architects with open source implementations of Liberty's suite of identity protocols. I am really looking forward to seeing a lot of dicussion happening there.

tag: Liberty Alliance, Identity, Open Source

Now - here is something quite interesting about Java directions: I was only remotely aware of JSR 277 - Java Modules - and took really no big interest in it. However, this effort might solve some of the self-inflicted problems that I had to deal with regarding OSGi bundles.

JSR 277 (which is currently in early draft) aims at provinding a simple class versioning mechanism that allows some of the features of OSGi bundles. Stanley Ho has written some explanatory material on this JSR - from what I could gather, it should be - at least principally - not too hard for OSGi to deal with Java Modules. Now if we only could get it working the other way round ...

tag: JSR 277, OSGi

WS-Federation 1.1 is out... and skipping through the TOC, I have this strange feeling of deja vu.

James McGovern asks whether federated identity might require (at least sometimes) federated authorization. I think this is a pretty good question and one that is not easy to answer. My initial take on this would be that federated identity should not require federated authorization, assuming that I understand correctly what federated authorization really is.

For simplicity's sake, let identity be just a bag full of attributes (e.g. e-mail address, names, phone number, etc.). An indentity provider is then nothing more than a service that asserts that certain attributes have a particular value for a given digital identity. A relying party (i.e. a service provider like e.g. AmazingBookStore) can choose to trust such an assertion - either in full, or just certain parts of it. At the end of the day, the relying party will have to determine the level of access based on the type of assertion and the content of the "attribute bag". As such, in this case authorization is local.

If authorization is to be delegated to another point (as in e.g. the XACML model), the relying party forwards it to a policy decision point, where the contained attribute information and additional attributes the PDP might obtain are evaluated according to a set of policies.

Now what is federated authorization? If I understand it correctly, it would be a scenario where you trust access level decisions to your resources to a third party (e.g. you would let YahaPortals.COM decide whether or not a user can get access to data you own). I am tempted to say that the risk that YahaPortals has about a false negative or false positive decision is quite substantial, particularly in our age of increased liability.

While there might be some use cases that do (or will) require such a model, I would argue that XACML provides a pretty substantial technology base for a federated authorization system, should the need arise. Some additional elements for such a system (e.g. trust establishment, crypto, etc.) could be either profiled or application specific.

UPDATE: As usual (at least in the last couple of weeks), I am quite behind things. James apparendly commented on quite a few blogs (hmm, was that related to IIW tagging ... noooo, can't be) and got some pretty substantial answers from Pat, Conor, and Paul.

Today I sent a mail to OSIS-General on using OpenSSO for the Identity System/Selector that we are trying to build:

We at Sun would like to offer/suggest OpenSSO (
http://opensso.dev.java.net/) as a open source project within the OSIS
framework. I believe OSIS could benefit from the technologies that are
either already implemented within OpenSSO or 'very soon to be released',
including SAML 1.x, SAML 2.0, ID-* etc. For additional information on
OpenSSO, please take a look at Pat Paterson's blog at: 
http://blogs.sun.com/superpat/entry/recently_asked_questions_on_opensso
and 
http://blogs.sun.com/superpat/entry/first_multi_protocol_federated_ident
ity. 

Given the existing large code base of OpenSSO (and still growing), we should be a significant step ahead in the goal of creating a OSIS. 

Here is my mail to Mike Jones on the OSP:

Hello Mike - 

First of all this is most excellent news - and I am looking forward to
seeing those protocols being implemented by a large number of market
participants. 

However, I do have a few questions that you might be able to clarify: 

1. For the purposes of OSIS, there are some components in the WCS that
do no seem to be covered, in particular the InfoCard specifications,
including schema and the visual components for the card selector UI.
Will this be covered by a separate covenant?

2. Also, the language of the OSP mentions that only Necessary Claims,
i.e. those REQUIRED in the specs are covered. What about OPTIONAL, etc.
portions of the specs?

Thanks a lot, 

Gerald Beuchelt 

At this point I would like to thank Mike and also Kim for their work on getting the WS-* protocolsl into the OSP and - hopefully - all the other specifications that will follow

Microsoft today announced their "Open Specifications Promise", essentially a non-assertion covenant for a huge chunk of WS-* protocols. This OSP means (as fas as I can tell - and I am NOT a lawyer ) that people can start implementing WS-* specifications without having to fear any action from Microsoft, as long as they do not sue Microsoft over these specs - duh!

This is quite good news for a number of reasons:

1. All existing implementations of WS-* technology are safe from any legal harassment from Microsoft. Not that they would do this necessarily, but this covenant gives peace of mind.
   
2. Since pretty much all security specs are out, OSIS and Higgins are now in a much better position to implement a WCS compatible InfoCard selector.
3. The best thing about this is the fundamental mindshift at Microsoft. A couple of years ago this would have been unthinkable. Now it is real. This is really major change in the way Microsoft deals with the open source community. It can be hoped that this OSP is just the beginning of a much more open discussion with Microsoft.
   

Here are the architectural overview pages for Project Higgins and Project Bandit:

Higgins

Overview: http://spwiki.editme.com/HigginsIntroduction

Presentation: http://spwiki.editme.com/HigginsOverview2

Bandit

Architecture: http://www.bandit-project.org/index.php/Architecture_and_Design

Roadmap: http://www.bandit-project.org/index.php/Roadmap

As you might know, Sun is shutting down their operations during the 4th of July week, so my bloggin will be fairly light over the next couple of days. A few thinks that I intend to spend some thoughts on over this break include:

• Is user-centric identity - as implemented by CardSpace - truly useful for interoperable and privacy-encouraging identity? The obvious interoperability limitation is the somewhat artificial restriction of WCS to WS-Trust. But I think there are other problems with WCS as well: will it be "just another box we have to click away"? If identity information about a user can be transmitted with a single click (by releasing an InfoCard), users might get lured into giving away personal information more easily, effectively having a negative impact on privacy. A good example is the AutoFill function of the Google toolbar: since I am using it, I am a lot less careful about giving away PII - when I still had to enter everything by hand, I was always thinking twice about releasing information.

• How can a CardSpace-like model play well with REST/POX web services? The whole question of lightweight identity enabled web services and application is still quite open.

• Will Germany make it to the Finals? THAT question will be answered on July 4.