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

Pat, Ben, and Kim have been talking about the use of password tokens for use with Windows CardSpace. Pat's detailed description of how this could work is quite useful, and can be extended in some interesting ways:

1. Create a single-use password deployment

If we change the default WS-Sec username/password token to not only include the username and the password needed to login, but also a newly IdP generated second password that replaces the old one on the RP, we would get a single-use password. This might be quite useful for improving the security of the system.

For the rest of this article, I will call such a token "Extended Username/Password token" (EUPT).

2. Creating an account at the RP

One of the issues that Kim has an issue with is that for bootstraping into a CardSpace password manager setup, the user would be required to enter the initial password into a web form. I agree that this *is* bad, but an extended username/password token could help here, too:
When the user does not yet have an account at the RP, he will need to login at a special URL. That URL accepts cards that support EUPTs. When the user creates the account, the RP will accept an EUPT with *any* values. These initial values (username AND password) are randomly generated at the IdP. Upon receipt of the EUPT, the RP stores the username and the initial password and associates it with the newly created account.

--

Time permitting, I will work with Pat to get this done, at least on the IdP side.

tag: Identity, CardSpace, OpenSSO

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

Hubert and Marc have been working on a very interesting subject: using RESTful service for identity. Please take a quick look at Hubert's blog - he is working on a series of articles on this subject.

tag: Identity, REST

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

Another one done. IIW 2007b is over, and - overall - it was quite productive for me.

The biggest takeaway for me is that Concordia and OSIS have made - in my mind - a major step towards harmonization and better coordination. This was reflected in the results of the OSIS steering committee meeting on Wednesday and the following two sessions on Concordia. I am glad that all participants recognized the value of both organizations. As Mike Jones put it, it helps that there is significant overlap in the members.

Other progress was made as well by both groups - the OSIS interop planning session was very fruitful, especially since the planning committee prepared an excellent laundry list document consolidating all test that are in the planning for RSA. I heard great things about the Monday Concordia meeting (which I was unfortunately unable to attend), but also the Use Case session on Wednesday with Paul and Mike was extremely productive.

Finally, the OpenID folks are to be mentioned for making a breakthrough with their 2.0 release, including their IPR regime. I took the Liberty (sic!) to capture the moment that David et al. have been waiting for more than a year:

Overall, the atmosphere seemed a lot mellower, but I can not really follow Dave's conclusions - especially concerning his comments about Concordia and OSIS.

tag: iiw2007b, osis, project concordia

Mike made a very good remark on the OSIS General mailing list that seems relevant to the discussion between Pam, Paul, and myself about assurance in distributed security:

There's a reason that self-issued cards didn't provide any ability to transmit a credit card number or national ID number. The good news is that Identity Providers sending such sensitive information are likely to not be willing to transmit it to relying parties they don't have a business relationship with. Once you're using managed cards for payment rather than typing credit card numbers into web forms, you'll definitely have additional layers of protection working for you. [...]

I fully agree with Mike here: as fas as I understand, Mike is describing the IdP deployment model that Paul and I have been championing over the use of self-asserted cards for sensitive attributes.

tag: assurance, identity, cardspace

Paul found an "periodic" table of data visualizations, which is quite nice in its own right (Paul: I think I have seen a knowledge map of the identity landscape some time ago). But I certainly prefer this "periodic" table of ... beers (hmmm).

tag: humor, beer

... that I will not let anybody break my windows - also, they seem to be a little stronger than the Jones' windows, at least the big one in the spotlight.

In the latest round, Pamela explains how a particular authentication should be considered to have a particular level of assurance. Paul takes the time to address some of the issues Pamela raises, but before we loose track of where we started, I would like to point back to the initial discussion between Pam and Paul:

Paul wrote:

In discussing Cardspace's relaxation of the SSL requirement for RPs, Pam writes

We now theoretically will have three different assurance levels going, based on three different ssl certificate levels (no certs, regular certs, and HA certs).

For there to be 3 Cardspace assurance levels would imply that the LoA is the same for self-asserted and managed cards. Is this the case?

Pam originally thought about three levels of assurance that were bound to the level of the certificates: none, regular, EV^[1]. Paul noted that the level of assurance depends on a number of factors, with technology and deployment architecture only having a small part in this. Paul and I then tried to elaborate in more detail how technical and non-technical factors affect the assurance an user and a RP can place into the transaction.

