Ben Laurie blathering

6 Apr 2008

Conflicting Roles

Filed under: Identity Management,Security — Ben @ 23:51

Pamela Dingle writes about the problems of people having conflicting roles. Funnily enough I’m working on a paper about roles, too, but more on that later. Right now I wanted to observe that the problem she describes

There is no simple way to say that John is a broker 100% of the time, but 50% of the time he represents Client A and only Client A, and the other 50% he solely represents Client B. There is no way to represent mutual exclusivity of roles in a single user profile (that I’m aware of).

can handled in an interesting way in SE-Linux: there you can make the rule that once the user (or rather, a program acting on behalf of the user) has accessed any resource corresponding to Client A he is no longer allowed to access resources corresponding to Client B, and vice versa. Of course, leaping from this to the idea that you’ve built a real Chinese Wall between the two clients is falling foul of one of the fallacies of DRM: of course the user can find ways to transport data across that wall. But, nevertheless, SE-Linux is a system in which it is possible to express such policies.

25 Mar 2008

Federated Messaging Meets Federated Identity

Filed under: Distributed stuff,Identity Management — Ben @ 23:51

XMPP, OAuth and OpenID. Social networking in real-time. Interesting. Peter Saint-Andre thinks we should talk about it.

Sign up here.

20 Mar 2008


Despite Kim’s promise in his blog

That doesn’t mean it is trivial to figure out the best legal mecahnisms for making the intellectual property and even the code available to the ecosystem. Lawyers are needed, and it takes a while. But I can guarantee everyone that I have zero intention of hoarding Minimal Disclosure Tokens or turning U-Prove into a proprietary Microsoft technology silo.

Like, it’s 2008, right? Give me a break, guys!

I’ve now heard through several different channels that Microsoft want to “ensure interoperability”. Well. Interoperability with what, I ask? In order for things to be interoperable, they must adhere to a standard. And for Microsoft to ensure interoperability, they have to both licence the intellectual property such that it can only be used in conformance to that standard and they have to control the standard.

I don’t know about you, but that sure sounds like a “proprietary Microsoft technology silo” to me.

6 Mar 2008

Microsoft Buys Credentica

Kim and Stefan blog about Microsoft’s acquisition of Stefan’s selective disclosure patents and technologies, which I’ve blogged about many times before.

This is potentially great news, especially if one interprets Kim’s

Our goal is that Minimal Disclosure Tokens will become base features of identity platforms and products, leading to the safest possible intenet. I don’t think the point here is ultimately to make a dollar. It’s about building a system of identity that can withstand the ravages that the Internet will unleash.

in the most positive way. Unfortunately, comments such as this from Stefan

Microsoft plans to integrate the technology into Windows Communication Foundation and Windows Cardspace.

and this from Microsoft’s Privacy folk

When this technology is broadly available in Microsoft products (such as Windows Communication Foundation and Windows Cardspace), enterprises, governments, and consumers all stand to benefit from the enhanced security and privacy that it will enable.

sound more like the Microsoft we know and love.

I await developments with interest.

28 Feb 2008

A Concrete Proposal

Filed under: Crypto,Identity Management,Security — Ben @ 20:56

Kim wants to help, and Pat Patterson puts flesh on the bones of my proposal in an infocards context.

To summarise Pat’s proposal, what happens is you go to wherever you want to log in, you fetch your username/password for that site from your IdP, encrypted using the public key for that site. That way, only the IdP and the site know the password. I’m pretty impressed that this can be done without modifying the WS-* protocols, but there’s still a little work left to be done…

In particular, we’re presumably going to be migrating to this from an existing login – in the process we should change the password from whatever phishable nastiness was in use to a nice strong, random password. Or one derived from a master password and the site’s name. Failure to do this would not improve the phishing situation.

Also, if we use the latter scheme, we can eliminate the IdP and do the whole thing locally, using the master password. This gives you portability (without worrying about the grander problem of porting all credentials) for free.

And, of course, this all needs to happen without much work or comprehension on the part of the user. But it’s definitely a step in the right direction!

26 Feb 2008

Not The Browser!

