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.
Scotland's eCare has been recognised at an international awards ceremony on good practice in data protection. On Tuesday, 11 December, the Data Protection Agency of the Region of Madrid awarded the eCare framework one of two “special mention” awards. The aim of the annual prize is to expand the awareness of best practices in data protection by government bodies across Europe.
I'm really pleased to see the authors of eCare recognized. They have created a system for sharing health information that concretely embodies the kind of thinking set out in the Laws of Identity.
A Scottish Executive publication describes eCare this way:
The system is designed with a central multi-agency eCare store in a ‘demilitarised’ zone (hanging off NHS net), which links to the multiple back office legacy systems operating locally in the partner agencies. This means that each locality will have its own locally defined and unique approach.
All data shared is subject to consent by the client. The system users are authenticated through their local systems, and are only entitled to view the data of their clients. Clients can change their consent status, and as soon as this is logged on the local system the records cannot be viewed by the partner practitioners.
Benefits that the programme will deliver
The direct benefit to the citizen will be through improved experience of care. Single Shared Assessment, through electronic information sharing, will reduce the volume of questions repeatedly asked by professionals, as data will only have to be collected from the client once, then shared through the technology.
The Children's Services stream will focus on the delivery of an electronic Personal Care Record, an Integrated Children’s Services Record, and a Single Assessment Framework for sharing, to benefit both Scotland’s children, and care practitioners. Across the streams’ care groups, practitioners will save time, because core data will be shared, rather than gathered by multiple agencies. This will reduce the possibility of duplicated or inappropriate care. A more holistic picture of the client will be created, which will help to ensure services that more accurately meet peoples needs.
The principal deliverables of the Learning Disability stream are the development of integrated local service records, which will help planning across a range of services, and the piloting of a national anonymised database, which will enable the Scottish Executive to monitor implementation of ‘The same as you?’ initiative.
Ken Macdonald, Assistant Commissioner (Information Commissioner’s Office, which provided a note of support for the eCare application) has commented:
It is wonderful to see UK expertise in data protection being officially recognised in Europe for the second year running. Recent events have highlighted the need to comply with the principles of the Data Protection Act and I am delighted to see the eCare Framework and the Scottish Government setting such a fine example to others not just in the UK but throughout Europe.
I hope the work is published more broadly. From seeing presentations on the system, it partitions information for safety. It employs encrypted data, not simply network encryption. It favors local administration, and leaves information control close to those responsible for it. It puts information sharing under the control of the data subjects. It consistently enforces “need to know” as well as user consent prior to information release. In fact it strikes me as being everything you would expect from a system built after wide consultation with citizens and thought leaders – as happened in this case. And not surprisingly with such a quality project, it uses innovative new technologies and approaches to achieve its goals.
Axel Nennker from ignisvulpis has been enhancing the openinfocard identity selector – I'm hoping to catch up with him soon and learn more about where the project is headed. Meanwhile this post is very interesting:
At DIDW 2007 I heard Sid Sidner talk about variable claims and how they could be used for online payment. Kim Cameron, who sat next to me during Sid's talk, suggested that I should include this into the openinfocard id selector. Today I uploaded two new applications to xmldap.org. You can use the STS to create a paymentCard and import it into the openinfocard id selector:
Next go to the paymentCard relying party. You can change the price to see that the claim can be changed by the merchant. Type a new price into the input field and press enter. Next click on the paymentCard icon to start the openinfocard id selector:
Select a paymentCard using the openinfocard id selector:
The result looks something like this:
Please note the “trandata?” claim. This is the one that is modifiable by the relying party. It can contain anything. Sid suggested to base64 encode the data needed for 3D-secure. I just use the variable claim to transport price information from the merchant to the STS. The basic principle: If a claim contains a ‘?’ then the matching of the claim against the claims in a information card stops; that is the claim “matches” and the whole claim is send to the STS in the RST. Of course this does not work with the current version of CardSpace. Some newer version of the openinfocard id selector should do it. This functionality is inside it since end of October (I think). I did not find time to blog about this feature earlier. Have fun.
I tried importing the card into CardSpace, but wasn't able to do so since the openinfocard STS currently issues the card using an expired certificate. CardSpace checks for this, and other identity selectors should too. Is this one of the tests in the emerging information card interoperability test suite?
I'll pick this up again once the certificate problem is fixed. Until then, it works very nicely with the openinfocard selector.
At first blush it seems we're looking at a 100 fold increase in teenage cracking power, according to this piece from the BBC News.
Security researcher Nick Breese used a PS3 to crack supposedly strong eight-character passwords in hours.
Typically, previous attempts to crack such passwords took days to get the same result.
Eight-character passwords are used to protect PDF and Zip files as well as those produced by Microsoft Office.
The work to turn the PS3 into a password cracker was carried out by Nick Breese, who works for Auckland-based Security Assessment.
The Cell processor at the heart of the PS3 is the key to speeding up the time it takes to crack a password.
In a presentation given at the Kiwicon security conference in mid-November, Mr Breese said a powerful Intel chip could crank through 10-15 million cycles per second.
The architecture of the Cell processor meant it could speed through 1.4 billion cycles per second. This speed boost was possible because each Cell chip had several processing cores – each one of which could be effectively trying passwords at the same time.
This was important when attempting “brute force” attacks that go through all possible combinations for a password.
Speaking to the Sydney Morning Herald, Mr Breese said although the PS3 could be used to crack eight-character passwords featuring letters and numbers, stronger encryption systems – such as those used to safeguard web transactions – remained safe.
Mr Breese's research comes soon after work by Russian company Elcomsoft to use graphics cards to speed up password cracking.
Hmmm. Security comes from the multiple circles of defense that protect our resources. So this discovery has many implications.
Amongst other things, it reminds us that password encryption just isn't a solution to problems like the one faced recently by Britain's HMRC. You need approaches that are more structural – partition data and use strong auth.
[Thanks to Richard Turner for pointing me to this story. He loves passwords as much as I do.]
Blogger.com now supports OpenID on its beta site. I have to congratulate the blogger.com team on the user experience they've created. This is not necessarily their final kick-at-the-can, but I like what they've done so far.
Blog owners have a simple radio-button selection to determine who can comment:
From then on, when someone visits the blog as a user and wants to make a comment, they are given the choice of how to identify themself. Choose “Any OpenID” and you are given the chance to enter one. Click on that, and you are redirected to your OpenID provider.
Here's what it looked like for me. I wanted to congratulate the team for their great work, so I filled out a comment form like this:
Then I pressed “Publish Your Comment” and got this:
That's because I use myopenid.com, which for me is phishproof because of its great Information Card support (in other words, no password is involved and no credential can be stolen).
That's it folks. I pressed send and got:
Why is this implementation so good? Because it doesn't torment you, doesn't make you set up an account, doesn't make you create a password you don't need, and doesn't nag you to join Blogger when that isn't in the cards. And it puts full control over the kinds of credentials to accept into the hands of the bloggers themselves.
This is the kind of experience I have envisaged and have been waiting for. I think it is a sign of things to come, since many other sites are looking at the same concepts. There is going to be a “conflagration” when people start to “get it”. Just look at the comments. There could be a lot of people who do join Blogger just because they've been handed a carrot, not given the stick.
One last aside on the low-friction thing. Once I've gone through the dance above, I can continue to post at Blogger.com and all other sites with which I've established relationships – without further authentication. That is very powerful.
I've been a Jon Udell fan for so long that I can't even admit to myself just how long it is! So I'll avoid that calculation and just say I'm really delighted to see the CardSpace team get kudos for its long-tail (no-ssl) work in Jon's recent CardSpace for the rest of us:
Hat tip to the CardSpace team for enabling “long tail” use of Information Card technology by lots of folks who are (understandably) daunted by the prospect of installing SSL certificates onto web servers. Kim Cameron’s screencast walks through the scenario in PHP, but anyone who can parse a bit of XML in any language will be able to follow along. The demo shows how to create a simple http: (not https:) web page that invokes an identity selector, and then parses out and reports the attributes sent by the client.
As Kim points out this is advisable only in low-value scenarios where an unencrypted exchange may be deemed acceptable. But when you count blogs, and other kinds of lightweight or ad-hoc services, there are a lot of those scenarios.
Kim adds the following key point:
Students and others who want to see the basic ideas of the Metasystem can therefore get into the game more easily, and upgrade to certificates once they’ve mastered the basics.
Exactly. Understanding the logistics of SSL is unrelated to understanding how identity claims can be represented and exchanged. Separating those concerns is a great way to grow the latter understanding.
I've never been able to put it this well, even though it's just what I was trying to do. Jon really nails it. I guess that's why he's such a good writer while I have to content myself with being an architect.
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.
Here is one of the best comments on digital identity I have ever seen. Francis Shannahan makes it crystal clear how overly fragmented our online identities really are. But he also shows perfectly that it would make no sense to try to compress all aspects of ourselves into a single context. This is exactly the contradiction the Identity Metasystem is intended to resolve.
I love the diagram because it is so concrete – click on it to make it readable. At the same time, it avoids over-simplification. Francis has captured a lot about the yin and yang of identity, and I hope this diagram becomes an emblem for us.
“A few weeks ago I joined Facebook (after much resistence). Facebook sucks you in, making it so easy to give up bits of information about yourself, many times without even realizing it. It occurred to me that I'm leaving pieces of my identity everywhere.
“Last night I took a stab at listing out the various entities that know me, regardless of how they know me. The list is overwhelming. It quickly became apparent that to develop a comprehensive list was not feasible. What I ended up with was a good all around representation. I then generalized it to include things not solely pertaining to me as an individual (e.g. I'm an immigrant, I can never have govt clearance).
“With all the talk of identity and claims federation, this was a good way to step back and at least understand the problem space a little better. I'm sure there are other such diagrams out there but the benefit for me was to go through the process of drawing it rather than take one off the shelf.
“Here's the diagram, it turns out there are bits of us EVERYWHERE!!! Click for a larger view.
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…]
