Paul Madsen has submitted the following card set for standardization with the ITU.
Ashish Jain has already asked if the various options will light up according to the policy requirements of the person to whom they are sent.
Paul has assured all those concerned that the preference URLs will be standardized through the UN.
When a user tells CardSpace to “send” identity data from a self-issued card to a web site, it posts a SAML token using the action attribute in the HTML form containing an x-informationCard Object tag.
In the simple, no-ssl case, this information will not be encrypted, so you can just treat it as an XML blob. You can test this out by making the form's action a script like this one:
This script just takes everything that is posted to the web server by CardSpace after processing the invocation form, and reflects it back as an “XML encoding”. The result is shown in my demo, and in the no-ssl zip file as result.xml.
As pedagogical as the XML dump may be, it isn't a good sample of how you would consume claims. For that, let's look at the following script:
GetClaims() shown above is just a way of pulling values out of an XML document – use your own instead. You will see that the givenname and privatepersonalidentifier claims used here are retrieved with this simple code.
I hope all of this will become very clear by watching the demo and looking at the aforementioned zip file, which you can cut and paste for your own experiments.
[Note: the raw XML display code above did not include the stripslashes function when I first posted it, which caused the function to fail in certain php configurations. Thanks to Alex Fung from Hong Kong for the report.]
In an upcoming post called Ultimate Simplicity: 30 lines of code, I show how to tweak a web page so it presents the option of logging in with an information card – without requiring you to dirty your hands with certificates.
If you haven't seen the demo yet, I start from a simple web page like this one:
I add an HTML form like this:
The form has an ID of “ctl00′, and a post action called “dump_input.php”. In other words, when the form is submitted (by clicking on the icon specified in the “img” section) the contents will be posted and the script “dump_input.php” will be run on the web server.
The form contains an x-informationCard object tag, which takes a parameter of “RequiredClaims”. This is followed by the claims the web page designer is asking for – in this case givenname and private personal identifier.
The zip of the sample code is here.
If you copy demo.html to your site, then when using the most recent release of CardSpace, you can navigate to that page, click on the icon, and you will be prompted for an infocard.
The claims supported in CardSpace for simple self-issued cards are defined here – you could cut and past them into the “RequiredClaims” parameter of demo.php to alter the form's behavior.
Paul Madsen at ConnectID writes:
Kim defends CardSpace on the issue of the Display Token.
Personally, I think it's a UI issue. The concern would be mitigated if the identity selector were to simply preface the display token with a caveat:
The following attributes are what the IDP claims to be sending. If you do not trust your IdP, do not click on “Send”.
If the UI doesn't misrepresent the reality of what the DisplayToken is (and isn't), then we're hunky-dory.
And of course, CardSpace is not the only WS-Trust based identity selector in town. The other selectors are presumably under no constraints to deal with DisplayToken in the same way as does CardSpace?
Paul has a good point and I buy the “general idea”. I guess my question would be, should this warning be presented each time an Information Card is used, or just when making the initial decision to depend on a new card?
I think the answer should come from “user studies”: let's find out what approach is more effective. I hear a lot of user interface experts telling us to reduce user communication to what is essential at any specific point in time so that what is communicated is effectively conveyed.
Despite this notion, identity providers should be held accountable for ensuring that the contents of information tokens correspond to the contents of their associated display tokens. This should be mandated in the digital world.
By the way, I love Paul's recollection of the word “Hunky-Dory”. He gives a nice reference. Funny – I always thought it referred to a “certain beverage“.
I recommend an interesting exchange between Citi's Francis Shanahan, Microsoft's Vittorio Bertocci, and University of Wisconsin's Eric Norman. Here's the background. Francis has spent a lot of time recently looking in depth at the way CardSpace uses WS-Trust, and even built a test harness that I will describe in another piece. While doing this he found something he thought was surprising: CardSpace doesn't show the user the actual binary token sent to a relying party – it shows a description crafted by the identity provider to best communicate with the user.
(The behavior of the system on this – and other – points is documented in a paper Mike Jones and I put together quite a while ago called “Design Rationale Behind the Identity Metasystem Architecture“. There is a link to it in the WhitePapers section on my blog.)
Francis has his priorities straight, given the way he sees things:
I'm not sure how to solve this. I'm not sure if it's a fault inherent in the Identity Meta-system or if it's just a fact of life we have to live with.
I would never want to put the elegance of a meta-system design and accommodation of potential future token types ahead of supporting Law #1.
There is no question that elegance of design cannot be pitted against the Laws of Identity without causing the whole design to fail and any purported elegance to evaporate.
So clearly I think that the current design delivers the user control and consent mandated by the First Law of Identity.
Let's start by seeing the constraints from a practical point of view. In an auditing identity provider, one of the main characteristics of the system is that the provider knows the identity of the relying party. Think of the consequences. The identity provider is capable of opening a back channel to any relying party and telling it whatever it wants to. In fact, from a purely technical point of view, the identity provider can just broadcast all the information it knows about you, me and all our activities to the entire world!
We put trust in the identity provider when we provide it with information that we don't want universally known. And more trust is involved when we accept “auditing mode”, in which the identity provider is able to help protect us by seeing the identity of the party we are connecting with (e.g. during a banking transaction).
Should we conclude the existence of scenarios requiring auditing mean the laws aren't “laws”?
“Going back to my original question which was “Does the DisplayToken violate the First Law of Identity?” I am not convinced it does. What I think I am discovering is that the First Law of Identity is not necessarily enforced.
“For me, being Irish Catholic (and riddled with guilt as a result) I take a very hard-line approach when you start talking about “Laws”. For example, I expect the Law of Gravity to be obeyed. I don't view it as a “Recommendation for the Correct Implementation of Gravity”…
The point here is that when the user employs an auditing identity provider, she should understand that's what she is doing.
While we can't then prevent evil, we can detect and punish it. The claims in the token are cryptographically bound to the claims in the display token. The binding is auditable. So policy enforcers can now audit that the human readable claims, and associated information policy, convey the nature of the underlying information transfer.
This auditability means it is possible to determine if identity providers are abiding by the information policies they claim they are employing. This provides a handle for enforcing and regulating the behavior of system participants.
We've spoken so far about “auditing” identity providers. The system also supports “non-auditing” providers, who do not know the identity of the relying party. In this case, a back channel is not possible. The auditing of the accuracy of the display token is still possible however.
There is also an option for going even further, through the use of “minimal disclosure tokens”. In such a system, the user can have an identity provider that she operates, and which submits her claims to a service for validation. In this architecture, the user can really be guaranteed that there are no back channels or identity-provider injected goop.
Again, we are brought to understand that the identity metasystem spans a whole series of requirements, use cases and behaviors. The most important thing is that it support all of them.
I do not want a “non-auditing” bank account. In that context, display tokens bound to information tokens and associated with an information policy all seem fine to me.
On the other hand, when browsing the web and doing many other types of transactions I want to prevent any identity provider from profiling me or obtaining any more information than necessary. Minimal disclosure tokens are the best answer under those circumstances.
The uberpoint: unless we have a system that embraces all these use cases, we break more than the first law. We break the laws of minimal disclosure, necessary parties, identity beacons, polymorphism, human integration and consistent experience. We need a balanced, pragmatic approach that builts transparency, privacy, user control and understanding into the system – integrated with a legal framework for the digital age.
From Wired's THREAT LEVEL, news of an identity provider for girls.
Just today at the CSI Conference in Washington, DC, Robert Richardson was saying he saw signs everywhere that we were “on the cusp of digital identity truly going mainstream”. Could anything be more emblematic of this than the emergence of Barbie as an identity provider? It's really a sign of the times.
From the comments on the Wired site (which are must-reads), it seems Mattel would be a lot better off giving parents control over whitelist settings (Law 1: user control and consent). It would be interesting to review other aspects of the implementation. I guess we should be talking to Mattel about support for “Barbie Cards” and minimal disclosure… I certainly tip my hat to those involved at Mattel for understanding the role identity can play for their customers.
At last, a USB security token for girls!
Pre-teens in Mattels’ free Barbie Girls virtual world can chat with their friends online using a feature called Secret B Chat. But as an ingenious (and presumably profitable) bulwark against internet scum, Mattel only lets girls chat with “Best Friends,” defined as people they know in real life.
That relationship first has to be authenticated by way of the Barbie Girl, a $59.95 MP3 player that looks like a cross between a Bratz doll and a Cue Cat, and was recently rated one of the hottest new toys of the 2008 holiday season.
The idea is, Sally brings her Barbie Girl over to her friend Tiffany's house, and sets it in Tiffany's docking station — which is plugged into a USB port on Tiffany's PC. Mattel's (Windows only) software apparently reads some sort of globally unique identifier embedded in Sally's Barbie Girl, and authenticates Sally as one of Tiffany's Best Friends.
Now when Sally gets home, the two can talk in Secret B Chat. (If Sally's parents can't afford the gadget, then she has no business calling herself Tiffany's best friend.)
It's sort of like an RSA token, but with cute fashion accessories and snap-on hair styles. THREAT LEVEL foresees a wave of Barbie Girl parties in the future, where tweens all meet and authenticate to each other — like a PGP key signing party, but with cupcakes.
Without the device, girls can only chat over Barbie Girls’ standard chat system, which limits them to a menu of greetings, questions and phrases pre-selected by Mattel for their wholesome quality.
In contrast, Secret B Chat lets girls chat with their keyboards — just like a real chat room. But it limits the girl-talk to a white list of approved words. “If you happen to use a word that's not on our list (even if it's not a bad one), it will get blocked,” the service cautioned girls at launch. “But don't worry — we're always adding cool new words!”
By the way, Kevin Poulsen has to get the “High Tech Line of the Year Award” for “a PGP key signing party, but with cupcakes.” Fantastic!
[Thanks to Sid Sidner at ACI for telling me about this one…]
Long Zheng's blog – iStartedSomething.com – is way cool , and though he describes himself as “technophobic”, he has not only understood the meaning of Information Cards – he has applied his obvious talent to tweaking the icon:
A while ago, Microsoft began working on an icon to symbolize Information Cards. The download describes, “this icon is intended to provide a common visual cue that Information Cards can be used to provide information to a site or program, similarly to how the RSS icon is used to indicate the availability of syndicated content.â€
If you don’t know what InfoCards are, these are basically virtual cards containing identification information such as your name which can be sent and received by websites and web services. On Windows, this is implemented via the CardSpace technology. Other platforms have their own implementation but theoretically Information Cards are universal. If you’re on Vista, type “CardSpace†into your start menu, make an InfoCard for yourself and use it on the demo site here.
I think the idea of an icon is great, especially in comparison to the RSS icon which not only serves as a symbol but also a promotional message to attract people to subscribe to content. On top of just indicating a website is ‘InfoCards compatible’, it also spreads the word about InfoCards. However I wasn’t too keen on the design. The purple was unique, but it wasn’t very bright or vivid either. The roundness of the outside border didn’t match the squareness of the inside cutout. But I did like the “iâ€, and how it is shaped like a person.
I had a stab at coming up with my own alternative design. Continue reading Long Zheng tweaks Information Card icon
Here's a story by the Canadian Broadcasting Corporation (CBC) on the British Columbia government's IDM project. Dick Hardt of sxip played the key and even charismatic role in developing a catalytic relationship between industry and government.
British Columbia will test a virtual ID “card” that enables citizens to connect with the government's online services more safely and easily, a top technology official said.
The government plans to begin tests on an “information card” early in the new year, said Ian Bailey, director of application architecture for the province's Office of the Chief Information Officer.
The cards are in the early stages, and “there's going to be some challenges,” Bailey said.
An information card is not a card at all: it's more like a document delivered to users’ computers which they can then use to access government websites.
It's meant to replace the current method of access, which involves logging on to a site with a name and password, and has a digital signature that can't be changed or reproduced, Bailey said.
“It will give us better privacy protection for individuals,” he said.
Among other attributes, Bailey said using an information card means:
- The government won't know which sites the user visits.
- The user is in control of shared information.
- The cards won't have to reveal users’ birthdates or addresses, or a student's school. Instead, it could simply confirm the user is over 19, a B.C. resident or a student.
He compared using the card to using a driver's licence for identification since, in both cases, the government does not know what the citizen is doing. Continue reading B.C. to test virtual digital ID card
If you use OpenID, you are propably running software developed by the gang of “Internet ninjas” at JanRain (yes, I've been there, and they actually do all wear black silk kung “foo” robes). Besides writing software, JanRain runs one of the largest independent OpenID services: MyOpenID.com. Today Jan Rain's Kevin Fox announced they had reached a major milestone:
The JanRain OpenID team is pleased to announce Information Card support has been added to MyOpenID.com
What is an Information Card?
What can I do with it? With a self-issued Information Card you can sign-in to MyOpenID, as well as sign-up and recover your account, without ever having to enter your password. Anywhere on MyOpenID that you can enter a password will now allow you to use an Information Card instead. With the addition of Information Card support MyOpenID is able to offer another solid option for people wanting to protect their OpenID account from phishing attacks and remember fewer passwords.
We were able to work with Microsoft’s Mike Jones and Kim Cameron who have both been long time proponents of OpenID + Information Card support.
As noted by Kim Cameron “Cardspace is used at the identity provider to keep credentials from being stolen. So the best aspects of OpenID are retained.†While one of the less desirable aspects (confusing user experience) has been improved for someone using an Information Card to login to their OpenID provider.
Support for Information Cards has been growing as more software projects implement the technology. It is important to note that this technology is being supported by many other organizations besides Microsoft. Information Card support is available for Windows platforms (Vista / XP) as well as Mac OS X and Linux.
Mike Jones beat me to the punch in heaping well-deserved praise on the Jan Rain group:
The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.
There’s another kind of integration they also did that makes this even more impressive in my mind: connecting their new Information Card support with their existing support for the draft OpenID phishing-resistant authentication specification. This is another significant step in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year. Because of this work, this sequence is now possible:
- A person goes to an OpenID relying party and uses an OpenID from MyOpenID.com.
- The OpenID relying party requests that MyOpenID.com use a phishing-resistant authentication method to sign the user in.
- The person signs into his MyOpenID.com OpenID with an Information Card.
- MyOpenID.com informs the relying party that the user utilized a phishing-resistant authentication method.
This means that MyOpenID users will be able to get both the convenience and anti-phishing benefits of Information Cards at OpenID-enabled sites they visit and those sites can have higher confidence that the user is in control of the OpenID used at the site. That’s truly useful identity convergence if you ask me!
Congratulations to all.
As innovators we need to think about what happens if our systems fail. I've argued, for example, that the starting point for designing a secure system is to recognize it will be breached.
So I took Ben Laurie's recent piece on CardSpace as an invitation to review one more time what can go wrong with Information Cards and CardSpace.
For those who don't know him, Ben has been a leading innovator in terms of open source SSL, and currently works at Google. In his piece he writes that OpenID isn't gaining much traction. Then he turns to CardSpace, which he says “appears to be supported only by Microsoft products.”
A number of people gagged on this, including Dale Olds of Novell (who none the less retained his unflappable charm). Dale had just released his new DigitalMe product providing Information Card support for Mac and Linux. In fact, at Digital ID World, the open source Bandit Project had launched a “Control Your Identity†campaign to promote awareness and use of information card technology. Hmmm. I wonder if Linux is a Microsoft product?
Continue reading What if we fail?
