Category: Privacy

News on the Australian “Access Card”

Here is a report from The Australian about the issues surrounding Australia's Human Services Access Card.  Some of the key points: 

“By this time next year, the federal Government hopes to be interviewing and photographing 35,000 Australians each day to create the nation's first ID databank. Biometric photos, matched with names, addresses, dates of birth, signatures, sex, social security status and children's details, would be loaded into a new centralised database. Welfare bureaucrats, ASIO, the Australian Federal Police and possibly even the Australian Taxation Office would have some form of access to the unprecedented collection of identity data.

“Within three years, all Australians seeking benefits such as Medicare, pensions, childcare subsidies, family payments, unemployment or disability allowances – about 16.5 million people – would have joined the databank. They would be given a photographic access card to prove who they are and show their eligibility for social security.

“This week, however, the billion-dollar project hit a bump when Human Services Minister Chris Ellison revealed that legislation due to go before federal Parliament this month had been delayed…

“How will Australians’ privacy be protected? How will the database and cards be kept secure? Who can see information on the card? What identity documents will Australians need to acquire a card, and what will happen to the estimated 600,000 people without a birth certificate, passport or driver's licence?

“The Government's mantra is that this is not an ID card because it does not have to be carried, but users will have to show it to prove their identity when claiming welfare benefits…

“The Government claims the new system will stem between $1.6 billion and $3 billion in welfare fraud over the next decade…

“A key Government adviser, Allan Fels – a former chairman of the Australian Competition and Consumer Commission and now head of the Government's Access Card Consumer and Privacy Taskforce – is at loggerheads with Medicare, Centrelink and the AFP, who all want the new card to display the user's identification number, photograph and signature…

“The photo would be stored in a central database, as well as in a microchip that could be read by 50,000 terminals in government offices, doctors’ surgeries and pharmacies…

“Despite his official role as the citizens’ watchdog, Fels still has not seen the draft bill…

“‘The law should be specific about what is on the card, in the chip and in the database,’ he says. ‘If anyone in future wants to change that they would have to do nothing less than get an act of parliament through. We don't want a situation where, just by administrative decisions, changes can be made…’

“‘There will be no mega-database created that will record a customer's dealings with different agencies,” the minister [Ellison] told the conference…

“Cardholders may be able to include sensitive personal information – such as their blood type, emergency contacts, allergies or illnesses such as AIDS or epilepsy – in the one-third of the microchip space that will be reserved for personal use. It is not yet clear who would have access to this private zone.

“Hansard transcripts of Senate committee hearings into the access card legislation reveal that police, spies and perhaps even the taxman will be able to glean details from the new database. The Department of Human Services admits the AFP will be able to obtain and use information from the databank and card chip to respond to threats of killing or injury, to identify disaster victims, investigate missing persons, or to ‘enforce criminal law or for the protection of the public revenue’.

“Australia's super-secretive spy agency, the Defence Signals Directorate, will test security for the new access card system…

“The Australian Privacy Foundation's no-ID-card campaign director, Anna Johnston, fears future governments could “misuse and abuse” the biometric databank…

(Full story…)

ID Cards can be deployed in ways that increase, rather than decrease, the privacy of citizens, while still achieving the goals of fraud reduction.  It's a matter of taking advantage of new card and crypto technologies.  My view is that politicians would be well advised in funding such products rather than massive centralized databases.

As for the Defense Signals Directorate's access to identity data, what has this got to do with databases offering generalized access to every curious official?  You would think they were without other means.   

More on the iTunes approach to privacy

Reading more about Apple's decision to insert user's names and email addresses in the songs they download from iTunes, I stumbled across a Macworld article on iTunes 6.0.2 where Rob Griffiths described the store's approach to capturing user preferences as “spyware”.

I blogged about Rob's piece, but it turns it was 18 months old, and Apple had quickly published a fix to the “phone-home without user permission” issue.  

Since I don't want to beat a dead horse, and Apple showed the right spirit in fixing things, I took that post down within a couple of hours (leaving it here for anyone who wonders what it said). 