Filed under: Crypto,Identity Management,Security — Ben @ 19:39

Kim correctly observes that the browser is not the place to be typing your password. Indeed. I should have mentioned that.

Clearly any mechanism that can be imitated by a web page is dead in the water. Kim also wants to rule out plugins, I take it, given his earlier reference to toolbar problems. I’m OK with that. We want something that only a highly trusted program can do. That’s been so central to my thinking on this I forgot to mention it. Sorry.

Get Real

Filed under: Crypto,Identity Management,Security — Ben @ 15:08

Kim Cameron, bless him, manages to interpret one of my most diabolical hungover bits of prose ever. I am totally with him on the problem of pharming, but the reality is that the average Cardspace user authenticated with nothing better than a password (when they logged into Windows). Furthermore, if you are going to achieve portability of credentials, then you can either do it in dreamland, where all users carry around their oh-so-totally-secure bluetooth credential device, or you can do it in the real world, where credentials will be retrieved from an online store secured by a password. And yes, we’ll encourage people to make sure that’s a passphrase, and they don’t type it in in web cafes, and all that. And the corporate VPN types will use SAML and doohickeys with keypads. And maybe if they’re really smart the “online store” will actually be a USB stick and a backup split between a few of their best friends.

But we have a simple mission: protect that password.

If you believe the Cardspace UI can protect people’s credentials, then surely it can protect a password?

If it really can’t (that is, we cannot come up with UI that people will reliably identify and eschew all imitations), then how will we ever have a workable, scalable system that includes recovery of credentials after loss or destruction of their physical goods?

25 Feb 2008

If You Have Cardspace, Why Use OpenID?

Filed under: Anonymity/Privacy,Identity Management,Security — Ben @ 14:31

Kim Cameron writes about fixing OpenID’s phishing problems by using Cardspace. Certainly I agree that using strong authentication to the OpenID provider fixes the phishing problem – but if you have strong authentication, why bother to use OpenID at all? Why not strongly authenticate to the site you are really trying to log into, instead?

Of course, Cardspace is a pretty heavyweight solution for this, so perhaps that’s what Kim’s getting at? It also doesn’t work well if you have more than one machine – moving your credentials around is not something Cardspace does well.

In my view, there’s a sweeter spot for solving this problem than Cardspace (or OpenID, obviously) – and that is to do strong authentication based purely on a password. That way, you can use the same password everywhere, so no problem with moving between machines, but can still resist phishing attacks and don’t have to make yourself linkable across all sites. Obviously supporting this would be way easier than taking the whole of Cardspace on board, but would have all of the immediate advantages. Clearly it would get you nowhere with advanced identity management, but its not like we don’t already have protocols for that and nor does there seem to be much demand for it yet.

23 Feb 2008


Filed under: Distributed stuff,Identity Management,Security — Ben @ 13:38

Pamela is freaked out by sites that gather all your logins. So am I. But this is exactly why a group of us got together to create OAuth. OAuth allows you to delegate access to your various accounts without revealing your username and password. All we need now is for all these sites to start using it.

13 Jan 2008

Be Careful With The Social Graph

Filed under: Anonymity/Privacy,Identity Management,Security — Ben @ 19:50

Bob Blakley is concerned that if we open up the social graph, then we’ll kill social networking (if I were you I’d skip the rather complicated and irrelevant analogy he kicks off with: to mangle my friend Jennifer Granick‘s oft-given advice, we should talk about the thing itself and not what it is like). His core point is that its not OK for Scoble to move his relationship data from one system to another because he doesn’t own that data – it is jointly owned by him and those with whom he has relationships.

Whilst I agree that it may not be OK to move such data around, I think Bob is wrong about the details. Plus he picked a terrible example: it hardly matters what Scoble did with his friends list because anyone can already see it.

And this precisely illustrates what seems most important to me: when I share social data, I do so under certain conditions, both explicit and implict. What I care about, really, is that those conditions continue to be met. I don’t really mind who does the enforcing, so long as it is enforced. So, it seems to me that its OK to create the social graph, you just have to be exceedingly careful what you do with it.

