Category: Laws of Identity

Boys scrap over Facebook

 Jason Calacanis, CEO of Weblogs  and Master of New Media, took the lid off a noisy can of worms this week when he declared Facebook Bankruptcy, exhausted by his facebook chores of responding to endless invitations, requests and guilt trips.  In sum, he says, “Folks have just opted in to another out of control inbox…. I'm opting out.”

This was all too much for Scoble,  whose river of crocodile tears led to “Calacanis can't keep up with Facebook“.  Scoble apparently manages more than 4,000 Facebook friends (including me – I'm down here somewhere) compared to Jason's mere 395, saying, “More of the best names in tech are on Facebook than any other social network I’m on.” and “Facebook is the new business card”.  He sees Facebook as new age marketing.  (Is this why half my homepage consists of Scoble videos? Just kidding…) 

Nestled between the extremes is a piece by Rex Hammock, who I think gets it right when he says, “Facebook is a sandbox I’m playing in — but it has a long way to go before it can hope to be the world I live in.”  Continue reading Boys scrap over Facebook

Time: no one knows you're a CEO

 Lev Grossman's The Price of Anonymity in this week's Time Magazine is interesting partly because of his unforgettable portrait of John Mackey as Marie Antoinette.  But it veers to a draconian conclusion:

As far back as the 1980s, the Internet has been an electronic masked ball, a place where people can play with new identities and get off on the frisson of being somebody else. MIT sociologist Sherry Turkle has argued that this kind of identity-play even has therapeutic value. You certainly can't ascribe a plausible financial motive to Mackey–rahodeb's postings weren't moving stock prices around. This was about just being naughty: picture Mackey chortling as he played the regular rube, like Marie Antoinette dressing up as a peasant and milking cows on the fake farm she built near Versailles. (Mackey was even in drag, sort of–rahodeb is an anagram of his wife's name, Deborah.) Continue reading Time: no one knows you're a CEO

Trustworthy Computing Privacy Award

While working on the Laws of Identity and CardSpace, it seemed that each new idea led inevitably to the next.  I really had no choice in arriving at the concepts that arose.  There was no other way to create an identity layer for the internet.   

But as the issues unfolded, it became clear that the road to be travelled wasn't going to be easy.  In fact, it was going to be hard.  It involved risk.  It required people and organizations to rise to challenges that seemed almost impossible.  It needed profound goodwill.  Do we dare say it required trust?

In the early days, as I shared my conclusions, my colleagues in the blogosphere and the conference rooms would say, “Kim, we don't doubt your personal integrity, or your vision; but surely you can't expect us to believe that Microsoft is really going to back you on this stuff…”

And when I looked coldly at what would be required of Microsoft, I could see that there was probably no large company in the world that could do all the counter-intuitive things necessary for success. 

  • In a world where the erosion of privacy was becoming endemic, I would need a Microsoft relentless in championing privacy. 
  • In a world where you are normally lucky just to get your research funded, I would need a Microsoft that would not only fund but then freely share every aspect of the new technology. 
  • In a world polarized between open-source and inventor-owned software, I would have to ask both sides to work together in a single community for the good of everyone. 
  • Having concluded that the original thinking about Passport broke the laws of identity, I would need a Microsoft willing to admit to the mistake, and show it could learn from it. 
  • Above all, I would need a Microsoft that would let me be completely open about what I was thinking, despite my internal role as an architect.  That was the only way I could speak both to Microsoft and to the rest of the industry, to argue for the changes everyone would need make if we were to be successful. 

The project could not succeed if we failed to achieve any of these.  And then, only after that, you had all the uncertainty associated with the introduction of any new paradigm, and any new product.  I would need a team willing to buy fully into all the architectural tenets, and to defend them with passion while building something eminently usable.

Other than love, there is little that is higher in my estimation than authenticity.  To actually be the architect of identity I was supposed to be, I would have to express what was required, try to find the language, try to build the context.   That's what this blog has been about, transforming itself so that more and more it became a place for me to learn and to work.  