So now, with a better understanding of the context, I can get on with thinking about what it means for Apple to insert our names and email addresses into the music files we download – again without telling us.

First I have to thank David Waite for pointing out that the original profiling issue had been resolved:

Kim, [the Macworld] article is almost 18 months old.  Apple quickly released a newer version of iTunes which ‘fixed’ this issue – the mini store is disabled by default, and today when you select to ‘Show MiniStore’ it displays:

“The iTunes MiniStore helps you discover new music and video right from your iTunes Library. As you select tracks or videos in your Library, information about your selections are sent to Apple and the MiniStore will display related songs, artists, or videos. Apple does not keep any information related to the contents of your iTunes Library.

Would you like to turn on the MiniStore now?”

The interesting thing about the more recent debacle about Apple including your name and email address in the songs you buy from their store is that they have done this since Day 1. Its only after people thought Apple selling music with no DRM was too good to be true that the current stink over it started.

It's interesting to understand the history here.  I would have thought that in light of their previous experience, Apple would have been very up front about the fact that they are embedding your name and email address in the files they give you.  After all, it is PII, and I would think it would require your knowledge and approval. 

I wonder what the Europeans will make of this?

iTunes and Identity-Based Digital Rights Management

 A fascinating posting by Randy Picker at the University of Chicago Law School Faculty Blog:

Over the last week, it has been become clear that Apple is embedding some identifying information in songs purchased from iTunes, including the name of the customer and his or her e-mail address. This has raised the ire of consumer advocates, including the Electronic Frontier Foundation which addressed this again yesterday.

Last year, I published a paper entitled Mistrust-Based Digital Rights Management (online preprint available here). In that paper, I argued that as we switched from content products such as CDs and DVDs to content services such as iTunes, Google Video and YouTube, we would embrace identity-based digital rights management. This is exactly what we are seeing from iTunes. How should we assess identity-based DRM?

Take a step backwards. As long as I keep my songs to myself and don’t share them, the embedded information shouldn’t matter. The information may facilitate interactions between Apple and its customers and might make it easier to verify whether a particular song was purchased from iTunes, but this doesn’t seem to be the central point of embedding identity in the songs.

Instead, identity matters if I share the song with someone else. Identity travels with the content. If I know that and care, I will be less likely to share the content indiscriminately over p2p networks. Why should I care? It depends on what happens with the embedded information. One use would make it possible for Apple to identify who was sharing content on p2p networks. Having traced content to its purchaser, Apple might choose to drop that person as a customer.

But Apple could do this without embedding the information in the clear. As Fred von Lohmann asked in his post on the EFF blog, why embed identity in the clear rather than as encrypted data? After all, if Apple intends to scour p2p networks, it could do so just as easily looking for encrypted identities.

Apple might have a different strategy, one that relies on third-party sanctions, and that strategy would require actual identities. Suppose Apple posted the following notice on iTunes:

“Songs downloaded from iTunes are not to be shared with strangers. We have embedded your name and email address into the songs. Our best guess is that if you share iTunes songs on p2p networks, your name and email will be harvested from those songs and you will receive an extra 10 spam emails per day from third parties.”

Encrypted information works if Apple is doing all of the detection. It would even work, as I suggested in my paper, if Apple relied on third parties to do the detection by turning in p2p uploaders to Apple. We could run that system with encrypted information. All that is required is that the rat knows that he is turning in someone; he doesn’t need to know who that person is exactly.

But a third-party punishment strategy would probably be implemented using actual identity. The spammer who harvests the email address inflicts the penalty for uploading, not Apple itself. For Apple to drop out of the punishment business, it needs to hand off identity. Obviously, extra spam is just one possible cost for disclosing names and emails; other costs would further reduce the incentive to upload.

Disclosing identity is a clumsy tool. It doesn’t scale very well. It will work most powerfully against the casual uploader. It offers no (marginal) deterrence against someone who would upload lots of songs anyway. My mistrust-based scheme (described in the paper) might work better in those circumstances.

