Category: Privacy

An example of delegation coupons

Even if the true meaning of uber-geek is “incomprehensible”, my last comment on the use of delegation in VRM was a real winner in terms of terseness. I was discussing Whit's notion that he wanted to give Amazon access to his behavior at Netflix, Powell's and lastfm – the goal being to improve Amazon's relationship with him by revealing more about himself as a complete person. So I'll try to unfold my thought process.

If you ponder the possible architectures that could be used, it becomes clear, as usual, that the identity aspects are the hardest. Let's build a little picture of the parties involved. Let's say the user (I know, I should be calling Whit a “customer”), shares his behavior with Amazon and Powell's. Now let's call some subset of his behavior at Powell's “BP“. Whit would like an outcome that would be modelled in the following diagram, assuming for the moment that U->A:BP just represents Amazon asking Powell's for the customer's relevant information.

But how does Powell's know that Whit really wants it to release information to amazon.com but not snooper.com? How does it know that the amazon.com which calls for information is really the same Amazon that Whit was dealing with? Why should Powell's ever take the privacy risk of releasing information to the wrong party? What would its liability be if it were to do so? Can it protect itself from this liability?

When I mentioned delegation, I meant that while the user is “behaving” at Amazon, it gives Amazon a “coupon” that says “User delegates to Amazon the right to see his Behavior at Powell's”. I represent this as U->A:BP, where:

  • U is the user;
  • A is Amazon;
  • P is Powell's; and
  • B is behavior

Amazon can now present this coupon to Powell's, along with cryptographic proof that it is the “A” in the coupon. By retaining this coupon and auditing any release, Powell's can indemnify itself against any accusation that it released information to the wrong party – and better still, actually defend the user's privacy.

‘Breaking up is hard to do.’

I have left two of the most important questions for another time. First, is it really necessary (or advisable) for Powell's to know that the Whit is sharing information with Amazon, rather than “some legitimate party”? Second, how does Whit revoke the permission he has granted to Amazon if he decides the time has come for them to “break up”?

But without even opening those cans of worms, it should be evident that, for reasons of privacy, auditablity and of liability reduction, everyone's interests are served by making sure no service ever acts as an end user. In this example, Amazon continues to act as Amazon, and even if its access is one day anonomized, would would always be identified as “the user's delegate”. The approach constrasts starkly with current approaches – as spooky as they are cooky – in which users release their credentials on “good faith” and eventually, if enough secrets are shared, anyone can be anyone.

Note:   The notation above is my own – please propose a better one if it is just as simple…

Blog posting delegation and third-party auth

LesOrchard at 0xDECAFBAD (…t’s all spinning wheels and self-doubt until the first pot of coffee) expands on the idea of how delegation can be used to improve our blogging experience:

Here’s something I’ve been meaning to post about, brought back to mind from Kim Cameron’s post on “Wrong-headed impersonation”:

I wish that blog posting interfaces (ie. MetaWeblog API and Atom Publishing Protocol) offered a way to delegate blog posting to a 3rd party app (desktop or web) in such a way as to avoid providing one’s login details (i.e. user name and password). For instance, consider both Flickr’s and Upcoming’s 3rd party token-based authentication / authorization schemes.In particular, I’m looking at things like del.icio.us’ own Daily Blog Post and others. These can be used to auto-post content to one’s blog generated elsewhere – but at the price of sharing login details. Granted, you can mostly trust these 3rd parties not to do anything nasty with your credentials, but it would be nice not to have to.

I figure that something RESTful like extending HTTP authentication (ala Atom Authentication) with a token scheme could be interesting, and possibly fit nicely into APP itself. It could probably be retrofit into the MetaWeblog API by specifying a per-app user name and password. I can imagine a WordPress admin plugin that issues approved authentication tokens to restrict the categories and other activities allowed by 3rd party apps.

Just something I’m thinking about, as more services may or may not grow into delegated blog posting.

Identities on multiple devices

As I said here, I want also to look at a second strange claim by Eve: 

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.

But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them…that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal “space.”

