Identity versus attributes

I’ve had several conversations recently, including one at the TERENA/EMC2 (higher education federation) workshop in Rome yesterday, which suggest that we are gradually overcoming some of the adoption barriers to attribute-based authorisation.

That might sound a bit dry and esoteric, but actually it’s a Good Thing, and intuitively simple. To try and put it in a nutshell: for an awful lot of service access decisions, it’s not actually important to know who the service requester is – it’s usually just important to know some particular thing about them. Here are a couple of examples:

  • If someone wants to buy a drink in a bar, it’s not important who they are, what’s important is whether they are of legal age;
  • If someone needs a blood transfusion, it’s more important to know their blood type than their identity…

In the past, of course, unique identifiers have been used as a way to index that attribute data. You tell me who you are, and I’ll look up the record which associates that identity with all the attribute data I hold about you. Then I’ll make an entitlement/access control decision based on that information.

For understandable reasons, that approach tends to lead to a very disclosure-heavy design. If the first thing I have to provide you with is the index to all the data you hold about me, every request for a service implicitly unlocks everything about me, rather than only that information relevant to this request. In simple and/or hierarchical relationships, and when communication between multiple parties is difficult or impossible, this is a rational (and sometimes perhaps the only) way to do things.

However, the internet undermines some of those assumptions: online service provision relationships are often neither simple nor hierarchical; multi-party communication and transactions are the norm.

The problem is, we’ve ended up by default with the worst of both worlds. We have all the disclosure-heaviness of the previous model, plus the promiscuous communication of the web. And that’s why I think the increasing awareness of attribute-level assertion is so important. It offers far better ways of having multi-party transactions take place with selective disclosure of the user’s data.

That’s not to say that attribute-level assertions are the panacea. There are still knotty problems to resolve, even if we adopt that approach; for instance:

  • managing user consent and control;
  • making selective disclosure appropriate to each given context;
  • defining and enforcing ‘sticky policy’, to protect users’ preferences even after the data has been disclosed;
  • catering for transactions which involve multiple different levels of assurance;
  • defining appropriate metaphors to represent all this to the user…
  • … and so on.

But the signs are positive. Awareness that attribute-level assertions are a key component is a vital first step, and it is heartening to see that awareness rising and becoming increasingly widespread.


5 thoughts on “Identity versus attributes

  1. I think there is an important difference between your two examples. Blood transfusion is a transaction with longer-lasting consequences. If a batch of blood is contaminated, there seems to be a legitimate requirement to trace forwards (who received this blood) and backwards (who donated this blood), in order to limit the consequences of this contamination event and to prevent further occurrences.There is a strong demand for increasing traceability. In manufacturing, we want to trace every manufactured item to a specific batch, and associate each batch with specific raw materials and employees. In food production, we want to trace every portion back to the farm, so that salmonella outbreaks can be blamed on the farmer. Transactions that were previously regarded as isolated ones are now increasingly joined-up. The eggs that went into your custard tart used to be anonymous, but in future they won't be.Of course, there is also a strong demand for increased auditability. So it is not enough for the barman to check the drinker's age, the barman must keep a permanent record of having diligently carried out the check. It is apparently not enough for the hotel or bank clerk to look at my passport, they must retain a photocopy of my passport in order to remove any suspicion of collusion. (The bank not only mistrusts its customers, it also mistrusts its employees.)The point is that authorization is not an isolated event, but is embedded in a larger system, and it is this larger system that apparently requires greater disclosure and retention.

  2. Very good post Robin. I like to go one step further and question the orthodoxy which insists on authenticating first and authorising second, as if one cannot have authority without being held to a singular identity. I believe that we *really* have multiple, separate identities, and that it is unhelpful to always insist that attributes must hang off a true identity. For instance, my identity as a business bank account holder is separate (both psychologically and legally) from my identity as a personal bank account holder. And my identity as an anonymous participant in an online psychiatric counselling session must absolutely be separate from any Unique Health Identifier I might have in general practice or public health info systems. I'd like to see acceptance of "identity plurality" as a deeper way of looking at identity management. Cheers, Stephen.

  3. While I agree with most of Richard Veryard's specific examples of cases needing traceability, I am very reluctant to extend the reasoning in such a way that would see all authorisations intrinsically linked to a purportedly "true" authentication of one primary identity (for reasons I expand upon on elsewhere). The *general* case (general in the mathematical sense) is where a person is abel to exercise multiple identities, each of which has attributes. Lots of transactions, like moving around a large sum of money, or donating blood, will have rules that require involvement of a traceable phyical identity, but many others will not, such as making small cash-like purchases, participating in social networking (especially the new medical social networking) etc etc. Cheers, Stephen.

  4. In answer to Stephen, my point was that there is a large (and growing) class of situations where so-called joined-up-thinking seems to require the negation of privacy. I am certainly not saying that this reasoning should always trump the needs of privacy. But privacy campaigners need to understand that all transactions belong within some system of systems, and that this provides the context for the forces they are battling against, rather than pretending that transactions can be regarded as purely isolated events.

  5. a jangbrand says:

    Something to consider as well is how long chains to use for traceability. Should we also know the batch number for the food that was given to the chicken that laid the egg you included in the cake? What "length" of traceability is sound and meaningful? How do we connect all these traces?And also time is of interest. For how long should records be kept? Do we have to know the identity of the blood donour after six months? 10 years? 100 years?Of course some attributes might be of interest to "keep" or "trace" for longer periods of time. And also backward and forward in the "chain".

Comments are closed.