So far, Apple doesn’t seem to be saying much about what it is doing. It needs to be careful. As the Sony BMG fiasco—also discussed in the paper—emphasizes, content owners may not get that many opportunities to establish technological protection schemes. Each one they get wrong makes it that much harder to try another scheme later, given the adverse public relations fallout. As I suggest above, Apple may have a legitimate strategy for disclosing identity in the clear. It will be interesting to see what Apple says next.

I haven't read Randy's paper yet but will do so now.

Keys, signatures and linkability

Stefan Brands is contributing to the discussion of traceability, inkability and selective disclosure with a series of posts over at identity corner.  He is one of the world's key innovators in the cryptography of unlinkability, so his participation is especially interesting.   

Consider a user who self-generates several identity claims at different occassions, say “I am 25 years of age”, “I am male”, and “I am a citizen of Canada”. The user’s software packages these assertions into identity claims by means of attribute type/value pairs; for instance, claim 1 is encoded as “age = 25”, claim 2 is “gender = 0”, and claim 3 is “citizenship = 1”. Clearly, relying parties that receive these identity claims cannot trace them to their user’s identity (whether that be represented in the form of a birth name, an SSN, or another identifier) by analyzing the presented claims; self-generated claims are untraceable. Similarly, they cannot decide whether or not different claims are presented by the same or by different users; self-generated claims are unlinkable.

Note that these two privacy properties (which are different but, as we will see in the next paragraph, complementary) hold “unconditionally;” no amount of computing power will enable relying parties to trace or link by analyzing incoming identity-data flows, not even if relying parties collude (indeed, they may be the same entity).

Now, consider the same self-generated identity claims, but this time their user “self-protects” them by means of a self-generated cryptographic key pair (e.g., a random RSA private key and its corresponding public key). The user digitally signs the identity claims with his private key; for example, claim 1 as presented to a relying party looks like “age = 25; PublicKey = 37AC986B…; Signature = 21A4A5B6…”. Clearly, these self-protected claims are as untraceable as their unprotected cousins in the previous paragraph. Are they unlinkable? Well, that depends:

  • If the user applies the same key pair to all claims, then the public key that is present in the presented messages will be the same; thus, all presented identity claims are linkable. As a result, a relying party that receives all three claims over time knows that it is dealing with a 25-year old Canadian male. As the user over time presents more linkable claims, this may indirectly lead to traceability; for example, the relying party may be able to infer the user’s birth name once the user presents a linkable identity claim that states the postal code of his home address.
  • If the user applies a different self-generated key pair to each identity claim, the three presented claims are as unlinkable and untraceable as in the example where no cryptographic data was appended. Note that this solution does notforce unlinkability and untraceability: in cases where the user should be identified, the user can simply provide a claim that specifies his name: “name=Jon Smith” or “SSN-identifier=945278476”, for instance. Similarly, to make self-generated identity claims linkable, an additional common attribute value can be encoded

This is a clear way to introduce the notion of how keys and signatures affect tracability and linkability of claims.  However there is more to consider.  Even if the user applies a different self-generated key pair for each of the three attributes discussed above,  if the three attributes are transfered in a single transaction, they are still linked.  The transaction itself links the attribute assertions.  Convenyance of multiple claims is a very common case.

Similarly, if Stefan's three attributes are released during what can be considered to be the same session, they are linked, again regardless of the cryptography.  And if they are released within a given time window from the same transport (IP) address, they should be considered linked too.

While cryptography is one factor contributing to linkability, we need to look at the protocol patterns and visibility they render possible as well.  I'll be starting to do that in my next posting.

Linkage and identification

Inspired by some of Ben Laurie's recent postings, I want to continue exploring the issues of privacy and linkability (see related pieces here and here). 

I have explained that CardSpace is a way of selecting and transferring a relevant digital identity – not a crypto system; and that the privacy characteristics involved depend on the nature of the transaction and the identity provider being used within CardSpace – not on CardSpace itself.   I ended my last piece this way:

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?

But before zeroing in on specific technologies, I want to drill into two issues.  First is the meaning of “identification”; and second, the meaning of “linkability” and its related concept of “traceability”.  