This really strikes me as bizarre.  Maybe Eve was asleep while the entire world learned to copy mp3s onto their music players and carry them around?  Duh.  We know how to move files from device to device.  In fact there are probably many hundreds of millions of people who can do it better than either Eve or I can.

The idea that this is the big vulerability of CardSpace boggles my mind.  The whole criticism “Does not compute.”

Then again, I actually use Information Cards, and move them from device to device, so maybe that's why it's so clear to me how easy it is to do. 

Let me share the exact experience I have installing the Information Cards from my PC's CardSpace onto my mobile phone.

 Moving Information Cards from device to device

1)  I open up CardSpace and select Back Up Cards.  This will create a file containing my cards.  I decide to call it “cardset”.

2) I copy ‘cardset’ to my phone and click on it:

3) The phone asks for the password I used to protect my file

 

4) It verifies I'm importing the right cards

5)  And now I have the same cards on my phone device as on my PC.

How hard is that?  It would be the same process copying the file to some other device.  It works fine.  As easy as getting a word document or powerpoint or mp3 from one place to another.  Dongle anyone?  How about email?

Still, the uberpoint is this:  once Information Cards live on my phone, they go whereever I go. 

There are lots of ways phones can potentially talk to other devices.  So who says we have to copy our cards to all our devices once they live in a secure, personal device like a phone that we always have with us?

NOTE:  I want to point out that the mobile implementation of CardSpace I'm showing here is NOT a product.  It's a way of learning about the issues, and collaborating with colleagues in the world of telecom and secure portable devices.  But hey!  It's still a lot of fun.  More later.

Notes on Bill Gates’ Identity Keynote

Many of you know my colleague Mike Jones. He had enough wits about him to take notes on what actually transpired during the keynote earlier today. So I'll share them with you:

The flow of the identity part of the talk went something like this:

  • Slide: Evolution of Identity: Making the Vision Real (with picture of two cards in hands)
  • People are used to choosing what credential to use where for what purpose (talking about cards in our wallets)
  • We use a variety of physical tokens to represent these things
  • CardSpace creates a vehicle to allow people to have a GUI for credentials that represent their identities or personas in particular situations
  • Each thing in the physical world conveys a particular set of information and discloses just enough information
  • CardSpace provides a drag & drop interface for identity
  • People will have to acclimate to it
  • People can create their own credentials and others can give you credentials
  • The system reasons about what the right credential is for you to simplify things for users
  • WS-* hints about what credentials that are being looked for
  • CardSpace shows candidates for credentials

Then they segued to the OpenID collaboration announcement:

  • Issues of reputation and trust are foundational on the Internet
  • Different levels of trust are needed in different contexts, such as blogs and access to enterprise resources
  • People have been thinking about issues of trust
  • OpenID 2.0 is doing this in the blog / Web 2.0 world, others are coming at this from the enterprise space
  • We see these approaches as being complementary
  • “Today we are announcing that we are supporting OpenID 2.0 and that they’re extending what they’ve done to enable the use of strong credentials”
  • They're doing this because they see that it solves problems and attacks that a pure password approach has
  • We're excited about this marriage of CardSpace and Web 2.0
  • This will help eliminate the possibility of man-in-the-middle attacks
  • CardSpace is built on our work on the WS-* specifications
  • OpenID will be endorsing the CardSpace marriage later today
  • We see this as a very smooth continuum with a common GUI metaphor

Numerous enthusiastic comments followed in Mikes rendition…

Bill Gates and Craig Mundie on identity and privacy

Here are some of the top level messages from the Microsoft RSA Conference Keynote press release.  I thought Bill Gates and Craig Mundie spoke extremely well about identity this morning.  In the speech, Bill announced the industry initiative to converge the capabilities of CardSpace and OpenID that we've been discussing here.  This includes support for OpenID in future Microsoft identity products.   

“Security is the fundamental challenge that will determine whether we can successfully create a new generation of connected experiences that enable people to have anywhere access to communications, content and information,” Gates said. “The answer for the industry lies in our ability to design systems and processes that give people and organizations a high degree of confidence that the technology they use will protect their identity, their privacy and their information.”

