In response to Carolyn's comment on the "Future of Identity and Privacy" post, I thought it might be useful to give a little more information about the "Ladder" model I've been using as part of the Privacy Summits. Originally this came out of a discussion with my friend and colleague Peter Lord, of Oracle. The diagram we used to summarise our discussions looked like this:
What we had been trying to do was engage in a productive discussion about the 'high-level' concepts at the top of the 'ladder', with participants from a very wide range of backgrounds, including technical and non-technical ones. What we observed was that it was very easy to set off with the assumption that some technology or other was the right starting point... for example, perhaps smart cards, or cryptography, or whatever. What we then found was that each technology brought along with it a set of concepts and functional capabilities which invariably imposed constraints on the subsequent discussion. Quite unintentionally, in most cases, the mere fact that you start off by saying, for instance, "oh, this is the kind of problem which cryptography can solve" in itself limits the rest of the conversation.
In other words, thinking about it graphically, the result is a 'stovepipe' discussion which progresses up the ladder but never widens. As a result, you may find you address one of the high-order topics, but exclude the others.
As usual, the first step towards fixing this problem was to become aware of what the problem was.
The second step was to acknowledge that, while any given techno-centric approach was unlikely to answer the whole range of 'high level' questions, it was equally likely to have a valid place as part of the solution. That being so, we needed to find a way of taking each participant's input, assuming that it had a valid place somewhere in the discussion, and factoring it in at the appropriate time and place.
This second diagram illustrates some of the different kinds of contribution one might get in the course of a discussion; the trick was to be able to find the right place to note each contribution, so that it could be revisited at the appropriate point.
I think it's fair to say that each successive summit has not only taught us more about the multi-stakeholder approach, it has also validated that approach and confirmed that the models we have developed are a robust foundation on which to build. I hope that in publishing them in the London/Basel summit report, we have contributed something which the identity and privacy communities will find valuable and useful over the coming months.
![[RSS Newsfeed]](/themes/sotto/images/valid-rss.png)
![[This is a Roller site]](/themes/sotto/images/roller-logo.gif){kind=logo}
Thanks, Robin. This helps.
Posted by Carolyn on October 22, 2008 at 08:34 PM GMT+00:00 #
Good diagram. Being from the 'if you can say it on one diagram, you probably understand it' school, this looks useful. Any chance that the top layer - which has the all 'interesting stuff' after all - could be given more structure? Also, some way of linking layers together? C'mon Robin, all that time on planes, you've gt lots of time to think deep thoughts.
Posted by Ian Mitchell on October 23, 2008 at 07:17 AM GMT+00:00 #
Thanks Ian ... and *after* breakfast...? ;^)
Actually, one answer (and this is not a cop-out, onnist) is that the top layer is intentionally left vague for the Summits, because I don't want to constrain what people discuss. Some of the most interesting bits of intelligence have come out of that 'free-form' aspect.
As for linking the layers together, I think there are a couple of ways in which that will happen (bearing in mind that the Summits have really been a glorified requirements definition exercise...): first, in the design/architecture phase, having a model like the ladder should mean that multiple design perspectives are more effectively incorporated.
Second, in the implementation phase I think it should lead to a better balance between the technical and non-technical elements of a solution, and a clearer understanding of the success criteria. For instance, if you decide that data breaches are best protected against by predominantly technical measures, you'll end up with one set of success metrics; if you decide the best countermeasure is actually a policy control, your success metrics will be quite different.
At the moment I think those kinds of factor are often either ignored or left implicit on the assumption that 'someone's keeping an eye on them'. this way, it's clearer who the major stakeholder is, and therefore who has it in their interest to monitor the success metrics...
Hope this helps...
Posted by Robin Wilton on October 24, 2008 at 12:17 PM GMT+00:00 #