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“.
OSIS conducted the third in our series of User-Centric Identity Interop events last week at the Burton Group Catalyst conference in Barcelona.
As in San Francisco, the Burton Group hosted and provided support for the event, and in this posting, analyst and cat herder Bob Blakley reports on what was accomplished:
There were a few differences between the Barcelona interop and the earlier event held at Catalyst North America 2007. The most noticeable difference is that the Barcelona interop has been conducted entirely in public. You can visit the Interop wiki to see details of the organization, planning, use cases, and participants; if youâ€™re in a hurry, though, Iâ€™ll summarize here.
Fourteen projects and organizations participated; you can see the list here.
The participants tested 6 identity selectors, 13 identity providers, and 24 relying parties. The Barcelona interop added a significant amount of testing of OpenID interoperability; 6 OpenID providers and 5 OpenID relying parties participated.
The participants have posted their results on the wiki, and a few words are in order about these results. The first thing youâ€™ll notice is that there are a significant number of â€œfailureâ€ and â€œissueâ€ results. This is very good news for two reasons.
The first reason itâ€™s good news is that it means enough new test cases were designed for this interop to uncover new problems. What you donâ€™t see in the matrix is that when testing began, there were even more failures â€“ which means that a lot of the new issues identified during the exercise have already been fixed.
The second reason the â€œfailureâ€ and â€œissueâ€ results are good news is that theyâ€™re outnumbered by the successes. When you consider that the things tested in Barcelona were all identified as problems at the previous interop, youâ€™ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.
Iâ€™d like to call your attention to one more thing. At the Catalyst North America interop in San Francisco, all the interop participants were onsite, sitting in a room together.
Here in Barcelona, as you can see in the Participant Profile table, about half the participants worked remotely. What this means in practical terms is that a lot of the components in this interop were accessed over the Internet, in the same configuration youâ€™d use if you deployed them in your business.
I expect that the results table will continue to evolve for a while as additional information from the event is digested and entered into the wiki; Iâ€™ll probably post another blog entry with some analysis of the significance of the results after the conference is over and Iâ€™ve gotten some sleep. But my preliminary sense is that this interop continued to demonstrate progress toward an open, deployable, interoperable identity metasystem. Continue reading OSIS User-Centric Identity Interop at Catalyst Europe
I'm facinated by this post by Pamela Dingle at Adventures of an Eternal Optimist:
Paul and Gerry have been talking about levels of assurance for self-asserted vs. managed cards, loosely based on my Letâ€™s talk Turkey entry from awhile back. Paul calls Gerryâ€™s stance hard-line; Iâ€™m inclined to agree.
â€¦ as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:
- No assurance – self-managed cards, or any managed card where the Issuer is not enforced by the RP
- Assurance – managed cards where a particular set of Issuer(s) is required by the R[P]
Gerry also states that itâ€™s ok to have no assurance for â€œlow-value transactionsâ€. This seems like a very strange statement to me. Whether you are a blog or a bank, you still want to have confidence that the the card and the data in it is correctly associated with the right account. Perhaps the bank cares more about the veracity of additional claims â€” but in my mind, any additional level of confidence in quality of data must first be based on a foundation of accurate identification.
Such thoughts led me to ask & try to answer the following question: Should an RP feel more confident in receiving a managed card from a user compared to a self-issued card?
For the purposes of token validation, the only thing I as an RP get in a managed card that I donâ€™t get in a self-issued card (that I can think of anyway) is a certificate that is chained to a â€œtrusted root certification authorityâ€. This, of course, only gives me more actual assurance if I go to the trouble of verifying that the cert does indeed chain properly, and that it hasnâ€™t been revoked.
As far as data veracity goes â€” well that has nothing whatsoever to do with the card format. It just as equally easy and possible to lie through a managed card as it is to lie through a self-issued card. The format guarantees nothing. Trusting a managed card because it is a managed card over a self-issued card is the equivalent of trusting hearsay over perjury.
A card issuer that simply parrots back what a user types into it will have certain uses, regardless of the issuing mechanism. A card issuer that adds value to what the user supplies will gain over time a different kind of reputation, and therefore will inspire a different level of confidence in both users and relying parties. Mistakes, abuse, quality of user experience, extra features – all of these things will play into trust decisions for transactions of all kinds, and of all values. Dividing things into low-value vs. high-value classifications seem like a good way to divide things – but not with respect to identification mechanism. Think of the gmail user who becomes a Google payment user. A relying party in a high-value payment transaction involving a Google user still has to depend on the same identification mechanism used for a low-value google mail transaction. The foundations are the same – it has to work and it has to have some kind of assurance attached, for relying parties and users too.
I would put it this way.
- Self-issued cards provide high assurance that the subject possesses the key associated with the card. In other words, the key is itself a claim, and self-issued cards intrinsically offer high assurance of the validity of this claim. This may not sound big, but it's a big deal, since it is the essence of interactive authentication. However, other self-asserted claims require out-of-band verification if certaintly is required.
- Managed cards can provide various degrees of assurance around a broad set of claims. In this case, an out-of-band process is required to establish what claims should be accepted from a given identity provider.
Sorry. As Pam says, assurance isn't binary.
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
Pamela Dingle is the awesome, programming, geek, girl Canadian who runs The Pamela Project. She produced the WordPress InfoCard plugin that I use on my blog. In this piece, she has a different take on Information Card adoption:
“It has been a while since Iâ€™ve meandered through my thoughts on where the world of the Identity Metasystem is going these days.
“A few entries in the blogosphere have examined what this system is not – which is in common use. I canâ€™t deny the truth of such statements. However, what I do see, is a growing number of people who are contacting me, because they are working hard to change this fact.
“I can honestly say that I donâ€™t worry about whether Information Cards will succeed. What I worry about, is what happens when it does. To me, this is why it is critical to run interops via OSIS, and not only that, but to create a body of work that anyone can use to understand, test, and create correctly operating components. We are in the lull before the storm.
“Have you ever heard the term â€˜victims of our own successâ€™? This is what we will be, if the wave of mass adoption comes, and we havenâ€™t made it easy to be a GOOD member of the Identity Metasystem. If we donâ€™t set community consensus on edge cases, abuse cases, some common standards for basic user interface, and other such things now, if we all donâ€™t get busy implementing and learning from our mistakes and fixing them while it is still easy to do so, it is going to be chaos when suddenly the big thing is for every site out there to accept Information Cards.
“My view is, that user-centric technology in general is a massive tsunami moving towards the coast. It doesnâ€™t look like much now because the wavelength is long â€” but once we get close to shoreâ€¦ If Iâ€™m right, there will be a sudden, immediate, and critical demand for architects, sys-admins, and developers with experience in this space. The more mistakes we make now and learn from, the less mistakes these future techies will have to make en masse.
“â€¦ and if Iâ€™m wrong about the tsunami â€” well I guess weâ€™ll all have stories to tell around the campfireâ€¦. “
Continue reading Success brings complexities too
Last week the Electronic Privacy Information Center (EPIC) made an agenda-setting intervention on the newest dangers in digital privacy. EPIC is perhaps the worldâ€™s most influential privacy advocacy group, and presented its brief to a US Senate hearing looking into Googleâ€™s proposed acquisition of Doubleclick.
According to USA Today,
â€œThe Federal Trade Commission is already reviewing whether the Google-DoubleClick combination would violate antitrust law. Consumer groups are pressing the agency to also scrutinize Google's privacy practices. Marc Rotenberg, executive director of the Electronic Privacy Information Center, told the Senate committee that Google should be required to strengthen its privacy practices as a condition of the acquisition.â€
Continue reading EPIC opposes Google / Doubleclick merger
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?
In this video of the Windows Live ID beta (1:20) we use Bandit's DigitalMe to register and log into Hotmail from a Mac. If anyone has been concerned that Information Cards won't scale to handle large sites, they can relax now. To see another version of the demo, this time using CardSpace, watch this (2:20).
You can now use Information Cards at Hotmail and all the other MSN/Windows Live sites.
Just go here to associate an Information Card with your existing account. I found that both Windows CardSpace and the Mac DigitalMe information card selectors worked beautifully with the system. Check out this video to see what it was like registering and logging in from my Mac using DigitalMe.
It's worth taking a step back to think about what can go wrong when you add a feature of this importance to a site with 300 million accounts. If things don't work, you don't have a software bug – you have a trainwreck. So the Windows Live people have done a lot of thinking, planning and testing in order both to create a cool experience and keep from confusing their users.
There are still some anomolies. In the words of the Beta announcement: Continue reading MSN and Windows Live CardSpace Beta