“To create the level of seamless, pervasive connectivity that will make secure anywhere access a reality, continued collaboration and cooperation across this industry is essential,” Mundie added. “If we can work together to enhance trust, it will open the door to a transformation in the way people share experiences, explore ideas and create opportunities.”

Gates and Mundie said that to further advance trust and enable anywhere access, there are three key technological areas for industry focus and momentum:

    Evolution of networks. As businesses and the industry move forward on redefining network boundaries, policy will become the driving force for managing access — not the physical topology of the network. The goal is for the network and the Internet to appear and work as if the boundaries between them are seamless, so access for users is easier and faster.
    Evolution of protection. To achieve this anywhere access vision, customers need comprehensive security products and services that integrate seamlessly with each other and existing infrastructure and that are easy to use and manage. There is a necessity for the industry to enable greater protection, not only when information is in transit but also when it is created and where it resides, whether on the server, the desktop or a mobile device.
    Evolution of identity. Today, individuals and businesses struggle with an increasing number of digital identities to manage and the increased level of complexity and risk that goes with them. The industry’s collaborative efforts around the development of an identity metasystem are the right direction, and customers need this system to be based on standard protocols that address heterogeneous infrastructures in order to reduce the complexity of managing identities across networks and the Web.

There are a lot more details about many different initiatives here.

 

How to get a branded InfoCard?

A lot of people have asked me, “But how does a user GET a managed Information Card?”  They are referring, if you are new to this discussion, to obtaining the digital equivalent to the cards in your wallet.

I sometimes hum and ha because there are so many ways you can potentially design this user experience.  I explain that technically, the user could just click a button on a web page, for example, to download and install a card.  She might need to enter a one-time password to make sure the card ended up in the hands of the right person.  And so on.

But now that production web sites are being built that accept InfoCards, we should be able to stop arm-waving and study actual screen shots to see what works best.  We'll be able to contrast and compare real user experiences.

Vittorio Bertocci, a colleague who blogs at vibro.net, is one of the people who has thought about this problem a lot.  He has worked with the giant European Etailer, Otto, on a really slick and powerful smart client that solves the problem.  Otto and Vittorio are really on top of their technology.  It's just a day or two after Vista and they have already deployed their first CardSpace application – using branded Otto cards. 

Here's what they've come up with.  I know there are a whole bunch of screen shots, but bear in mind that this is a “registration” process that only occurs once.  I'll hand it over to Vittorio…

The Otto Store is a smartclient which enables users to browse and experience in a rich way a view of Otto's products catalog.  Those functions are available to everyone who downloads and installs the application (it is in German only, but it is very intuitive and a true pleasure for the eye). The client also allows purchase of products directly from the application: this function, however, is available only for Otto customers. For being able to buy, you need to be registered with http://www.otto.de/.

That said: while buying on http://www.otto.de/ implies using username and password, the new smart client uses Otto managed cards. The client offers a seamless provisioning experience, thanks to which Otto customers can obtain and associate to their account an Otto managed card backed by a self issued card of their choice.
Let's get a closer look through the screens sequence.

Above you see the main screen of the application. You can play with it, I'll leave the sequence for adding items in the shopping cart to your playful explorations (hint: once you're chosen what to buy, you can reach the shopping cart area via the icon on the right end.

Above you see the shopping cart screen. You can check out by pressing the button circled in red.

Now we start talking business! On the left you are offered the chance of transfering the shopping cart to the otto.de web store, where you can finalize the purchase in “traditional” way. If you click the circled button on the right, though, you will be able to do go on with the purchase without leaving the smartclient and securing the whole thing via CardSpace. We click this button.

This screen asks you if you already own an Otto card or if you need to get one. I know what you are thinking: can't the app figure that out on its own? The answer is a resounding NO. The card collection is off limit for everybody but the interactive user: the application HAS to ask. Anyway, we don't have one Otto card yet so the question is immaterial. Let's go ahead and get one. We click on the circled button on the left.