If this has all been a voyage, this week was a milestone.  The interoperability event at the Burton Group's Catalyst conference was stunning (more later).  The combined impact of the open source community and Microsoft and many other companies charging into this new world of Information Cards and claims-based computing was intoxicating.   

But there was a second milestone as well – one which I had never predicted.  And although it seems like a personal one, it really isn't, so I hope you will let me share it with you.

I received an award from my colleagues at Microsoft.  Here's the congratulatory letter:

To: Kim Cameron
From:  Bill Gates and Scott Charney
Re: 2007 Trustworthy Computing Privacy Award

On behalf of Microsoft, we want to congratulate you for your outstanding contributions to Trustworthy Computing during the last year.

In recognition of your efforts – which stem from your passion, determination and leadership – you have been chosen to receive the Trustworthy Computing Privacy Award.  Your work is having a tremendous impact across the company, and has significantly improved customers’ interactions with Microsoft.

Specifically, your Laws of Identity, and the work you are leading on the Identity Metasystem, is establishing the foundation for electronic credentials in the virtual world, and is leading a renaissance for identity solutions.  By placing individuals at the center of trust decisions and establishing contextual frameworks where credentials can be recognized, these laws are able to address security requirements while respecting the privacy needs of individuals.  These seven laws, and the identity metasystem, governed the design of the potentially game-changing functionality of Windows CardSpace.

The Trustworthy Computing Privacy Award is a key achievement that recognizes outstanding contributions in advancing an important company tenet. It acknowledges and rewards individuals and teams who have pioneered noteworthy process improvements and innovations in their pursuit of trustworthy computing.  Receiving the Trustworthy Computing Privacy Award is a level of recognition that only few of our finest employees achieve.  Everyone involved in this project should be extremely proud of this accomplishment.

Congratulations again on your achievement, and congratulations on your efforts.

Sincerely

Bill Gates, Chairman, and

Scott Charney, Corporate Vice President, Trustworthy Computing.

Not only had Microsoft supported my work.  It had risen to the extreme challenges my work set for it.  And this would not have been possible without the contribution of many others, like Scott Charney, who were working to guide Microsoft in the same direction I was. 

I was especially happy to receive the award from Bill Gates, whose vision reaches across every aspect of technology.  He, above anyone else, is the symbol of a Microsoft that “gets” identity, and I thank him very deeply.

I don't normally get into a lot of stuff about Microsoft on the blog, but this award thing has made me stop and think about what she has been willing to do, OSP and all.  I congratulate her on what she has done already, and will continue to do, to move us closer to the identity big bang.

Linkage in “redirect” protocols like SAML

Moving on from certificates in our examination of identity technology and linkability, we'll look next at the redirection protocols – SAML, WS-Federation and OpenID.  These work as shown in the following diagram.  Let's take SAML as our example. 

In step 1, the user goes to a relying party and requests a resource using an http “GET”.  Assuming the relying party wants proof of identity, it returns 2), an http “redirect” that contains a “Location” header.  This header will necessarily include the URL of the identity provider (IP), and a bunch of goop in the URL query string that encodes the SAML request.    

For example, the redirect might look something like this:

HTTP/1.1 302 Object Moved
Date: 21 Jan 2004 07:00:49 GMT
Location:
https://ServiceProvider.com/SAML/SLO/Browser?SAMLRequest=fVFdS8MwFH0f7D%
2BUvGdNsq62oSsIQyhMESc%2B%2BJYlmRbWpObeyvz3puv2IMjyFM7HPedyK1DdsZdb%........2F%
50sl9lU6RV2Dp0vsLIy7NM7YU82r9B90PrvCf85W%2FwL8zSVQzAEAAA%3D%
3D&RelayState=0043bfc1bc45110dae17004005b13a2b&SigAlg=http%3A%2F%
2Fwww.w3.org%2F200%2F09%2Fxmldsig%23rsasha1&
Signature=NOTAREALSIGNATUREBUTTHEREALONEWOULDGOHERE
Content-Type: text/html; charset=iso-8859-1