Having done this will allow us to describe different types of linkage, and set up our look at how different cryptographic approaches and transactional architectures relate to them.

Identification 

There has been much discussion of identification (which, for those new to this world, is not at all the same as digital identity).  I would like to take up the definitions used in the EU Data Protection Directive, which have been nicely summarized here, but add a few precisions.  First, we need to broaden the definition of “indirect identification” by dropping the requirement for unique attributes – as long as you end up with unambiguous identification.  Second, we need to distinguish between identification as a technical phenomenon and personal identification.

This leads to the following taxonomy:

  • Personal data:
    •  any piece of information regarding an identified or identifiable natural person.
  • Direct Personal Identification:
    • establishing that an entity is a specific natural person through use of basic personal data (e.g., name, address, etc.), plus a personal number, a widely known pseudo-identity, a biometric characteristic such as a fingerprint, PD, etc.
  • Indirect Personal Identification:
    • establishing that an entity is a specific natural person through other characteristics or attributes or a combination of both – in other words, to assemble “sufficiently identifying” information
  • Personal Non-Identification:
    • assumed if the amount and the nature of the indirectly identifying data are such that identification of the individual as a natural person is only possible with the application of disproportionate effort, or through the assistance of a third party outside the power and authority of the person responsible… 

Translating to the vocabulary we often use in the software industry, direct personal identification is done through a unique personal identifier assigned to a natural person.  Indirect personal identification occurs when enough claims are released – unique or not – that linkage to a natural person can be accomplished.  If linkage to a natural person is not possible, you have personal non-identification.  We have added the word “personal”  to each of these definitions so we could withstand the paradox that when pseudonyms are used, unique identifiers may in fact lead to personal non-identification… 

The notion of “disproportionate effort” is an important one.  The basic idea is useful, with the proviso that when one controls computerized systems end-to-end one may accomplish very complicated tasks,  computations and correlations very easily – and this does not in itself constitute “disproportionate effort”.

Linkability

If you search for “linkability”, you will find that about half the hits refer to the characteristics that make people want to link to your web site.  That's NOT what's being discussed here.

Instead, we're talking about being able to link one transaction to another.

The first time I heard the word used this way was in reference to the E-Cash systems of the eighties.  With physical cash, you can walk into a store and buy something with one coin, later buy something else with another coin, and be assured there is no linkage between the two transactions that is caused by the coins themselves. 

This quality is hard to achieve with electronic payments.  Think of how a credit card or debit card or bank account works.  Use the same credit card for two transactions and you create an electronic trail that connects them together.

E-Cash was proposed as a means of getting characteristics similar to those of the physical world when dealing with electronic transactions.  Non-linkability was the concept introduced to describe this.  Over time it has become a key concept of privacy research, which models all identity transactions as involving similar basic issues.

Linkability is closely related to traceability.  By traceability people are talking about being able to follow a transaction through all its phases by collecting transaction information and having some way of identifying the transaction payload as it moves through the system.

Traceability is often explicitly sought.  For example, with credit card purchases, there is a transaction identifier which ties the same event together across the computer systems of the participating banks, clearing house and merchant.  This is certainly considered “a feature.”  There are other, subtler, sometimes unintended, ways of achieving traceability (timestamps and the like). 

Once you can link two transactions, many different outcomes may result.  Two transactions conveying direct personal identification might be linked.  Or, a transaction initially characterized by personal non-identification may suddenly become subject to indirect personal identification.

To further facilitate the discussion, I think we should distinguish various types of linking:

  • Intra-transaction linking is the product of traceability, and provides visibility between the claims issuer, the user presenting the claims, and the relying party  (for example, credit card transaction number).
  • Single-site transaction linking associates a number of transactions at a single site with a data subject.  The phrase “data subject” is used to clarify that no linking is implied between the transactions and any “natural person”.
  • Multi-site transaction linking associates linked transactions at one site with those at another site.
  • Natural person linking associates a data subject with a natural person.

Next time I will use these ideas to help explain how specific crypto systems and protocol approaches impact privacy.

Age verification roundup