This presents two, in my view, enormous technical challenges. The first is dealing with a variety of different conditions applying to different parts of the graph. Even representing what those conditions are in any usable way is a huge task but then you also need to figure out how to combine them, both when multiple conditions apply to the same piece of data (for example, because you figured it out twice in different ways) or when the combination of various pieces of data, each with its own conditions, yield something new.

Once you’ve done that you are faced with a much larger problem: working out what the implicit conditions were and enforcing those, too. The huge adverse reaction we saw to Facebook’s Beacon feature shows that such implicit conditions can be unobvious.

Anyway, the bottom line is that those in favour of the social graph tend to see it as some nodes, representing people, and edges, representing relationships. What they ignore is the vast cloud of intertwined agreements and understandings woven around all those edges and nodes. But those are absolutely vital to the social graph. Without them, as Bob says

Opening the social graph will destroy social networks, and turn them into sterile public spaces in which formation of meaningful and intimate relationships is not possible.

So, by all means, open the social graph but do it really carefully.

One thing I’ll note in passing: it is very common, in human relationships, to reveal far more than you are supposed to – under condition that the recipient of the revelation maintains absolute secrecy about it. For example, everyone knows that Alice is bonking Bob except Alice’s husband and Bob’s wife. This is because a series of “absolute secrecy” conditions and careful thought have neatly partitioned the world with respect to this piece of information. Usually. Should a good social graph emulate this?

12 Jan 2008

Me-ville Versus The Global Village

Thanks to Adriana, I just came across an intriguing post on VRM. In it, two completely different versions of VRM are presented (he thinks he presented four, but I claim that the “vendor control” end of the spectrum is CRM, not VRM).

In Me-Ville, everything is anonymous and reputation/value-based. In the Global Village, its all about long-term relationships. I think this divide is interesting and sums up the differences in the approach taken by techies, like Alec Muffett and me versus the approach the fluffier, social people like Adriana Lukas and Doc Searls would like to take.

Who’s right? Well, normally I’d say I am, but I’m not sure I really know in this case. But recognition is the first step towards reconciliation.

16 Dec 2007

Is IdP Discovery The Next Big Thing?

Filed under: Identity Management,Security — Ben @ 18:57

I’ve been thinking. Even though us fans of user-centric identity like to think of it all being in the hands of individual users, it seems to me that in practice many users will delegate management of their identity data to a third party. They’ll do this for a variety of reasons, the main one being convenience, though the need to be always on may be a driver in the end, too.

So this leads to an interesting question: when I first arrive at a site, how does it know who I’ve chosen to be my IdP? When I turn up at Unicorns-R-Us, how do they know that they should go to Amazon to verify that I’m logged in and that I’m the same guy as shopped there last time?

This question is, of course, the question of IdP discovery, and although we’re not worrying about it much right now (at least in the user-centric world – I know Liberty has worried about it forever), I predict that we’ll be worrying about it a lot, Real Soon Now.

But why is it an issue? There seem to be all sorts of obvious options…

1. The OpenID approach: you (the user) give a URL to Unicorns-R-Us, and at that URL can be found further information about your identity. Clunky and weird for the average user.

2. Cookies. The first time you visit Unicorns-R-Us some miracle occurs that informs them I am an Amazon user and they set a cookie so they’ll always know in future. Two problems here, the first being that we still have that first encounter to solve and the second being that this works fine until you switch to my laptop and then you’re screwed.

3. Client-side component. This works well, and solves the first encounter problem, but still suffers from the issue of me switching to a machine without the component installed – or with it installed, but not yet initialised. Will I know how to initialise it, since that’s probably something I’d only do once a year or so? It can’t be too easy, or that’s clearly a security risk.

I’m starting to run out of ideas here, and so far none of them have worked really well. I suspect that in the end we’ll end up with the OpenID approach (“ask the user”) but with something more friendly than a URL and with a flow that often requires no effort on the part of the user. But its an interesting question that I don’t have a good answer to – and a good answer is key to a user-centric identity world.

I predict that figuring out standards and a good user experience around this problem will be one of the major pieces of the user-centric identity puzzle over the next couple of years.