The user's browser receives the redirect and then behaves as a good browser should, doing the GET at the URL represented by the Location header, as shown in 3). 

The question of how the relying party knows which identity provider URL to use is open ended.  In a portal scenario, the address might be hard wired, pointing to the portal's identity provider.  Or in OpenID, the user manually enters information that can be used to figure out the URL of the identity provider (see the associated dangers).

The next question is, “How does the identity provider return the response to the relying party?”  As you might guess, the same redirection mechanism is used again in 4), but this time the identity provider fills out the Location header with the URL of the relying party, and the goop is the identity information required by the RP.  As shown in 5), the browser responds to this redirection information by obediently posting back to the relying party.

Note that all of this can occur without the user being aware that anything has happened or having to take any action.  For example, the user might have a cookie that identifies her to her identity provider.  Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by.  (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on — trust us…)

Since the identity provider is tasked with telling the browser where to send the response, it MUST know what relying party you are visiting.  Because it fabricates the returned identity token, it MUST know all the contents of that token.

So, returning to the axes for linkability that we set up in Evolving Technology for Better Privacy, we see that from an identity point of view, the identity provider “sees all” – without the requirement for any collusion.  Knowing each other's identity, the relying party and the identity provider can, in the absence of appropriate policy and suitable auditing, exchange any information they want, either through the redirection channel, or through a “back channel” that dispenses with the user and her browser altogether. 

In fact all versions of SAML include an “artifact” binding intended to facilitate this.  The intention of this mechanism is that only a “handle” need be exchanged through the browser redirection channel, with the assumption that the IP and RP can then hook up and use the handle to “collaborate” about the user without her participation.

In considering the use cases for which SAML was designed, it is important to remember that redirection was not originally designed to put the “user at the center”, but rather was “intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent… for example, if the communicating parties do not share a direct path of communication.”  In other words, an IP/RP collaboration use case.

As Paul Masden reminded us in a recent comment, SAML 2.0 introduced a new element called RelayState that provides another means for synchronizing or exchanging information between the identity provider and the relying party; again, this demonstrates the great amount of trust a user must place in a SAML identity provider.

There are other SAML bindings that vary slightly from the redirect binding described above (for example, there is an HTTP POST binding that gets around the payload size limitations involved with the redirected GET, as Pat Paterson has pointed out).  But nothing changes in terms of the big picture.  In general, we can say that the redirection protocols promote much greater visibility of the IP on the RPs than was the case with X.509. 

I certainly do not see this as all bad.  It can be useful in many cases – for example when you would like your financial institution to verify the identity of a commercial site before you release funds to it.  But the important point is this:  the protocol pattern is only appropriate for a certain set of use cases, reminding us why we need to move towards a multi-technology metasystem. 

It is possible to use the same SAML payloads in more privacy-protecting ways by using a different wire protocol and putting more intelligence and control on the client.  This is the case for CardSpace in non-auditing mode, and Conor Cahor points out that SAML's Enhanced Client or Proxy (ECP) Profile has similar goals.  Privacy is one of the important reasons why evolving towards an “active client” has advantages.

You might ask why, given the greater visibility of IP on RP, I didn't put the redirection protocols at the extreme left of my identity technology privacy spectrum.  The reason is that the probability of RP/RP collusion CAN be greatly reduced when compared to X.509 certificates, as I will show next.

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.   

The European e-Identity Conference

I don't often mention my speaking agenda, but next week I'll be giving the opening keynote at a conference in Paris that looks like a great opportunity to exchange information.  It is hosted by EEMA (which has morphed into the European Association for eIdentity and Security) and ENISA (the European Network and Information Security Agency).  If you've been sitting on the fence, it looks like the conference has really come together. Here's the program.