This screen explains to the (German-speaking) user what is CardSpace. It also explains what is going to happen in the provisioning process: the user will choose one of his/her personal card, and the client will give back a newly created Otto managed card. We go ahead by clicking the circled button.

Well, that's end of line for non-Otto customers. This screen allows the user to 1) insert credentials (customer number and birthdate) to prove that they are Otto customers and 2) protect the message containing the above information with a self issued card. This is naturally obtained via my beloved WS-Security and seamless WCF-CardSpace integration. Inserting the credentials and pushing the button in the red circle will start the CardSpace experience:

The first thing you get is the “trust dialog” (I think it has a proper name, but I can't recall it right now). Here you can see that Otto has a Verisign EV certificate, which is great. I definitely believe it deserves my trust, so I'm going ahead and chosing to send my card.

 

Here there's my usual card collection. I'm going to send my “Main Card”: let's see which claims the service requires by clicking “Preview”.

Above you can see details about my self issued card. Specifically, we see that the only claim requested is the PPID. That makes sense: the self issued card will be used for generating the Otto managed card so the PPID comes in handy. Furthermore, it makes sense that no demographic info are requested: those have been acquired already, through a different channel. What we are being requested is almost a bare token, the seond authentication factor that will support our use of our future Otto managed card. Let's click “Send” and perform our ws-secure call.

The call was successful: the credentials were recognized, the token associated to self issued card parsed: as a result, the server generated my very own managed card and sent it back to you. Here's there is something to think about: since this is a rich client application, we can give to the user a seamless provisioning experience. I clicked “Send” in the former step, and I find myself in the Import screen without any intermediate step. How? The bits of the managed card (the famous .CRD file) are sent as a result of the WS call: then the rich client can “launch” it, opening the cardspace import experience (remember, there are NO APIs for accessing the card store: everything must be explicitly decided by the interactive user). What really happens is that the cardspace experience closes (when you hit send) and reopens (when they client receives the new card) without any actions required in the middle. If the same process would have happened in a browser application, this would not be achievable. If the card is generated in a web page, the card bits will probably be supplied as a link to a CRD card: when the user follows the link, it will be prompted by the browser for choosing if he/she wants to save the file or open it. It's a simple choice, but it's still a choice.
Back on the matter at hand: I'm all proud with my brand new Otto card, and I certainly click on “Install” without further ado. The screen changes to a view of my card collection, which I will spare you here, with its new citizen. You can close it and get back to the application.

The application senses that we successfully imported the managed card (another thing that would be harder with web applications). The provisioning phase is over, we won;t have to go through this again when we'll come back to the store in the future.
At this point we can click on the circled button and give to our new Otto Card a test drive: that will finally secure the call that will start the checkout process.

Here's we have my new card collection: as expected, the Otto card is the only card I can use here. Let's preview it:

Here's the set of claims in the Otto card: I have no hard time to admit that apart from “Strasse” and “Kundennummer” I have no idea of what those names mean :).
I may click on “Retrieve” and get the values, but at the time of writing there's no display token support yet: nothing to be worried about in term of functionality, you still get the token that will be used for securing the call: click the circled button for making the token available to WCF for securing the call.
Please note: if you are behind a firewall you may experience some difficulties a this point. If you have problems retrieving the token, try the application from home and that should fix it.

That's it! We used our Otto managed card, the backend recognized us and opened the session: from this moment on we can proceed as usual. Please note that we just authenticated, we didn't make any form of payment yet: the necessary information about that will be gathered in the next steps.
Also note that it was enough to choose the Otto managed card for performing the call, we weren't prompted for further authentication: that is because we backed the Otto card with a personal card that is not password protected. The identity selector was able to use the associated personal card directly, but if it would have been password protected the selector would have prompted the user to enter it before using the managed card.

It definitely takes longer to explain it than to make it. In fact, the experience is incredibly smooth (including the card provisioning!).

Kim, here's some energy for fueling the Identity Big Bang. How about that? 🙂

That's great, Vittorio.  I hear it. 

By the way, Vittorio is a really open person so if you have questions or ideas, contact him.

 

Identity Crisis Podcast

Identity Crisis If you haven't read Jim Harper's book, Identity Crisis: How Identification Is Overused and Missunderstood I urge you to do so as soon as you can.

I was initially a bit skeptical about this book because – I hope my more politically inclined friends will forgive me – it was published by what I assume is a political “think tank”.  I worried it might reflect some kind of ideology, rather than being a dispassionate examination of reality.

But in this case I was wrong, wrong, wrong. 

Jim Harper really understands identification.  And he is better than anyone at explaining what identification systems won't do for us – or our institutions. He carefully explains why many of the proposed uses of identification are irrational – delivering results that are quite unrelated to what they are purported to do.  In my view, getting this message out is just as important as explaining what identity will do.  In fact it is a prerequisite for the identity big-bang.  There are two sides to this equation an we need to understand them both.

He directly takes on the myth that if only we knew what peoples’ identifiers were, “we would be safe”.  Metaphorically, he is asking what kind of plane we would rather fly in – one where the passengers’ identifiers have been checked against a database or one where they and their luggage have been screened for explosives and guns? 

I think he will convey to “lay people” why a so-called “blacklist” is one of the weakest forms of protection, showing that all you have to do is impersonate anyone not on it to sneak through the cracks.

The book is full of important discussions.  It has chapters like “Use identification less” and “Use authorization more.”  I have only one criticism of the book.  I would like to see us separate the notion of identity, on the one hand, and individual identification (or identifiers) on the other.  We need return to the original meaning of identity: the fact of being who or what a person or thing is.

As a simple example, suppose I'm a service provider building a chat room for children, and want to limit participation to children who are between 12 and 15.  Let me contrast two ways of doing this. 

In the first, all the children are given an identifier.  To get into the room, they present their identifier and prove they are the person to whom that identifier was given.  Then the chatroom system does a lookup in some public system linking identifier and age to make the access control decision.

In the second, the children are given a “digital claim” that they are of some age, and a way to prove they are the person to whom that “claim” was given.  The chatroom system just queries the claim to see if it meets its criteria.  There is no reference to any public or even private identifier.

My point is that the first mechanism involves use of an identifier.  The second still involves identity – in the sense of being what a person is – but the identification, so rightly put into question by Jim's book, has been put into the trashcan where it belongs.

The use of an identifier in our first example breaks the second Law of Identity (Data Minimization – release no more data than necessary). It breaks the third Law too (Fewest Parties – since it discloses use of information to a central database unnecessary to the transaction).   Finally, it breaks the Fourth Law (using an omnidirectional identifier when none is required).

The book was written before “claims-based thinking” began to gain mindshare, and so it's missing as a category in Jim's discussion of advanced identity technologies.  But we've talked extensively about these issues and we have concluded that we have no theoretical difference – in fact the alignment between his work and the Laws of Identity struck us both as remarkable given that we come at these issues from such different starting points. 

Jim's book is wonderful reading.  It should help newcomers better understand the Laws of Identity.  And this week the Cato Institute in Washington held an event at which Jim spoke, along with James Lewis, Director and Senior Fellow, Technology and Public Policy Program Center for Strategic and International Studies; and Jay Stanley, Public Education Director, Technology and Liberty Project American Civil Liberties Union.

Download the podcast or watch the video here.

 

Resending of personal data with InfoCards

Eric Schultz writes with this question: 

I've been investigating CardSpace and the practicality of it's use for login on a new social networking site.

I have a question regarding the method through which data is transferred. I see that you can require certain claims from an InfoCard such as email, first and last name, zip code etc. When I look at the login code I see that the same claims are required again.

Does this mean that each time an InfoCard is sent all the personal data is resent? Isn't this dangerous for security/privacy? The potential for a server failure (malicious or not) caused by a buffer overflow, a coding mistake that outputs the details of session variables etc. seems rather risky in this scenario.

Perhaps I am being alarmist?

This is an area in which being “an alarmist” – perhaps I will rephrase it as being thoroughly pessimistic about what can go wrong – is the best starting point.  You questions are ones everyone should think about.

InfoCard and Minimal Disclosure

The simple answer is that there is nothing built into InfoCard concepts that requires a “relying party” to ask for attributes every time a user comes to its site.  Let's first look at the mechanics. 

The relying party controls what attributes it asks for by putting an OBJECT tag in the HTML page where the user opts to use an infocard.

The example shown here will bring up the infocard dialog and illuminate any cards that offer all four claims so the user can select one. 

If, next time, the relying party doesn't want to receive these claims, it just doesn't ask for them.  If it has stored them, it should be able to retrieve them when necessary by using  “privatepersonalidentifier” as a handle.  This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.

No theoretical bias 

In other words, the InfoCard system has no theoretical bias about what information should be asked for when.  Through the Laws of Identity we have tried to help people understand that they should only ask for what they need to complete a transaction and should only keep it for the length of time they absolutely must. 

In particular, there should be no hoarding of rainy-day information – information that “might come in handy” some day – but which is more likely to turn into a liability than into a benefit.

Do your risk analysis 

You'll need to do the conventional risk analysis and think about whether it is more dangerous to store the information or just ask for it on an “as-needed” basis and then forget it.  My personal sense is that it is more dangerous to store it than to use an on-demand approach. 

A central machine with the stored information that animates a successful internet business is a honeypot.  It could well be subject to insider attacks, and certainly, since it lives on the internet, will be subject to many attacks on the information it stores.  Why not avoid these problems completely?

Certainly, the on-demand approach has benefits in convincing customers and legal practitioners that, having held no identity information, you cannot be seen as being responsible for an identity meltdown.  To me this is very attractive, and something that has not been possible until now.

Conclusion

The examples Eric gives of things that can go wrong seem to me to apply even more strongly if you have stored information locally than if you ask for it on demand.

But as I said earlier, this just expresses my thinking – there is lots more to be written by Eric and hundreds of others as they develop applications. 

Meanwhile, InfoCard has no built-in assumptions around this and can be used in whatever way is appropriate to a given situation.

 

World's leading identity politician

When it comes to dealing with identity, Australia has already “been there, done that.”  In 1987 there was a massive public revolt against a proposed national ID card that imprinted several of the Laws of Identity on the psyche of the nation.

None the less, the country faces the same challenges around health care and social benefits as every other: the need to streamline benefits processing, reduce fraud, and improve information flow where it is vital to the health and safety of individual citizens.

Over the last few years this had led a whole cohort of Australians to think extensively about how identity, privacy and efficiency can all be served through new paradigms and new technology. 

On its second try, Australia went in a fundamentally different direction than it did with its 1987 proposal (reminiscent of others that have hit the wall of public opinion recently in other countries).  This time, Australia started out right – bringing privacy advocates into the center of the process from day one. 

The cabinet minister responsible for all of this has been Joe Hockey, who seems to have a no-nonsense approach based on putting users in control and minimizing disclosure.

Finally!  Our first glimpse of a government initiative that is, at least in its inception, fully cognisant of the Laws of Identity.  Beyond this, instead of swimming with dull proposals based on Berlin-wall technology,  Australia is leading the way by benefiting from new inventions like smartcards with advanced processors and web services that can together put information ownership in the hands (and wallets) of the individuals concerned.

Here's the story from The West Australian

Police, State governments and banks will not be able to demand access to the new $1.1 billion smartcards under new laws aimed at stopping them becoming de facto national identity cards.

Responding to a report to be released today by Access Card task force chairman Allan Fels, Human Services Minister Joe Hockey will announce changes to ensure individual cardholders have legal ownership over them.

In a speech to be delivered to the National Press Club today he says most government and bank-issued cards remain the property of the issuer but in what may be a world first, the new laws will ensure the cards cannot be demanded for ID purposes.

Professor Fels foreshadowed the legislation in June when he warned consumers needed to be given as much control over the card as possible, and that the Government faced major security concerns if it did not protect cardholders from having to produce the card as identification.

Mr Hockey says the legislation will be introduced next year.

The Government will be able to turn off access to health and welfare benefits if the owner of the card is no longer entitled to them.

The high-tech cards, to be rolled out across Australia from 2008, will replace 17 health and social services cards, including the Medicare card, healthcare cards and veterans’ cards.

They will include a digital photo and name but not the holder’s address and date of birth, and the microchip will store certain health information and emergency contact details.

The Government says it will not be compulsory, but has admitted it will be hard to avoid because it will be required for all government services.

Nearly every Australian will need to carry a smartcard by 2010.

In his speech, Mr Hockey will argue that Australia has been a “complacent comfort zone” when it comes to aspects of card technology and security.

“Many other countries, particularly in Europe, replaced the magnetic strip with a microchip long ago,” he says.

He denies the scheme will result in one giant data base.

“Your information will stay where it presently is, the agency relevant to that information, the agency you deal with,” he says.

The Government hopes the scheme will wipe out $3 billion in welfare fraud a year.

Shadow human services minister Kelvin Thomson said the Government had engaged in precious little public debate about the card.

“Concerns include the threat to privacy from surveillance by corporations and governments, as well as the financial plausibility of a Government-run $1.1 billion IT project,” he said.

“In the United Kingdom, the Blair Government has been forced to put their proposed smartcard on hold due to overwhelming public opposition.”

If Joe Hockey's proposal is as enlightened as it appears to be, I hope every technologist will help explain that our current systems are far from being ideal.  We mustn't get too hung up on simply preventing deterioration of privacy through absurdist proposals, because the current bar is already too low for safety. 

We need to follow Australia in being proactive about strengthening the fabric of privacy while achieving the goals of business and government.

Privacy and Identity – IGF workshop outcomes

From the Internet Governance Forum, via Ralf Bendrath's blog: 

The workshop on privacy and identity we held together with the LSE information systems group this morning sparked an interesting discussion.

Christian Möller gave some examples of how privacy is not only important in itself, but how it also is a necessary condition for freedom of expression.

Microsoft’ Jerry Fishenden presented their InfoCards concept and the “7 Laws of Identity” as one approach on how to handle user data based on different credentials. While most of the panelists agreed that this is a good basis for a start, and especially welcomed the company's recent efforts to make it more privay-friendly, Jan Schallaböck and Mary Rundle pointed at one major drawback: Once you have sent your personal information to a company – no matter if through InfoCards or another system – you can not control what happens with it afterwards.

Jan, who is with the data protection authority of the German land of Schleswig-Holstein, therefore presented the ideas, concepts and systems developed in the EU-funded Privacy and Identity Management in Europe (PRIME) project as an alternative.

Their model is that user data given to web service providers will have “sticky privacy policy” attached to it in the form of meta-data. This meta-data will move with the personal data and can help ensure that it is only used or tranferred in a way the user has agreed to.

Mary from NetDialogue suggested (having) a similar way as the Creative Commons license: Privacy Policies should be human readable, lawyer readable, and machine readable. The advantages would be that the users can better decide how they “licence” the use of their data to other parties. Mary even presented a very nice series of icons that symbolize different use policies.  This approach might be one way to address the failure or “myth of user empowerment”, as Ives Poullet called it.

Stephanie Perrin, research director at the Office of the Privacy Commissioner of Canada, finished by saying that the privacy community has to become much more involved in international technical standardization processes. As always, time was too short. Therefore, we will discuss a collaborative follow-up process later this evening.

Actually, the “sticky privacy policy” notion can be implemented by identity providers using version 1 of Cardspace – it doesn't limit the token types that can be exchanged.  A new type of token that includes metadata about use policy is a good example of why this flexibility is useful.  I support the idea.

Maybe Jan Schallaböck and Mary Rundle are aware of this, but are talking about the self-issued identity provider used to “bootstrap” Cardspace.  In v1.0, it does not have this kind of metadata built in to it. 

I look forward to collaborating with Mary and Jan to create the kinds of visual and metadata systems now being discussed.  I don't actually see PRIME as being “alternative” in any way to the work I've been doing – we have the same goals.