by Tateru NinoTateru Nino at Second Life Insider has done a roundup of age verification issues arising from Second Life's experiment in controlling access to adult content. 

There's a lot of talk about age/identity verification going on, so I've done a pile of reading of material and logs (thanks for everyone who has provided links, logs and other information to source from) and condensed them into a not inconsiderable bulleted list, below the fold.Longer than your hand, people. Grab a cup of coffee.

  • Credit cards do not provide proof of age. In some areas and with some card providers you can obtain a credit card compatible card before you can talk.
  • Verification costs. It will be available at a token fee for premium account holders, but the brunt of the verification costs apparently will be borne by basic account holders. Linden Lab is passing along the costs of verification.
  • Mobile phones do not provide proof of age. In the UK, more children under 12 possess a mobile phone than adults over 18. In the USA, almost 50% of children have a mobile phone.
  • Driver's licences are not as widely held as you might think. Particularly the old, infirm or handicapped may not possess them. Areas with highly developed public transport systems, or poorer nations may have low penetration of these credentials.
  • Online verification does not verify the person, only the validity of the documentation that person provides. The person need not provide their own documentation for verification to be successful. Therefore, this system can only realistically be used to shift blame and does not constitute a method of verification or trust.
  • The status of a minor who has provided false verification information can (apparently) no longer be contested. If it says they're of a certain age, would it be harassing behavior to attempt to challenge that?
  • Linden Lab is apparently wishes to use a third-party company to keep verification costs down, and to prevent access to or storage of verification information by Linden Lab employees.
  • The age at which you are considered to be permitted to access ‘adult content’ varies from country to country. In most, the age varies between 12 and 25. A very few jurisdictions do not permit it under any circumstances. In most US Jurisdictions the age for the apparent class of adult content Linden Lab intends to grant access to would be 21, not 18.
  • Having taken steps to attempt to verify the age of a user, and then granted them access to adult content, does Linden Lab them become liable if you are still not eligible to be transmitted adult content in your jurisdiction? Does it even matter if the age/identity is accurate or not?
  • The verification provider may not demand or require any information from you. However, they are under no obligation to provide verification for you if you do not willingly provide it.
  • Integrity Services was initially given as the verification provider, however there is good cause to believe that the provider will change before plans go ahead.
  • Merely requesting an SIN identification from a Canadian citizen constitutes a legal offense. This policy may extend to other forms of identifying information in various countries.
  • Linden Lab provides only very vague guidelines for what does and does not constitute ‘adult content’. These are “adult content is that which is overtly, graphically, or explicitly sexual in nature or intensely violent”, which obviously leaves a lot of open questions.
  • The guidelines of most nations are vague on what constitutes adult content. In some cases, certain kinds of political content may fall under this classification. In India, “scenes that are a threat to the integrity to the nation, and those which disturb the friendly peace between nations” are classifiable as adult content.
  • Flagging parcels that contain adult content is mandatory.
  • Adult content flagged parcels must be within Mature sims.
  • It is inevitable that the judgement of an individual based on their own society's and community's standards and norms will unintentionally disagree with the judgement of one or more other residents or Linden Lab staff members. What will happen then? Will Linden Lab exercise editorial control, or assign punishments or penalties?
  • Verification may not be accessible to Linden Lab or verification service employees but must be archived for a period of time that may changed or extended by law before that that period expires. Can it be extended by other means (eg: Company policy?).
  • Archived verification data may be accessed during an audit. Who can initiate an audit of this data, and under what circumstances?
  • Will this archived verification data be subject to the European Union's DPA legislation, as would be required if any EU citizen's data is stored/archived?
  • Do you know what your nation's policy is on providing your passport number to overseas third parties?
  • The Second Life website already requests that users state using a check box that they are over the age of 18. By checking this box, users are making a statement that may be held as truth in a court of law. In short, they can and will be held responsible if this statement is later shown to be untrue. Why is it necessary for Linden Lab to perform an expensive operation like this that appears to only increase their overall legal exposure? What are we missing?

The author concludes:

Whew. What did I miss?

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.

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.

Conciously false technology claims

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.