One track is called “managing identity” (in the largest sense) with presentations about architecture and application development approaches by Siemens, SEALED and SAP.  It includes roundtables on interoperability, security-identity interfacing and SOA. 

The other track is on “social networking” with presentations on Netlog and Facebook, and a fascinating series of roundtables on a nice taxonomy of reputation issues.

And that's just day one!  Day two is huge. 

Nick Shelness on CardSpace

The strangest thing just happened.  I was following a link that had just appeared from vowe.net  – a site published by Volker Webe.  An interesting site, for sure – and on it, I read this piece by Nick Shelness:  

Establishing identity and authenticating on the web are a mess. I doubt I’m alone in using the same user id and password over and over again. If they’re hacked once they can be employed a hundred times over. Yeah, some sites make you change your password at regular intervals, but how do you remember them? I write them down, and carry them with me. OK, they’re somewhat encoded, but …

For some time now, there has been the possibility of improvement under the “Identity 2.0” banner. To the surprise of some (many?), a significant chunk of Identity 2.0 innovation has come from Microsoft, and no, no, no, it’s not “Passport”. It is expressed in two seminal papers: The Laws of Identity and The Identity Metasystem, both by Kim Cameron.

But this is not all. There is a Microsoft product. It’s called “CardSpace” (it used to be called “Info Card”). It ships as part of Vista. It also ships as an automatic XP upgrade, and there are a host of alternatives, including open source ones.

CardSpace and its analogues, on their own, are not a solution. They are a component, albeit a key one, of an Identity Metasystem. What needs to come next is for web sites (“Relying Parties”) to start requesting and employing CardSpace-managed security assertions. This in turn will create a demand for Identity Provision (yes, this is where ActiveDirectory and son of Passport come in).

Will this happen? It’s too early to say. But by seeding the digital world with CardSpace, Kim and Microsoft have taken us a long first step down this path, and IMHO done us all a big favor.

It took me a minute to click in to the name Nick Shelness.  He is a great visionary – CTO at Lotus and later an IBM fellow (now with his own practice in the UK).  His support means a lot to me. 

As for his “will it happen?” question, I've asked it too on a hundred ‘bleak and dreary days’.  But I continue to think there are historical inevitabilities at work here.  

Distributed computing is dammed up behind a wall of identity friction.  The one good thing about the friction is that it limits phishing and cyber crime as much as it limits business.  Remove the friction with something like single sign-on and you massively increase the attraction of the digital honeypot, providing a one-stop attack surface for evil.  The more consolidated identity initiatives succeed, the more they will fail – unless there is a paradigm change like CardSpace that compensates for risk aggregation.  

Few may understand these dynamics through theory alone, but Professor Reality will come to tutor them before too long.  Meanwhile, there are more and more people with enough vision that they don't have to “go over Niagra Falls in a barrel to know it hurts.” 

Day after day, week after week, month after month, CardSpace “sockets” are appearing on desktops.  One day – not too far into the future – it will be present on 50% of them.  Then on 75%!  Meanwhile the software will get slicker and slicker, with multiple versions and choices by people like our friends at Higgins running on Mac and Linux.  This is a historic thing we are doing together, and we can't be impatient.  But this baby is going to light up big time.

Separation of powers

Paul Madsen is being his amusing self over at ConnectID:

Doesn't the principle of ‘Separation of Powers‘ forbid Kim playing both the legislative and judicial roles, i.e. writing the ‘laws’, and then adjuticating on compliance?

Certainly makes for efficient government.

To which Eric Norman replies:

Well, it never stopped Murphy from sitting in judgement about his law.

Of course this is all about what I claim are laws of computer science, not legal edicts, and the phenomena described are measurable.  We should really end up agreeing about how systems behave, even if we finally disagree about how they should behave. 

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.