[cap-talk] Webkeys vs. the web
sam at samason.me.uk
Mon Mar 30 07:42:14 EDT 2009
On Mon, Mar 30, 2009 at 09:46:12AM +0200, Rob Meijer wrote:
> On Mon, March 30, 2009 01:54, Sam Mason wrote:
> > I have a feeling that multiple passwords (at least) are going to be the
> > only tractable solution for quite a while yet.
> My main concern is not actually with passwords, it is with dividing
> authority up using the static domain+username identity compartments, and
> allowing proof of identity to be used in a mobile way with untrusted or
> less trusted workstations.
Sorry, I missed that as being the target before. It sounds like a much
more laudable goal.
> Any 'solution' that puts a focus on identity
> and the mobile usage of identity IMO is simply missing the base values of
In general yes; but it does have the advantage of conscientious users
being able to assert their identity to multiple sites without the
need for technical devices and without affecting other sites if the
password from one is compromised. Whether this is a useful thing to
do and whether people actually use independent passwords is of course
> We need to work towards a solution that allows a person to delegate
> bundles of revocable 'authority' in a mobile way. If this requires
> passwords, that is OK.As long as this password is not used as proof of
OK; I think passwords are still highly conflated, in my head, with lots
of other things.
> What I proposed was along the following line:
> 1) The service Alice bundles some authority for an entity with the Bob
> 2) On proof of Bob identity (client certificate? ), Alice delegates the
> authority to the entity that is providing this proof.
> 3) Alice allows the holder of the bundle of authority to decompose,
> recompose and create membranes for the authority. The holder of the
> raw authority bundle uses this to create a more appropriate membrane
It would be interesting, in the transitional period for me at least,
if Bob could be the traditional username/password combo. Users would
have the option of finer grain control (i.e. object capability based
approaches) if they choose so. It would also serve as a good measure of
adoption as mentioned elsewhere in this mailing list.
> 4) The holder of the Bob identity delegates the more appropriate bundle of
> authority to a mobile device Carol. The mobile device stores the
> authority, possibly behind a password protection if you like.
I'd not considered doing this, but it makes a lot of sense. The whole
username+password/identity confusion seems to be clouding my judgement
more than I'd realised!
> 5) The owner of the Carol device wants to use some sub authority from a
> foreign machine 'Mallet'. He uses the Carol device to access Alice and
> further decompose the already limited authority into a singe usage
> session bound auto revoked authority bundle. This authority is delegated
> to Mallet.
> 6) The user uses the Mallet machine to access the Alice service. Mallet has
> no knowledge of the Bob identity, and after usage, no more access to the
> sub authority that was temporary delegated to it.
Yes, all nice properties.
> I can imagine simular solutions without a mobile device and with
> passwords. As long as you can stay away from identity and non auto revoked
> authority, we could I feel do much better than password based proof of
> identity solutions.
Yes, there seem to be many technical solutions to the problem but it's
an interesting twist of perspective.
I'm still somewhat worried about so much trust being placed on the
device Carol. Have you read the Hitchhikers Guide to the Galaxy?
There's a wonderful parody of this sort of thing gone wrong where all
authority came from a little card that was stolen, allowing Ford to
escape. I can't remember which book in the series it's in though.
More information about the cap-talk