The reason I started this discussion was that - in my mind - the security certificate used in a particular authentication or authorization transaction is essentially only one reputation factor: by wielding an SSL or EV certificate you demonstrate that a particular company (the CA) thinks that you are who you say you are. This certainly affects assurance, but - by itself - it is rather useless.

The identity provider model (which derives from the mutual trust model in Kerberos) adds a very significant layer to the assurance model: It goes beyond the generic assurance by e.g. a CA by offering information (authentication, attributes) about a particular group of users - the IdP is by far more specific than the CA. Additionally - as Paul points out - a trustworthy IdP is typically a company with deep pockets - someone a RPor an user can sue for damages if something goes wrong. Note that the Windows CardSpace system support such an IdP deployment by using managed cards with Issuer policy. I expect this to be the default deployment for CardSpace, if it gets selected by large organizations.

Self-issued cards or managed cards from any IdP (the OpenID model) do not offer the comfort of sueable deep pockets to the RP. A RP that trusts an authentication that is done by anyone but himself will find himself in a rather dangerous situation: if something goes terribly wrong (e.g. some nasty mal-ware rootkit stole my self-asserted cards along with usage logs and sent them to a criminal for use with my bank) the burden is then on the RP to prove that the authentication token it received did not originate at my Windows CardSpace client, but at the criminal's computer. In an IdP model this burden is with the IdP^[2].

Thus with all respect to Pam's critique, I do have to insist on my original point: the technical factors (like an EV cert or lack thereof) play some role in the level of assurance, but only to establish a baseline. What allows RPs and their customers to truly trust in an identity system are the deployment parameters (including such "mundane" but at least equally important things as e.g. physical security), and - most importantly - the established mechanisms of society for enforcement, arbitration, and liability management.

tag: assurance, cardspace, identity

[1] By the way: the recognition that different types of security certificates might even on influence the assurance you have about a transaction invalidates Ben Laurie's argument that third parties do not add additional assurance.

[2] If I were a cynic, I'd might come up with this argument: Since there is likely a contract between a RP and an IdP, and the IdP has all kinds of lawyers working for them and an interest in precting itself and its users (to a degree), the RP would actually be much better off with self-issued cards: if something breaks, the RP can

• blame the end-user about their lack of security precaution and sue them for negligence,
  
• rest assured that no large number of lawyers will counter-sue them,
• offer the end-user a token of reparations ("We will cover 50% of your losses") and earn tons of goodwill for marketing purposes.
  

Fortunately, I am not a cynic.

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

Paul and Pam seem to think that my stance on assurances and trust is hard-line.

No Assurance vs. Pseudonymity

Paul seems to agree with me to some extend while noting that a concept like self-issued cards can establish a stable pseudonym. I agree with this: both the Windows CardSpace system, as well as OpenID produce in their basic usage scenarios^[1] stable pseudonyms - not more, not less. But this conveys nothing about the identity of the user controlling this pseudonym. It is purely an authentication process that takes place, with no authorization data being exchanged. In fact, all authorization takes place within the RP system, solely based on the pseudonym. I called that the "No assurance" level, which is - a little - harsh, but still fair.

Pseudonymity and Low-Value Transactions

Pam has more issues with my analysis: initially, she finds it strange that "No assurance", pseudonym-only level of assurance is acceptable at all. Again, I might have been somewhat extreme in my wording: when speaking about "No assurance" I was speaking about a situation, where some authentication, but no authorization took place. So you do have (as Paul pointed out) a stable pseudonym, but absolutely no reliable information beyond that. This, I find completely acceptable to what I coined "low-value transactions" like forums, blog commenting, etc.

Trusting an IdP

Now Pam goes on to point out, that an arbitrary managed card provider has - beyond the certificate that confirms the identity of the IdP to only some extend  - no other trustworthiness to them, making them practically as unreliable as a self-issued card.

I agree totally. That is why I insisted in my earlier article that in order to gain any confidence in the token, the RP has really no other choice but to set the sp:IssuedToken/sp:Issuer (3.1.1 [ISIP 07]) to a WSA Endpoint that the RP is willing to trust. This trust is established through non-technical means, e.g through contracts, reputation systems, etc. But without this tying of the authentication to an IdP you have at least some trust in, you cannot have any reasonable level of assurance about your attributes.

The Energy Level Diagram of Assurance

Thus, I also agree with Kim: assurance is not binary - quite the opposite. For reasons of brevity (and laziness 8-)) I only focused on the two major categories of assurance for authenticated session. So here is now a somewhat more complete picture:

