Ben Laurie on Selective Disclosure (Part 2)

In introducing people to his Selective Disclosure paper, Google's Ben Laurie says: 

In fact, there are many ways CardSpace could violate the laws, but there is one which it is currently inherently incapable of satisfying, which is the 4th law – the law of directed identity – which says, once you’ve fought your way through the jargon, that your data should not be linkable.

Ben doesn't like the term “omni-directional identifier”, which is certainly his prerogative.  But speaking of jargon, note that according to the Oxford English Dictionary, Ben's word “linkable” doesn't actually exist… 

Meanwhile “omni-directional” is a real word from the field of telecommunications (isn't that what we are working in?)  It means “of equal sensitivity or power in all directions”.  Similarly, “unidirectional” means “moving or operating in a single direction”.

So I think the Fourth Law is precise enough:

A universal identity system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

The word “discovery” is again used in the technical sense of making it possible to locate and rendezvous with other entities.   The goal here is to embrace the range of use cases I discussed in part one

Ben argues that CardSpace breaks this Fourth Law.  In this he is wrong.  I suspect he is confusing CardSpace, which is just a way of selecting between identity providers, and the identity providers themselves.  Let's get that really straight.

CardSpace is one component of the Identity Metasystem – by which I mean a distributed mesh of parties asserting and depending upon identity.  CardSpace informs the user about the identity providers that can satisfy a given relying party request, and provides a mechanism to tell the user what information must be released to the relying party in order to gain admission to the site.  But the identity selector does not itself make assertions or sign them cryptographically, or do anything that introduces linkability or traceability.  If linkability is introduced, it is because of the choice of the identity provider people use with the the system, and of the cryptographic systems they employ.  

Privacy characteristics of the self-asserted Identity Provider 

While CardSpace is an identity selector, we have built it to include a self-asserted identity provider as a way to bootstrap the system.   So what are the privacy characteristics of this provider?

  • It emits no identifiers that allow the identity of the user on one system to be linked to the identity of the user on any other.  
  • A different signing key is used at each site visited so keys and signatures cannot be correlated.
  • Relying parties cannot collude with this identity provider because it is run by the user. 

So the Identity Provider that ships with CardSpace does not break the Fourth Law either.

Managed Card Providers 

Now let's talk about managed card providers, and think about other systems such as Liberty or Shibboleth or OpenID or SAML or WS-Federation in browser mode. 

These systems always identify the relying party to the identity provider.  They do so because they need to tell the identity provider how to redirect the client's browser back to the relying party.  So they are what I call panoptical by design.  There is zero collusion required for the identity provider to know what is being asserted where – that knowledge is designed right into the system.

CardSpace breaks with this paradigm, and I hope Ben comes to recognize this. 

To support use cases where we do NOT want linkability, CardSpace hides the identity of the relying party from the identity provider.  If we had built it without this feature, it too would have been “panoptical by design”.  But we didn't do that.  We built it to conform with the Fourth Law.  In other words, CardSpace does not provide unnecessary handles to facilitate linkability.

How does CardSpace hide the identity of the relying party?  It associates some random information – unknown to the identity provider – with each Information Card.  Then it hashes this random information (let's call it a “salt”) with the identity of the site being visited.  That is conveyed to the identity provider instead of the identity of the site.  We call it the “Client Pseudonym”.  Unlike a Liberty Alliance client pseudomym, the identity provider doesn't know what relying party a client pseudonym is associated with. 

The identity provider can use this value to determine that the user is returning to some site she has visited before, but has no idea which site that would be.  Two users going to the same site would have cards containing different random information.  Meanwhile, the Relying Party does not see the client pseudonym and has no way of calculating what client pseudonym is associated with a given user.   

The question now becomes that of how identity providers behave.  Given that suddenly they have no visibility onto the relying party, is linkability still possible?  I'll discuss this next.

Shibboleth adds CardSpace support

Here is news from Internet2 and Shibboleth, the open-source software for building multilateral federations that has become especially popular in the academic world (more information on Shibboleth here). 

ANN ARBOR, Mich. – May 23, 2007 –  Adding information card support to Shibboleth, the most widely-deployed federated authentication architecture, would enable interoperability with Windows CardSpace which provides critical support for secure user-centric authentication and identity information exchange for web-based applications. By enabling this interoperability, Microsoft and Internet2 aim to help users exchange personal identity information more safely and easily. In doing so, institutions can more effectively leverage their existing and future investments in their identity management solutions and build a closer, safer relationship with their users.

“As more and more companies and organizations make information materials and resources accessible online, the need for secure access solutions has become critical. We see information card technology like Microsoft's Windows CardSpace as a very important step forward in creating a ubiquitous Internet identity layer, which is a key goal of the Shibboleth project as well,” said RL “Bob” Morgan, security architect at the University of Washington and co-manager of the Shibboleth Project. “We appreciate Microsoft's leadership in helping to create an open environment for information card development and deployment, and are grateful for Microsoft support of Windows CardSpace work in Shibboleth.”

Shibboleth is a standards-based, open source middleware architecture providing both intra-domain and inter-domain single-sign on (SSO) capability. Used by over 20 million users worldwide within the research and higher education community, Shibboleth implements the OASIS Security Assertion Markup Language (SAML) standard specification, and is currently interoperable with Microsoft's Active Directory Federation Services (ADFS).

Both Shibboleth and Windows CardSpace provide the underlying mechanisms for institutions and individuals to share resources across organizational boundaries and to make informed authorization decisions for the access of protected online resources. This federated authentication model implemented by both Internet2 and Microsoft has proven to provide online resource providers and institutions with a solid platform for exchanging information in a highly secure and privacy-preserving manner. Once development is complete, sites using Windows CardSpace will have the ability to participate in the growing number of Shibboleth-based federations worldwide.

“The Internet2 Shibboleth project has been one of the leaders in bringing interoperable digital identity to the academic and research communities worldwide,” said Michael B. Jones, senior program manager for Identity Partnerships at Microsoft. “Shibboleth's support for information cards allows people in the Shibboleth federation to use the cards at sites participating in the Identity Metasystem, making the identities more valuable to both the issuers and to the individuals, as well as enhancing the user's control of their online interactions.”

I echo Mike's words.  Shibboleth is distinctly forward thinking in its approach, and has been the main crucible for refining the thinking (and practice) that enables multilateral federations like those needed to facilitate co-operation between universities. 

As Shibboleth federations continue to grow, so will the rewards for attacking them.  CardSpace, and other compatible Information Card selectors, will add resilience and phishing resistance while helping solve Shibboleth's “home site discovery” problem in a way that doesn't put control in the hands of evil sites posing as federation affiliates. 

For more details on what is at stake here, see this posting where I explain a similar vulnerability in OpenID.  SAML and the browser-based version of WS-Federation are also subject to these attacks, which become more probable as the technologies become more widely deployed.   

Ben Laurie on Selective Disclosure (Part 1)

Google's Ben Laurie has a new paper called Selective Disclosure in which he argues the importance of zero knowledge proofs and privacy-enhancing cryptography. I fully share his view of the importance of these technologies.

Everyone with a technical interest in identity should look at Credentica’s recently released SDK, called U-Prove. It holistically embodies the cryptographic breakthroughs of Stefan Brands.

There is also a competing system from IBM called IDEMIX, though it is not yet publicly available and I can't talk about it first-hand.

On his way toward explaining how these systems work, Ben takes the time to put forward his own Laws of Identity (“Let a thousand flowers bloom!”)  He is responding to my Fourth Law, which asserts the need for the Identity Metasystem to support both public identifiers (for example, my blogging address) and private ones (my account number with a given company, unknown to anyone but me and them).  He says:

“For an identity management system to be both useful and privacy preserving, there are three properties assertions must be able to have. They must be:

  • Verifiable: There’s often no point in making a statement unless the relying party has some way of checking it is true. Note that this isn’t always a requirement – I don’t have to prove my address is mine to Amazon, because its up to me where my goods get delivered. But I may have to prove I’m over 18 to get alcohol delivered.
  • Minimal: This is the privacy preserving bit – I want to tell the relying party the very least he needs to know. I shouldn’t have to reveal my date of birth, just prove I’m over 18 somehow.
  • Unlinkable: If the relying party or parties, or other actors in the system, can, either on their own or in collusion, link together my various assertions, then I’ve blown the minimality requirement out of the water.”

These are important things for the Identity Metasystem to support, and I make the same points in my own version of the laws. But I don't think these characteristics are the whole story – rather, they describe requirements for certain use cases.  However, there are other use cases, and it was the goal of the original Laws of Identity to embrace them as well.

For example, when I blog I want to use an identity that is linkable. I want anyone who is interested in my ideas to be able to talk about them with anyone else, and tell them how to get to my web site, which is – in the most literal sense of the word – a “linkable” characteristic of my identity.

And when accessing my bank account through the internet, I would rather like to ensure that the party withdrawing the money is tightly linked to a real-world person – hopefully me.

So we don't always want our identity to be unlinkable. We want unlinkability to be one of our options.

Similarly, I don't want every assertion I make to be verified by some bureaucratic process. I don't run around in the molecular world armed with official documents that I present to every Tom, Dick and Harry.  Again, I want verifiability to be one of my options, but not more than that. We need to be careful about what we wish for here. Requiring individuals to employ identities verified by third parties in contexts where there is no good reason for it is a slippery and dangerous slope. So I hope that's not what Ben has in mind.

When using a public identity (which I call “omnidirectional” because you share it with everyone) I may want to divulge more information than is necessary for some specific purpose. So even the notion of minimal disclosure doesn't apply within certain contexts and when public personas are involved.

Thus I take Ben's real point to be that an important and mainstream use case is one where verifiability, minimal disclosure AND unlinkability, should all be achievable at the same time.  This I agree with.

What strikes me as strange in Ben's document is this comment:

“Note a subtle but important difference between Kim’s laws and mine – he talks about identifiers whereas I talk about assertions. In an ideal world, assertions would not be identifiers; but it turns out that in practice they often are.”

I say “strange” because when you actually read the Laws of Identity this is what you will find:

We will begin by defining a digital identity as a set of claims made by one digital subject about itself or another digital subject. (page 4)

Is what I called a claim different from what Ben calls an assertion?  Well, on page 5 of the Laws, I wrote (citing the Oxford English Dictionary, well known to Ben):

A claim is, “…an assertion of the truth of something, typically one which is disputed or in doubt”.

Clearly I'm going a bit beyond Ben's concerns in that I remind the reader that assertions must be evaluated, not just made.  But in no way can I be said to confuse identifiers and digital identity.  In fact, I go on to give some examples which make my ideas in this regard perfectly clear.  (page 5). 

  • A claim could just convey an identifier – for example, that the subject’s student number is 490-525, or that the subject’s Windows name is REDMOND\kcameron. This is the way many existing identity systems work.
  • Another claim might assert that a subject knows a given key – and should be able to demonstrate this fact.
  • A set of claims might convey personally identifying information – name, address, date of birth and citizenship, for example.
  • A claim might simply propose that a subject is part of a certain group – for example, that she has an age less than 16.
  • And a claim might state that a subject has a certain capability – for example to place orders up to a certain limit, or modify a given file.

These examples demonstrate that there is no difference between my approach to claims in the Laws of Identity and that proposed recently by Ben.  Further examples abound: 

In proffering this definition, we recognize it does not jive with some widely held beliefs – for example that within a given context, identities have to be unique. (page 5)

Or:

In this scenario we actually do not want to employ unique individual identifiers as digital identities. (page 6)

Or:

It makes sense to employ a government issued digital identity when interacting with government services (a single overall identity neither implies nor prevents correlation of identifiers between individual government departments). (Page 9)

Now I know we're all busy.  I don't expect people to be familiar with my work.  But Ben explicitly cites what he calls my “famous laws” in a footnote, and calls out the “important difference” in our thinking as being that I'm concerned with identifiers, whereas he is concerned with assertions.  He's just wrong, as anyone who reads the Laws can see. 

The fact is, I like Ben, and I like a lot of his thinking.  I hope he reads my version of the laws before citing them again, and that he corrects his rendition of my thinking about identifiers and claims or assertions.  This seems doable since his paper is still a work in progress.

Pamela Dingle on multiple issuers

Some clear and advanced thinking from Pamela Dingle at Eternal Optimist:

Here is a simple and likely RP scenario that I’d like you to consider:

A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?

Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it’s important too, but I don’t see an easy way to actually accomplish it.

To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:

  • if a card’s issuer matches the value of the issuer parameter

  • if the entire set of required claim types are all present in a given card.

In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0 only accepts a single issuer. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa’s STS, or I can specify Mastercard’s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.

So – that leaves us claims. Claims are great – when you can use what’s in them. In this case, however, the RP can’t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn’t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim type for every possible distinct combination of credit cards. Let’s say that there are 6 major credit card companies out there. How many permutations & combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?

It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types — contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn’t so bad — but the big problem is, it takes the ‘distributed’ out of this wonderful distributed system.

Unless things change (or unless I’m proven wrong, maybe I’m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML “menu” of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?

If it does happen, I can see all sorts of fallout:

  • Common claim types are no longer needed to ensure the user picks the right card. This is good.

  • Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.

  • The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.

  • The system is more distributed, but MUCH less consistent for the user. This is bad.

  • It opens the door for the more established Identity Providers to set arbitrary rules on what attributes “must” be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.

Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP’s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won’t end up being that important — but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like “every issuer except these two”.

Kim, Mike, what can we do? Is this as big a problem as I’ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?

Pam's thinking is unassailable.  The problems she outlines are issues we just didn't have time to solve in version 1.0 of CardSpace. 

We were aware of them, but wanted to get the first round of our technology “out there” so everyone could start doing proofs of concept and implementations that would help clarify the right approaches.  I think in practice we'll have time to fix this before people anyone really “feels” it.  Not all credit card providers will be supporting information cards at once.  Meanwhile we'll be pumping out more advanced versions of CardSpace that address the issue.  

The same problems Pam describes with respect to issuers apply with respect to RP support for multiple token types (e.g. SAML tokens plus OpenID tokens).  Currently we can address this by accepting “any” token type, and that will get us by for a while, but ultimately we will need to be able to specify rich combinations.

WS-SecurityPolicy is powerful enough to express boolean logic, so theoretically the relying party can publish metadata that has all the capabilities Pam calls for.  For example, you can say you will accept American Express AND Visa as issuers but not Diner's Club.  You can also require different claim types from different issuers.  So the architecture is adequate to the problems.  

So given that the architecture is right, it represents an opportunity for our competitors…  And we ourselves are working really hard to solve this problem in our next version – before it anyone feels the pain.

Side effects of synthroid

My lawyer friends all know I am “legally challenged” – so don't take anything I say about legal issues as representing any particular expertise. 

But on the news today I saw a story about a drug manufacturer showing the consequences of making false technical claims like those I objected to here in other walks of life: 

NEW YORK (CNNMoney.com) — The maker of OxyContin, Purdue Pharma LP, agreed Thursday to a $600 million penalty as part of a plea deal with the Justice Department on a felony charge of misleading and defrauding physicians and consumers, the government said.

Three of the company's executives, including its CEO, general counsel and former chief medical officer, have separately agreed to pay $34.5 million in penalties. The company and the three men appeared in federal court Thursday to plead guilty.

The company also agreed to subject itself to independent monitoring and a remedial action program.

“Purdue … acknolwedged that it illegally marketed and promoted OxyContin by falsely claiming that OxyContin was less addictive, less subject to abuse and diversion, and less likely to cause withdrawal symptoms than other pain medications – all in an effort to maximize its profits,” said U.S. Attorney John Brownlee.

There should be accountability and penalties for those who consciously mislead people like the Marlin County school board, convincing them there is no risk to privacy by preying on their inability to understand technical issues.  It should be mandatory, when selling technology with potential privacy implications, to explain the threats and mitigations in an objective and public way.

Just lie so you can sell your product

David C pointed me to this document as being typical of how conventional biometrics are being sold to the schools.  It represents the minutes of a meeting of the Marlin County School Board in Stuart, Florida:

Members Present
Lorie Shekailo-Chair
Laurie Gaylord-Vice-Chair
Susan Hershey
Nancy Kline
Dr. Sara A. Wilcox, Superintendent
Doug Griffin, School Board Attorney

Members Absent
Dr. David Anderson

Staff Present
Hank Salzler, Ruth Pietruszewski, Cathleen Brennan, Kerry Lewis, Sean Lewis, Linda King, Ray Parrish, Steve Weil, Rae Hollenbeck, Deana Newson, Rodger Osborne, Teresa D’Albora, Willie Sauls, Jeff Haertjens, Gail Williams, Marilyn Gavitt, Kathy Ritch

Public
None

Press
PBPost – Rachel Simmonsen
Stuart News – No Representation

MCEA – No representation
AFSCME – No representation

Call to order by the Chairman and Pledge of Allegiance to the Flag of the United States.

1. Presentation on Biometric Finger Imaging (COPY ATTACHED)

Rae Hollenbeck, MCSD Director of Food and Nutritional Services, described a new technology called Biometric Finger Imaging that has only been available about six months. She showed a PowerPoint presentation. Finger images are scanned and stored on the computer network, so that children no longer need cards. Rae explained how children forget and lose cards as they run off to school in the morning. This backs up the lunch line and creates managerial time reprinting meal cards. Rae commented that already this school year 4,000 meal cards had been reprinted just at the middle schools. The cards become unsanitary, because the children put them in their mouths. To solve these problems, schools are using biometric scanners in the cafeteria. The student places their index finger on a scanner.

The Perfectmatch software extracts the small marks on their finger tip and creates a template. These marks are transformed into a binary number that is encrypted from the time it is captured to the time it is stored on the database, and the finger image is discarded. The binary number will become the student ID number. Only the numbers are retained and it is impossible to recreate a fingerprint image from this data. This is a closed system, and it is not accessible from the internet. The biometric images cannot be used by law enforcement for identification purposes. Only a mathematical algorithm remains in the system after registration, not finger images. Rae stated that she would like to pilot this program at Murray Middle School in January 2007.

The program would not be mandatory.  Parental choice would be offered if parents wanted to opt out of the program.

The hardware would run somewhere around $200 per line. The total cost of hardware and software would run about $1500.00 per cafeteria. The new technology would improve sanitation of the line, increase the speed of the serving lines, and reduce staff time dealing with missing and lost cards, forgotten ID numbers, and reprinting cards.

2. Open to the Public
No one from the public requested to speak.

Biometric Finger Imaging Workshop Minutes
Tuesday, October 17, 2006 – 6:00 p.m.
Page 2 of 2

3. Open to the Board
Lorie Shekailo suggested withholding “Open to the Board” and doing it at the Regular Board meeting which followed.
Board members agreed.

There being no further business to bring before the Board, the meeting was adjourned at 6:24 p.m.
_______________________________

CHAIR (Lorie Shekailo)
_______________________________

SECRETARY (Sara A. Wilcox, Ph.D)

The sanitation argument is new to me.  Imagine – stressing the sanitation benefits of   having every child in a middle school put his germy little finger on the same sensor as every other child…  Seems like a good way to isolate viruses, doesn't it?  A lot better than giving each child a paper card!

The idea of children putting their cards in their mouths sends chills down my spine.  In contrast, they would never stick their fingers in their mouths, and then swipe them on the finger print reader for distribution to all the other kids.  Talk about a shared secret!

But let's brush this aside and move on to the old saw – the lie:

The biometric images cannot be used by law enforcement for identification purposes. Only a mathematical algorithm remains in the system after registration, not finger images.

If you want to find out who owns a fingerprint, just convert the fingerprint to a template and do a search for the template in one of these databases.  Call the template a binary number if you want to.  The point is that all you need to save in the database is the number.  Later, when you come across a “fingerprint of interest”, you just convert it to a number and search for it.  Law enforcement can use this information – and so can criminals.

It drives me nuts that people can just open their mouths and say anything they want about biometrics and other technical matters without any regard for the facts.  There should really be fines for this type of thing – rather like we have for people who pretend they're a brain surgeon and then cut peoples’ heads open.

LeaveThemKidsAlone has an annotated commentary here.

And if you haven't see it yet, don't miss this little movie clip.  It will boggle your mind.

Age and identity verification in Second Life

Via Dennis Hamilton, a pointer to a new experiment at Second Life:

We will shortly begin beta testing an age and identity verification system, which will allow Residents to provide a one-time proof of identity (such as a driver’s license, passport or ID card) and have that identity verified in a matter of moments.

Second Life has always been restricted to those over 18. All Residents personally assert their age on registration. When we receive reports of underage Residents in Second Life, we close their account until they provide us with proof of age. This system works well, but as the community grows and the attractions of Second Life become more widely known, we’ve decided to add an additional layer of protection.

Once the age verification system is in place, only those Residents with verified age will be able to access adult content in Mature areas. Any Resident wishing to access adult content will have to prove they are over 18 in real life.We have created Teen Second Life for minors under the age of 18. Access to TSL by adults is prohibited, with minors not allowed into the rest of Second Life.

For their part, land owners will be required to flag their land as ‘adult’ if it contains adult content using the estate and land management tools provided to landowners. This flag will protect landowners from displaying inappropriate content to underage users who may have entered Second Life. Landowners are morally and legally responsible for the content displayed and the behavior taking place on their land. The identity verification system gives them new tools to ensure any adult content is only available to adults over 18 because unverified avatars will not have access to land flagged as containing adult content.

We hope you’ll agree that the small inconvenience of doing this once is far outweighed by the benefits of protecting minors from inappropriate content. Further, this system will assist landowners in engaging in lawful businesses.

The verification system will be run by a third party specializing in age and identity authentication. No personally identifying information will be stored by them or by Linden Lab, including date of birth, unless the Resident chooses to do so. Those who wish to be verified, but remain anonymous, are free to do so.

(Continues here…)

The idea of presenting a passport to get into an imaginary adult establishment strikes me as nutso.  I must be missing a gene.  It is certainly a conundrum, this virtual world. 

I think that rather than adopting this one-off inspector approach, outfits like Second Life and all the other big web sites should get together to accept registration claims from whatever identity providers would fully guarantee both accuracy and the anonymity of their users.  Information Cards combined with the anonymous credential technology developed by people like Stefan Brands would provide the ideal solution.

Privacy International global privacy invaders

Privacy International ran the first International Big Brothers Awards ceremony this week, focussing attention on what it called the most invasive companies, projects, officials, and governments at the ‘Computers, Freedom and Privacy’ conference in Montreal. A ‘special award’ for the ‘Lifetime Menace’ was also announced.  The detailed announcement is here:

PI's ‘Big Brother Awards’ have been running for nearly ten years, with events run in eighteen countries around the world. Government institutions and companies have been named and shamed as privacy invaders in a variety of countries and contexts.

This year was the first time that Privacy International ran an international event to identify the greatest invaders around the world. The event was hosted by ‘the pope’, as presented by Simon Davies in full regalia. Previous hosts include ‘Dr. Evil’ and ‘The Queen of England’.

Nominees and Winners

After reviewing the variety of nominations received from around the world, Privacy International and leading international privacy experts selected the following nominees and winners in the following categories:

Most invasive company

Nominees

  • Google, for their retention practices and their purchase of Doubleclick, an on-line marketing and profiling firm
  • Choicepoint, for their vast databases of personal data, sold to nearly anyone who wishes to pay
  • SWIFT, the international banking co-operative for sharing personal financial transactions with the U.S. government
  • Booz Allen Hamilton, the international consultancy, for taking the knowledge and contacts of their senior executives, mostly from U.S. intelligence agencies, to sell and share their experiences with firms and governments around the world

Winner: Choicepoint

Worst Public Official

Nominees

  • Tony Blair, Prime Minister of Britain, for his relentless work over ten years to expand the UK into the greatest surveillance society amongst democratic nations
  • Vladimir Putin, President of the Russian Federation, for returning the surveillance policies of his nation to the age of the Cold War
  • Stewart Baker, former general counsel for the National Security Agency and now undersecretary for policy at the Department of Homeland Security, behind and at the forefront of most disastrous U.S. surveillance policies, most recently the EU-U.S. agreement on Passenger Name Records transfers
  • Alberto Gonzales, current Attorney General for the U.S., for pushing expansive interpretations of the U.S. Constitution in order to create new powers for the Bush Administration without Congressional authorisation and judicial oversight

Winner: Stewart Baker

Most Heinous Government

Nominees

  • China, for implementing even greater surveillance policies and continues its oppression of various groups, and moves towards the international stage with the Beijing Olympics with additional surveillance schemes
  • The U.S., for leading the world down the path of greater surveillance and its disastrous influence on policy and technology
  • The United Kingdom, for being the greatest surveillance society amongst democratic nations, rivaling only Malaysia, China and Russia as it also leads other countries across the EU down its same path
  • Tunisia, for being stupid enough to have invasive and despotic practices even while hosting a UN summit on the information society, and then oppressing guests and groups from around the world while in the public eye
  • The European Union, for pretending to be founded upon a bedrock of civil liberties and fundamental rights but then spending decades establishing invasive policies without any democratic oversight

Winner: The United Kingdom (for more information please see Taking Liberties documentary (off-site))

Most Appalling Project or Technology

Nominees

  • U.S. Border Policy, and most recently the Western Hemisphere Travel Initiative, for fingerprinting visitors from around the world while hoisting fingerprinting and ID card programmes upon citizens around the world, including Americans
  • International Civil Aviation Organization, a UN agency, for implementing a variety of invasive policies behind closed doors, including the ‘biometric passport’ and passenger data transfer-deals
  • India's Ministry for Personnel, Public Grievances and Pensions for requiring government employees to disclose their menstrual cycles on job appraisal forms
  • the CCTV industry, for promoting a technologically ‘effective’ policy around the world despite all the evidence to the contrary

Winner: The International Civil Aviation Organization

Lifetime Menace Award

Nominees

  • The Biometrics Industry, for selling a limited technology to governments and public institutions around the world, promising much while delivering very little except for minimisation of personal privacy
  • The Military Industrial Complex, for being behind almost every invasive surveillance policy around the world, where we showed the example of General Dynamics, contractor to a variety of governments, who own companies such as Anteon (UK) who in turn own ‘Vericool’ (UK) who is responsible for selling surveillance technologies to schools that want to fingerprint their students to verify class registries, library privileges, and cafeteria purchases
  • The Intellectual Property Industry, for promoting and pushing invasive policies around the world in order to keep track of the habits of on-line users to pursue their agenda of ‘protecting’ content
  • Communitarianism and the proponents of the ‘Common Good’, because every bad policy around the world is justified based on the philosophy that is good for society and the individual must sacrifice his or her selfish rights in favour of the needs of the many

Winner: The ‘Common Good’

Privacy International said winners were given the classic BBA award (shown above), a golden statue of a boot stamping upon a human head, as promised by George Orwell in 1984 on a vision for the future.

I wonder who accepted on behalf of the “Common Good”?

WS-Federation OASIS TC

I'll begin by quoting from a piece by Paul Madsen after the OASIS announcement of a new working group to drive WS-Federation towards standardization.  Paul writes: 

“James McGovern predicts:

‘I humbly predict that WS-Federation will become more important than SAML within the next two years and will invalidate all the hard work already done by the Liberty Alliance.’

“I guess it's over. I have to admit that I'm disappointed and, to be honest, even surprised.

“I actually thought things were going well, you know, lots of adoption, encouraging signs of convergence, important new functionality etc.

“As for the New Jersey Devils, it seems that the Liberty Alliance's playoff run is over. I'll be emptying my locker and signing autographs this afternoon before spending the summer golfing.”

Like Paul, I'm surprised, if not so inspired to irony, by James’ comment. 

I do agree that WS-Federation will gain a lot of traction.  But I absolutely disagree that it will “will invalidate all the hard work already done by the Liberty Alliance.” 

Liberty has contributed deeply to understanding a whole series of use cases and requirements, and the protocols, formats and concepts proposed by the SAML working groups have been an important step forward for all of us involved with identity.  Nothing about WS-Federation invalidates this work.

On the other hand, technology doesn't stand still.  Think back to the days when SAML was first posited as an alternative to LDAP authentication.  Those of us involved in LDAP from the very beginning didn't for one minute take LDAP as the end of all thinking about attributes and identity.   Ask LDAP guru Mark Wahl, or Bob “RL” Morgan or Keith Hazelton – people deeply involved in Kerberos and LDAP but just as willing to embrace new technologies like SAML as meeting new use cases.

Just as SAML broke new ground, WS-Federation is intended to address a number of things that people working in Web Services want better defined to facilitate interoperation using WS-Security and WS-Trust. 

These protocols hadn't even been invented when SAML evolved.  The idea of claims transformation is the most important technical advance in distributed computing for at least a decade.  It is so powerful that it wasn't even fully understood until we began to build things with it.  So how can anyone expect SAML to deal in an optimal way with the issues that ultimately emerged?  This doesn't detract from SAML's successes.  That's not how software engineering works.

WS-Federation will provide new options for people who want to build on the web services architecture, evolving their current web technology in an incremental way to be consistent with that architecture.  To do this, no one will have to throw out their existing SAML deployments.  Many of the SAML producers will include support for WS-Federation so that interconnectivity will be a given.

A lot of WS-Federation editorial work has been done by my friend DES (Don Schmidt).  This guy has paid his dues – triple dues – and works from a deep experience in security.  After some badgering he has just started to blog his ideas.  Here's part of how he explains his goals: 

WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model.  Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.

Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.

Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.

Microsoft is actually pretty typical of many other companies in that it will have to support a whole spectrum of deployments reaching from simple, restful apps at one end to transactionally guranteed high security applications at the other.  The ability to support the whole spectrum consistently is the key.

We don't want to build two parallel infrastructures in order to do this.  We don't want to deploy everything twice.  Test everything twice.  Secure everything twice.   Does anyone? 

So we need a technology that takes everything learned while elaborating SAML – plus new features – and allows them to be composed and managed within the WS framework as well as used in conventional web sites. That's what I understand this TC to be about.

It remains a personal hope that those who have been involved with SAML will adopt this larger goal as part of what needs to be achieved.  That really will make convergence possible.

And I also expect everyone to give them credit for all they have done, which will not be lost if WS-Federation continues to gain momentum, but will rather be extended.

Information Card Contest

I was still reeling from the latest chicken pictures posted by James McGovern when I stumbled onto news of a contest put together by my colleague Richard Turner

James was complaining that the contest would slow down adoption in his case since it would break corporate policy to accept a prize.  I added a comment to his blog saying I would try to figure out a way that someone who could not accept the prize could make a charitable donation instead. 

But I didn't know what the prizes were until I read the original posting by Richard:

Identifying yourself online is becoming increasingly difficult and dangerous. Most people who use the web have to maintain several usernames and passwords and have to remember which usernames and passwords to use at the various sites they use.

While usernames and passwords are a growing frustration to most users, this problem is dwarfed by the growing threat of phishing and other forms of malware and identity-related attack.

Follow the wrong link and try to sign-in to a malicious site masquerading as, for example, your bank, and you run the very real risk of suffering considerable loss. These potential losses may be financial but may also impact your reputation (e.g. credit score) that may take years to repair.

Microsoft, along with many partners in the IT Industry, is building a suite of technologies to help combat the phishing issue, whilst making it easier for users to authenticate safely online. Technologies such as Windows CardSpace enable users to identify themselves by presenting cryptographically strong identity tokens (represented visually as information cards) to supporting websites.

To help fuel the growth of sites supporting Information Cards, Microsoft is announcing a competition that is open to every website owner, regardless of your web platform of choice. We hope you'll join us in helping to protect your user's identities from abuse and make it easier for your users to sign-in to your sites! 

How to enter

  • Add sign-up and sign-in support for Windows CardSpace to your website
  • Email the following to identity@microsoft.com
    • Details of your site
    • Your details
    • Complete this statement: “We added support for information cards to our site because …”
  • All entries will be judged by the CardSpace product team and winners announced on August 17, 2007. The winner will be notified by email.

The prizes

  • Grand Prize:
    • 1 Round-trip ticket (from and to a single location within the United States)
    • Overnight accommodation in a hotel near Microsoft Campus
    • Meet the team – spend a day with various members of Microsoft's Federated Identity team
    • Dinner with Kim Cameron
  • Second prize:
    • XBox 360 Elite Games Console
  • Third prize:
    • Zune music player

[Please note that due to international gaming laws we are only able to offer these prizes to US Residents and that any taxes incurred from receiving a prize is the sole responsibility of the prize winner(s).]

Adding support for Windows CardSpace to your site

  • The following resources will be indispensible in guiding you how to add support to your website:
  • If you have technical issues, please post questions to the Windows CardSpace discussion forum on MSDN – we'll be monitoring this forum closely and responding as quickly as we can. Note – if you contact us directly with support requests and your request is generic in nature, we'll ask you to post your question to the forum. This is the help others who may be experiencing the same issue as you and so that we can better manage potential support issues.

Anyway, that sounds like a lot of fun, and I'll make sure the winner gets a really incredible evening at one of the top restaurants in the region. 

And as for James, now I know what the prize is, if he wins we can just make it a working dinner at the local pub, taking on the role of Information Cards in the enterprise environment and all the other things I'd like to discuss with him from a purely business point of view.