23 Nov 2007

Can HMRC and NAO Protect Their Own Data?

Filed under: Identity Management,Security — Ben @ 13:14

(Update: an ORG colleague correctly points out I should say “redacted” not “elided” – thanks, Louise!)

In the wake of the HMRC disaster (nicely summarised by Kim Cameron), the National Audit Office has published scans of correspondence relating to the lost data.

First of all, it’s notable that everyone concerned seems to be far more concerned about cost than about privacy. But an interesting question arises in relation to the redactions made to protect the “innocent”. Once more, NAO and HMRC have shown their lack of competence in these matters…

A few years ago it was a popular pastime to recover redacted data from such documents, using a variety of techniques, from the hilarious cut’n’paste attacks (where the redacted data had not been removed, merely covered over with black graphics) to the much more interesting typography related attacks. The way these work is by working backwards from the way that computers typeset. For each font, there are lookup tables that show exactly how wide each character is, and also modifications for particular pairs of characters (for example, “fe” often has less of a gap between the characters than would be indicated by the widths of the two letters alone). This means that if you can accurately measure the width of some text it is possible to deduce which characters must have made up the text (and often what order those characters must appear in). Obviously this isn’t guaranteed to give a single result, but often gives a very small number of possibilities, which can then be further reduced by other evidence (such as grammar or spelling).

