In RC1 (.NET framework 3.0, IE7.0 and/or Vista: for once, we have all nicely aligned) we discontinued the namespace http://schemas.microsoft.com/ws/2005/05/identity, substituted by http://schemas.xmlsoap.org/ws/2005/05/identity. That holds both for the claims in the self issued cards (s-i-c) and for the qname of the issuer associated to s-i-c. If you browse a pre-RC RP site from a RC1 machine, you may experience weird effects. For example, like the Identity Selector claiming that the website is asking for a managed card from the issuer http://schemas.microsoft.com/ws/2005/05/identity/issuer/self no longer recognized as the s-i-c special issuer. Note that often is not a good idea to explicitly ask for a specific issuer
If you want to see a sample of this, check out the updated version of the sandbox.
Why this change? As you may know, relying parties specify the claims they want the identity provider to supply (for example, “lastname” or “givenname”) using URIs.
Everyone will agree that the benefit of this is that the system is very flexible – anyone can make up their own URIs, get relying parties to ask for them, and then supply them through their own identity provider.
But a lot of synergy accrues if we can agree on sets of basic URIs – much like we did with LDAP attribute names and definitions.
Given that a number of players are implementing systems that interoperate with our self-asserted identity provider, it made sense to change the namespace of the claims from microsoft.com to xmlsoap.org. In fact this is an early outcome of our collaboration with the Open Source Identity Selector (OSIS) members. Now that there are a bunch of people who want to support the same set of claims, it makes total sense to move them into a “neutral” namespace.
While this is therefore a “good and proper” refinement, it can pose a problem for people trying out the new software: if you are using an early version of Cardspace with self-issued cards that respond to the “microsoft.com” namespace, it won't match new-fangled claims requested by a web site using the “xmlsoap.org” namespace. And vica versa. Further, the “card illumination” logic from one version won't recognize the claims from the other namespace. Cardspace will think the relying party is looking for specialized claims supplied by a “managed card” provider (e.g. a third party). Thus the confusing message.
After getting some complaints, I fixed this problem at identityblog: now I detect the version of cardspace a client is running and then dynamically request claims in either an old dialect or the new one. I would say people would do well to build this capability into their implementation from day one. My sample code is here.