Please note that in this picture "No assurance" refers to completely anonymous transactions (no authentication), while the former level of that name is now name "Pseudonymity".

At the end of the day, however, I come back to the same point I made in my earlier post: technology (as long as it is not blatantly broken, i.e. insecure) bears no significant role in establishing trust or assurance. You cannot create a technology that has "built-in" trust - any technology can be deployed in a completely untrustworthy way.

Even a technology-centric system like SSL rests on the trustworthiness of the browser programmers (that put roots in the CA stores) and the CA companies themselves.

tag: identity, assurance, cardspace

[1] Windows CardSpace: self-asserted cards, OpenID: OpenID Auth 1.1 + SimpleReg 1.0

[ISIP 07]   Arun Nanda, "Identity Selector Interoperability Profile V1.0", Microsoft, April 2007

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

This comes through Lauren. I can only fully agree with her recommendation of watching and sharing this clip with anybody that has kids or is concerned about the security of our children.

This is very creepy and shows the high level of immorality of the toy industry. With aggressive data hoarders like this, it seems more urgent than ever to even go beyond an opt-in regime (which we do not - yet - have in the U.S.) and put heavy financial liability burdens on any company holding or handling information about children under 17. Also, I think that consent mechanisms for children must be changed in a way that makes it impossible for children and parents to consent to privacy regimes that can be detrimental to children.

What makes this even more scary is that local governments are obviously not fully aware of the privacy ramifications of these organized privacy violators. For example, the Town of Burlington, MA, offers through its recreation department a class (see here, p. 5) for parents and children to make special "things" for their WebKinz.

tag: identity, privacy, policy, children, ID Theft

Tim Bass responds to my objections to his earlier article on the immaturity of modern identity protocols. He makes the valid point that the maturity of a technology should not be measured by the time it has been available, but by the level of adoption and actual deployment numbers:

"On other other hand, I am measuring “maturity” by actual usage, and the proof of security solutions is in the actual adoption, not simply years of standards activity and vendor marketing." (Tim Bass)

I fully agree with Tim that this is a very important factor in evaluating the maturity of a given technology, probably more important than the technologies availability. In fact, my earlier post was not very clear on this. On the other hand, I do believe that an extended peer review with subsequent revisions does contribute to the maturing of a given technology.

It turns out that SAML and its related technologies (Shibboleth and Liberty) excel in both these requirements for maturity:

1. As I pointed out earlier, SAML (the concepts as well as the technology) has been peer reviewed since 2001 by a number of very different organizations such as OASIS, Liberty Alliance, and Internet 2. This extensive review process resulted in two subsequent versions, that incorporated security fixes and enhancements, as well as new features. It has very broad community and industry support from open source projects, universities, and companies like Microsoft, Oracle, Novell, HP, Sun and many, many others. For more information take a look e.g. at Eve's blog or Scott's presentation.
   
2. SAML has been deployed on a very broad scale. There are a number of not-so-visible financial and telco deployment that are huge, but also the highly visible higher education deployments (see here). In fact, there are few (if any) other web centric identity related technologies that can boast an adoption comparable to SAML.
   

So, at the end of the day, I still maintain that Tim's assessment of SAML as an immature technology is - at least - incomplete.

tag: saml, identity, protocols, cybersecurity, standards

Paul picks up on an article by Pam about level of assurance with Windows CardSpace. He emphasizes the important point that assurance is not only affected by the underlying technology, but also by non-technical parameters like contracts.

I would go one step further and say that LoA is almost exclusively affected by non-technical factors. To be able to put any trust into a given authentication system (let alone an authorization system) you need minimally:

1. A contract between the RP and the IdP
2. A contract between the user and the IdP

Both contracts need to have provisions for the following areas:

1. Data governance (including privacy assurances and data handling)
2. Fault handling
3. Data updates
4. Contract termination
   
5. Liability
   
6. Arbitration and conflict resolution
   

Without such a framework most authentication and all authorization systems are only useful for 'low-value transactions' such as blogging or simple social networking. Or - in other terms - there is no level of assurance, even if the underlying technology supports the most fancy certificates or crypto algorithms.

Obviously, contracts of such kind can only be meaningful and economically viable, if the underlying technology is not broken and has the necessary features to support such provisions^[1].

Now, 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

Only in the later case there can be a reasonable level of trust by the RP that the user is actually who he/she claims to be relative to a given IdP. In that case the contract provisions between the RP and the IdP are in effect and it will depend on them how much trust the RP can put into the authentication and attribute statements.