It seems HMRC and NAO are entirely ignorant of these attacks, since they have left themselves wide open to them. For example, on page 5 of the PDF, take the first line “From: redacted (Benefits and Credits)”. We can easily measure the gap between “:” and “(“, which must span a space, one or more words (presumably names) and another space. From this measurement we can probably make a good shortlist of possible names.

Even more promising is line 3, “cc: redacted@…”. In this case the space between the : and the @ must be filled by characters that make a legal email address and contain no spaces. Another target is the second line of the letter itself “redacted has passed this over to me for my views”. Here we can measure the gap between the left hand margin and the first character of “has” – and fit into that space a capital letter and some other letters, no spaces. Should be pretty easy to recover that name.

And so on.

This clearly demonstrates that those who are entrusted with our data have absolutely no idea of the threats it faces, nor the countermeasures one should take to avoid those threats.

5 Nov 2007

Self-issued Cards Are More Secure

Filed under: Anonymity/Privacy,Identity Management,Security — Ben @ 21:01

Pamela Dingle takes some Liberty dudes to task for being obsessed with the letter of the spec. Her, perfectly reasonable, stance is that if she chooses to link a self-issued infocard to her bank account, then that’s at least as secure as any other means we know of for authenticating. Of course, she’s left out of this equation how she gets to make that association, and, of course, the Liberty dudes think you should only make such associations via the middleman of some kind of certificate issuer.

But there’s no reason to involve any card issuers in this at all – we have to have a relationship with the bank to get this off the ground in the first place, regardless of authentication mechanism, and, however that relationship works, we can use it to inform the bank about our self-issued card. Once we’ve done that we have strong authentication with the bank, no need for IdPs, CAs or any of that stuff. In fact, our authentication is stronger than if we had involved a third party – with a self-issued card, no-one else is in a position to make a forgery.

And, of course, we’ve removed a potential correlator of our activities from the equation. Score one for privacy.

1 Oct 2007

Ben vs. Bandit, Part 2

Filed under: Identity Management,Open Source,Programming — Ben @ 10:31

As I previously wrote, I’ve been trying to get Bandit’s identity selector to work on FreeBSD. The good news is: I succeeded (with the burning of some midnight oil and the assistance of Dale Olds). The bad news is that it is a bit fragile.

Anyway, here’s how. First off, gnome-keyring-deamon has to be running. If you are running Gnome, then no doubt there’s some cute way to do it, but I’m not (for what it’s worth, I’m currently using XFCE4 as my desktop). So, I have to start it by hand (my shell is bash, btw – if you use a csh-like shell, you’ll need to do something slightly different)

eval `gnome-keyring-daemon`

Obviously one should script this for daily use – and, of course, you need to share the same daemon across all your shells. Next, you need digitalme, built in the last phase, somewhere on your path. Then run firefox (in such a way that it sees the keyring daemon environment variables you just set), install the XPI, if you haven’t already, and follow the instructions to test it. Or, if you want to win an iPhone, follow this process instead.

There some possible pitfalls. If you run digitalme when the keyring daemon is not running, then you have shot yourself in the foot; digitalme creates its card store and expects to store some corresponding magic in a keyring it creates. If the daemon isn’t running, the store is created, but not the corresponding keyring, and it never recovers. The answer is to delete ~/.iss, where the card store is, and start again.

A second way you can go wrong is when you create the information card: you might expect Bandit to automagically grab it and save it, but it doesn’t – you have to save the card to disk and manually import it into digitalme. I’m told this will be fixed at some point.

Thirdly, the first time you try to use the card it isn’t linked to your account, so it appears to fail. Read the screen carefully – it should be offering to set the link up.

Finally, and the most annoyingly – on FreeBSD at least, gnome-keyring-daemon is weirdly flaky. It just randomly stops running, sometimes before you’ve even got Firefox started. When this happens you have no option but to restart both it and Firefox – and, if you’re unlucky, you will have caused the first of these problems and will have to delete the card store.

As you can see it’s all a bit of a hack at the moment, but at least it works. The only real issue, other than rough edges, is the flaky keyring daemon, which I am trying to debug now.

29 Sep 2007

More on Cardspace and Passport, or, A Day in the Life of an Open Source Developer

Filed under: Identity Management,Open Source,Programming — Ben @ 19:02

Dale Olds is surprised. It seems mean to leave him in this state, though it seems somewhat ironic that an open source project should be choosing a thoroughly closed phone as a prize. So closed you can’t even install closed source add-ons. I’d rather have an N95, to be honest.

So, the first thing I should say is that I used the word “consumer” rather ill-advisedly. I blame OAuth, which I have been working on recently – it uses “consumer” for one of the roles in the protocol, so the word is on my mind. What I should have said was that there are few relying parties for OpenID of any significance (at least that are prepared to rely on anyone but themselves).

But OK, that aside, let’s see if I can win this phone! First off, Dale says I should read a press release. Yep, OK, Novell want us to be more aware of information cards. They also want us to know that we can do the whole thing with open source. This is, of course, fantastic. So, let’s have at it.

First off, I’m sent to the “Bandit Cards” home page. Apparently I can win an iPhone by merely getting hold of a Bandit Card – I’ll be entered into a draw. Hmm, shame, means I’m relying on luck and not my ‘4337 h4x0r sk1llz. OK, so I follow the link to create an account.

Bandit Create Account Page

OK, so let’s download one of those things.

Bandit Download Page

Hmm. No FreeBSD there, but that’s OK, this is open source. Surely I can build it. After a bit of poking around, I find a download page, from which I can retrieve a source RPM. Now, FreeBSD doesn’t understand RPMs out of the box, but it seems there’s a converter, so one quick portinstall rpm2cpio and a little bit of futzing later and I should be good to go…

[ben@euphrates ~/software/unpacked/digitalme-0.3.846]
$ ./configure
cmake: not found

Not come across cmake before, but FreeBSD’s ports system is at hand, as usual, and happily installs it for me. There, sadly, the fun appears to end:

-- Release DigitalMe build.
CMake Error: Command "/usr/local/bin/svn info /home/ben/software/unpacked/digitalme-0.3.846" failed with output:
svn: '/home/ben/software/unpacked/digitalme-0.3.846' is not a working copy

Well, quite so, it is not a working copy, because it is an RPM! However, a bit of poking suggests that this error is not as fatal as it seems – though a later error is

-- Could not find GLib
-- Gnome Keyring not found.
CMake Error: Unable to find a secret store provider.
-- Configuring done

Is it just me, or is this rather misleading? The configuration appears to have failed, since there are no Makefiles, but it completes as if all was well. In any case, this is beginning to get a bit painful, but once more, after a bit of futzing (in CMakeModules/FindGLib.cmake and CMakeModules/FindGnomeKeyring.cmake) I manage to get it to find Glib and Gnome Keyring and we move on to the next problem

-- Looking for GTK2 ...
-- Unable to find GTK2_gdk_CONFIG_INCLUDE_DIR
CMake Error: Could not find GTK2
-- Configuring done

I’m beginning to get the hang of this – dealt with in seconds. And finally the ./configure completes without error. But still no Makefiles. Yet more poking suggests that I really should be running

./configure --debug-output

if I really want to know what’s going on. And what’s going on is this:

The end of a CMakeLists file was reached with an IF statement that was not closed properly.
Within the directory: /home/ben/software/unpacked/digitalme-0.3.846
The arguments are: NOT ${Subversion_svn_info_result} EQUAL 0
-- Configuring done

Nice. An error you only find out about if debugging is on. OK, so this exhausts my cmake-fu. Can’t figure out how to fix this one. But I am not daunted – I do what every open source developer would do – go to the bleeding edge

svn co

The code I’ve been playing with lives in the iss subdirectory. And yes! After some editing of the cmake configuration, this actually generates Makefiles! Yes! (Once I’ve sorted out the usual irritation of svn checking out into a directory called “trunk”, that is). Not that it builds – I get a ton of errors on a make. Turns out there’s a header with platform info in, and FreeBSD is not configured – although I hate the GNU configure system, this kind of stuff makes me appreciate it! More hackery and I have some kind of configuration set up for FreeBSD. Then its just a matter of build, fix, build, rinse, wash, repeat until the compile completes. Which it does, eventually.

So I am now the proud possessor of a binary called digitalme. Now what, I wonder? I guess that’s tomorrow’s job, because now I have to cook.

For the truly geeky, here’s the diff:

Index: ftk/include/ftk.h
--- ftk/include/ftk.h (revision 960)
+++ ftk/include/ftk.h (working copy)
@@ -41,6 +41,7 @@
#undef FTK_SPARC
#undef FTK_X86
+ #undef FTK_FREEBSD
#undef FTK_GNUC
@@ -134,6 +135,11 @@
#error Platform architecture not supported
+ #elif defined(__FreeBSD__)
+ #define FTK_FREEBSD
+ #define FTK_UNIX
+ #define FTK_OSTYPE_STR "FreeBSD"
+ #define FTK_X86
#elif defined( sun)
#define FTK_OSTYPE_STR "Solaris"
@@ -410,7 +416,9 @@
#elif defined( FTK_UNIX)
#if defined( FTK_GNUC)
#define FTKAPI
- #define FTKEXP __attribute__ ((visibility("default")))
+// BEN: this causes a million warnings, so removing pending clearer understanding
+// #define FTKEXP __attribute__ ((visibility("default")))
+ #define FTKEXP
#define FTKAPI
#define FTKEXP
Index: ftk/src/ftkunix.cpp
--- ftk/src/ftkunix.cpp (revision 960)
+++ ftk/src/ftkunix.cpp (working copy)
@@ -428,6 +428,13 @@
return( f_mapPlatformError( errno, NE_FTK_FLUSHING_FILE));
+#elif defined(FTK_FREEBSD)
+ if( fsync( m_fd) != 0)
+ {
+ return( f_mapPlatformError( errno, NE_FTK_FLUSHING_FILE));
+ }


Index: ftk/src/ftkxpath.cpp
--- ftk/src/ftkxpath.cpp (revision 960)
+++ ftk/src/ftkxpath.cpp (working copy)
@@ -1889,7 +1889,7 @@

-#if defined ( FTK_LINUX) || defined ( FTK_NLM) || defined( FTK_OSX)
+#if defined ( FTK_LINUX) || defined ( FTK_NLM) || defined( FTK_OSX) || defined ( FTK_FREEBSD)
if( ui64Num > ((0xFFFFFFFFFFFFFFFFULL / 10) + (uChar - FTK_UNICODE_0)))
if( ui64Num > ((0xFFFFFFFFFFFFFFFF / 10) + (uChar - FTK_UNICODE_0)))
Index: CMakeModules/FindOpenSSL.cmake
--- CMakeModules/FindOpenSSL.cmake (revision 960)
+++ CMakeModules/FindOpenSSL.cmake (working copy)
@@ -23,19 +23,27 @@

# Locate OpenSSL files

+# BEN: Kludge in local version of 0.9.8 - FreeBSD uses 0.9.7, which
+# doesn't actually work - so this file should not check for 0.9.7.
+# Surely there's some way to do this without hacking this file?

find_path( OPENSSL_INCLUDE_DIR ssl.h
- PATHS /usr/include
+ PATHS /home/ben/work/openssl-0.9.8/include
+ /usr/include
+# remove the trailing "openssl" (this is not a kludge, it is needed)

find_library( SSL_LIBRARY
NAMES ssl.0.9.8 ssl.0.9.7 ssl
- PATHS /usr/lib
+ PATHS /home/ben/work/openssl-0.9.8
+ /usr/lib
@@ -43,7 +51,8 @@

find_library( CRYPTO_LIBRARY
NAMES crypto.0.9.8 crypto.0.9.7 crypto
- PATHS /usr/lib
+ PATHS /home/ben/work/openssl-0.9.8
+ /usr/lib
Index: CMakeModules/FindGTK2.cmake
--- CMakeModules/FindGTK2.cmake (revision 960)
+++ CMakeModules/FindGTK2.cmake (working copy)
@@ -71,6 +71,7 @@
PATH_SUFFIXES gtk-2.0/include
+ gtk-2.0
mark_as_advanced( GTK2_gdk_CONFIG_INCLUDE_DIR)
Index: CMakeModules/FindGLib.cmake
--- CMakeModules/FindGLib.cmake (revision 960)
+++ CMakeModules/FindGLib.cmake (working copy)
@@ -28,7 +28,8 @@
find_path( GLIB_INCLUDE_DIR glib.h
PATHS /opt/gtk/include
- /usr/include
+ /usr/include
+ /usr/local/include
@@ -41,7 +42,9 @@
+ /usr/local/include
PATH_SUFFIXES /glib-2.0/include
+ /glib-2.0
Index: CMakeModules/FindGnomeKeyring.cmake
--- CMakeModules/FindGnomeKeyring.cmake (revision 960)
+++ CMakeModules/FindGnomeKeyring.cmake (working copy)
@@ -34,6 +34,7 @@
PATHS /usr/include
+ /usr/local/include
PATH_SUFFIXES gnome-keyring-1

28 Sep 2007

Has Cardspace Become Passport?

I reviewed an article about identity management the other day. It got me thinking about what is really used out there, and what for?

People like to hail OpenID as a huge success, but as far as I can see its popularity is entirely on the provider side. There are no consumers of note.

Similarly, Cardspace appears to live in its own little world, supported only by Microsoft products.

Funnily enough, the only thing that seems to really be used much is SAML, widely used in enterprise SSO and in Shibboleth.

So why does this make Cardspace like Passport? Well, the fear with Passport was that Microsoft would control all your identity. The end result was that Microsoft was the only serious consumer of Passport. When Cardspace is deployed such that all providers and consumers of identity are really the same entity, then all its alleged privacy advantages evaporate. As I have pointed out many times before, when consumers and providers collude, nothing is secret in Cardspace (and all other standard signature-based schemes). So, there’s no practical difference between Cardspace and Passport right now.

(Sorry, no links today, I’m in a hurry)

19 Aug 2007

Brad Fitzpatrick on the Social Graph

Filed under: Anonymity/Privacy,Identity Management,Security — Ben @ 0:22

Brad Fitzpatrick writes about a problem that is essentially the same as my motivating example. His proposal avoids what I consider the interesting problems by only dealing with public data, though I think I would dispute that by so doing he solves 90% of the problem.

I also worry about whose perception of public is the correct one. If I have, say, a Facebook and a Flickr account, and a friend who knows what they both are, will I be happy if that friend broadcasts the fact that they’re both me? Possibly not.

In any case, interesting reading.

18 Aug 2007


Filed under: Anonymity/Privacy,Identity Management — Ben @ 5:56

Dick Hardt draws my attention to an article about the dangers of user-centric identity in something called informIT. As Dick says, the article tells us that, duh, if we screw up our websites then we screw up our users, too.

But it seems to me that there’s an even more fundamental issue. If, as the author correctly, if somewhat ungrammatically, claims, “the average users usually reuse the same username/password pairs for most of their accounts”, why, exactly, is it worse if the user types this same username and password into the same place every time (and probably far less often) than if the user is obliged to type it whenever he sees a login page?

It seems to me that the user stands a far better chance of being sure that he is typing his password in the correct place if there is only one correct place instead of several hundred.

14 Aug 2007

A Motivating Example

My friend, Carrie Gates (of CA Labs), posed me the following problem.

Let us imagine two services. The first we’ll call Facebook. Facebook is yet another of those obnoxious social networking services. The second we’ll call Flickr. Flickr lets me upload pictures and also acts as yet another, perhaps slightly less obnoxious, social network.

Flickr, being a kind, generous and forward-thinking sort of service, is happy to allow other services to build on top of it. It will let them link accounts for their users to Flickr accounts and show their users Flickr photos from those accounts. Flickr also allows me to choose who can see my photos. I can let just anyone see them, I can restrict access to my friends or I can make my pictures entirely private, so that only I can see them.

Facebook doesn’t let me upload pictures. But they’re smart – they’ve offloaded that bit of tedium to Flickr. You can tell Facebook what your Flickr account is, and then Facebook will display your Flickr pictures as if they were Facebook’s very own. Whether this is cheap, cunning or just good for the user I leave open to debate, but this is how these services work.

The interesting question arises when a friend wants to see my Flickr pictures on my Facebook pages (again, whether this is a good or bad idea I leave aside, but let’s just agree that people want to do this).

Now we have an interesting quandary. In fact, two interesting quandaries. Or maybe even three. The first arises if my friend is a Flickr friend. That is, I have told Flickr that his Flickr account is allowed to see my “friends only” pictures. The second if my friend is a Facebook friend. That is, I have told Facebook that his Facebook account is allowed to see my “friends only” pictures. The third arises when I trust Flickr more than Facebook, but this one I will have to explain later.

In the first case, Facebook is not itself aware that my friend is allowed to see these pictures. OK, you say, that’s pretty easy – Flickr knows, so all Facebook as to do is tell Flickr which Flickr account is trying to view my pictures, and hey presto! my friend can see my “friends only” picture. But what if my friend has not told Facebook what his Flickr account is? And why, indeed, should he? Then, of course, he can’t see my pictures (or perhaps he can, see the third quandary).

In the second case, Facebook knows he is my friend, but how does it tell this to Flickr? Flickr doesn’t expose APIs for saying who is a friend – Flickr takes the view that this would probably be insecure and certainly be quite confusing. Of course, Facebook has access to my Flickr account (obviously it is to my benefit to be able to manage my Flickr photos without leaving Facebook), so it could take matters into its own hands and show him my pictures anyway. Unfortunately, this would also give access to my completely private pictures, which I think I would take a dim view of.

And this leads to the third quandary. If I trust Flickr more than I trust Facebook, then by even indulging in this whole game I have reduced my security, as illustrated above.

OK, so now that I have set the scene, and, I hope, filled you with fear for the poor victims (err, I mean, “users”) of these services, the question arises: is there a way to do this properly? Can we achieve everything we desire and still leave everyone secure and with privacy intact?

One answer is to demand that every Facebook user must give their Flickr account to Facebook. Good luck with that. Clearly this sucks for all sorts of reasons, not least of which is that it totally fails to scale to the case of hundreds of Flickrs and Facebooks. It is also a disaster waiting to happen from a security and privacy point of view.

Obviously there must be better answers. I have some thoughts on this, but before I write them up I’m interested to hear what the blogosphere can come up with.

Feynman once said that if you could understand the two-slit experiment, then you understand the whole of quantum mechanics. This example is probably not quite as fundamental, but it seems to me to be, in some way, the two-slit experiment of identity.

BTW, all services in this blog post are fictional and any resemblance between them and real services is entirely coincidental.

« Previous PageNext Page »

Powered by WordPress