The Liberty identity system has the necessarily technology and the business and legal frameworks for providing a very high level of assurance, but they are currently not ideally equipped to address the needs of little or no assurance (which typically include fast and extremely easy deployments). Hopefully, openLiberty wil help address these issues.

tag: identity, WCS, Liberty

[1]Thus, any identity system that relies on an universal federation (i.e. any IdP is admissible) cannot provide any meaningful level of assurance.

It seems that history is about to repeat itself: after Liberty formed, a lot of people wither felt left out or did not understand what all this 'identity stuff' was good for. Granted, Liberty was in 2002 about 5 years ahead of the rest of the market. At the time, I thought that this perception problem could be attributed to some abysmally bad marketing - I guess that this was only partially correct.

Today, the same complete lack of understanding is about to hit the "user-centric" identity community as well: Take a look at a post by Brian Huff and compare that with this post from Tim Bass (via James McGovern).

It seems astounding to me that both authors (who claim to be working in 'SOA') have so little understanding of the problems, technologies, and solutions in the identity space. Granted, I am a geek working in this area, but both Tim and Bex claim to be architects and decorate themselves with shiny titles (CTO, CISSP, Oracle ACE Director). They should know better.

Both advocate (in so many words) 'a simpler identity system' (heard that one before) and 'authentication - and that's it'. Both paint existing standards in a very bad light, describing them as 'immature, confusing and less-than-proven  security standards' or asking 'Makes you wonder why people bother to call them "standard," doesn't it?'.

Ok, guys you do not understand identity - get over it and hire someone who does. The good old days where everyone was getting ready for the global directory and its PKI are over. It's not only about authN and authZ in these days, but about the much bigger business and regulatory issue like trust or identity theft.

It seems that the larger identity community (Liberty, InfoCard, OpenID) is about to experience the same pushback that Liberty was facing initially. Let us hope that our joint communication efforts today will help to get over this 'perception gap'.

--

Here are a few comments regarding Brian's post:

1. CardSpace, OpenID, SXIP, (parts of) WS-*
Are not even by the widest possible definition standards, but rather a collection of protocol specifications. Some of these are even proprietary, IPR protected technologies (e.g. SXIP) that are not even covered by a NAC. Also, why are you not including real identity protocols by industry consortia, that are free to implement like e.g. ID-WSF?

2. SPML, XDAS
These OASIS standards have - per se - nothing to do with identity. They *touch* upon identity and security, but are not core to it. Otherwise you should also include HTTP, IMAP, SOAP, and even TCP.

3. LDAP, SAML 2, (parts of) WS-*, XACML
The are (in a wider sense) identity and security related standards. But so are many, many others (Kerberos, X.509, WSPL, XML-Enc, etc.) that you chose to omit. And interestingly enough, most of these standards build on each other or are complementary. So where is the issue?

4. The API issue
There is no unified, standadized API to all these protocols? For starters, only protocol organizations typically create protocols, not APIs (one notable exception is the GSS-API). If you want to create a 'standard' identity API, go to the JCP and suggest a JSR. That organization is probably the body with the biggest amount of standardized APIs, and it is - by most standards - fairly open today. On the other side, if you take the contract-first approach serious, every WSDL or SOAP profile is a reasonable API documentation. In fact this approach allows you select your platform of choice.

Regarding Tim's post:

His list of immature protocols is simply ridiculous: SAML - well established since 2001: go ask the Shib folks, who are running the larger chunk of the academic environment on this protocol. XML Enc and Dsig - yes, there are a few problems (authenticated encryption or key exchange), but none of these problems are insurmountable and have been solved for a long time.

tag: identity, saml

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.

Yesterday, Kim Cameron picked up on a recent article Bob Blakley. The central theme is about Stefan Brands' criticism of OpenID. While Bob sets out to ask the OpenID 2.0 folks some hard questions about what kind of problem they are actually trying to solve, Kim opines that some of the criticism brought forward by Stefan (and Bob) is unfair, since it is out of the scope of what the original intent for OpenID was.

Instead, Kim suggests that there is a spectrum of identity systems which address different needs. Thus, all such systems including SAML 2, WS-Federation and - by extension - the WS-Trust based InfoCard identity system^[1] should answer the questions posed by Bob to OpenID 2.0:

"[Bob] argues that the OpenID specification should include an articulation of the constraints on what it is attempting to achieve.

I agree, with the proviso that other protocols, like SAML 2.0 and WS-Federation, should do the same."

A lofty goal, who could not agree to that: it is most crucial that software architects and designers spend time on defining the boundaries of a given solution. However, prior to limiting and classifying solutions, it would also be neat to actually identify (sic!) the problem/use-case of the solution under examination.

Although I try not to sound like a broken record, I do have to come back to a favorite theme song of mine: Liberty Alliance has done all these nasty and boring use-case evaluations, requirements, and scope definition like privacy and trust evaluations. Interestingly enough, a lot of these often fairly generic assessments is indirectly offered to other identity systems through Project Concordia.

tag: identity, OpenID, Liberty Alliance, meta-system, InfoCard

[1] Kim writes: "Popping up a level, we need a spectrum of solutions to identity problems.  Ergo, the identity metasystem." This is - in my opinion - an obvious example of why the term identity meta-system is very misleading: here it does not necessarily refer to the 'meta'-system defined by the InfoCard architecture, but rather to what I jokingly referred to as the "Aleph 0 Identity System" - a 'true' meta-system of protocols, deployments, etc.
But such a 'true' meta-system is not exclusively a WS-Trust based replacement for HTTP Redirect (WSTBRFHR), like the InfoCard identity system .

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 some Friday humor:

tag: facebook, identity, humor

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

Tatsuo Kudo wrote an article in Japanese on how to configure the OpenID Extension for OpenSSO. As far as I could see (http://tinyurl.com/35gfuh), this is a great article.

tag: openid, sunopenid, opensso

With this article I will try to clean up a little bit of the confusion that I help to create over the past few days. You might want to ask "WHY?" The answer to this is quite obvious: the medium is the message: the content of a message and how it is received depends strongly on the form it is presented in.

This will be my last post on the subject of "meta"-ness. At least for the time being.

It seems to me that there is a fundamental disconnect about what a system differentiates from a meta-system. For myself^[1] (and it seems also for Paul and Robin), a system is a set of rules, protocols, profiles, etc. that are to be implemented. For example, there is a system in place that governs the quality of gasoline and automobile motors, and its standard ways of distribution. This system consists of rules, regulations, engineering practices etc.

From what I gathered in the recent discussion with Bob and Pamela, it seems that they would call these rule-sets a meta-system (please correct me, if I am wrong). If I understand them correctly, the individual gasstations, car manufacturers, refineries, etc. would be called systems.

So far this comparative example held up well, therefore I will be trying to overstrech it now: To me, a meta-system would govern how e.g. different car fuel systems (such as hydrogen, electricity, natural gas) could be made to work together. Examples of this would be creating user devices cars or identity/service providers gas stations that can consume or dispense different types of fuels.

I am not quite sure what the right term for this would be, but the dreaded meta-meta-system certainly comes to mind. That is why I suggested (only half-jokingly) the term aleph 0 system^[2]since it would equalize the different 'starting points'.

---

Now, applying these thoughts to the identity world, I come to the following conclusions:

• Of the three contenders (Liberty, CardSpace, OpenID) for identity systems Liberty was the first identity meta-system.
  
• Concordia will hopefully serve us to arrive at an identity meta-system (better: an aleph 0 identity system).
  
• OSIS has so far tested implementations of identity systems (i.e. identity meta-systems), and will hopefully expand to use cases for identity meta-systems.
  

tag: identity, meta-system, meta-meta system

[1] In this article I will mark the terms system and meta-system either in blue or in orange, depending on whether I use them in my way or with the meaning that Bob and Pam have in mind.

[2] Ok, anybody with a better term?

There seems to be a little confusion over the differences between identity systems and meta identity systems. Some identirati are of the opinion that in order to qualify for the "meta" tag it suffices to support a single family of protocols and multiple token formats, while others are convinced that a "meta" system should also support multiple protocols.

Since this seems confusing to me, I implicitly suggested to call the later an "identity meta-meta-system". Opening this can of worms, you can easily derive at an "identity meta-meta-meta-system" etc. to include other staggering advances in interoperability such as semantics.

To prevent this kind of meta proliferation, I am now convinced that we should define the goal of "getting-these-pesky-identity-thingies-to-work-with-each-other": Aleph₀ Identity System (AIS) [1]. The AIS can - by definition - not be implemented, but describes the elysian state, where all identity systems that would like to be interoperable or interchangeable, are interoperable or interchangeable with all others participating in the Aleph₀ Identity System.

tag: identity, meta-system, meta-meta system, humor

[1] This is motivated by the notion that the cardinality of a countable set (in this case the meta's) is commonly denoted by Aleph 0:

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, l