[cap-talk] Ben Laurie's Motivating Example
Toby Murray
toby.murray at comlab.ox.ac.uk
Wed Aug 15 11:36:08 EDT 2007
On Wed, 2007-08-15 at 08:14 -0700, Jed Donnelley wrote:
> ----- Original Message -----
> From: Toby Murray <toby.murray at comlab.ox.ac.uk>
> Date: Wednesday, August 15, 2007 3:55 am
> Subject: [cap-talk] Ben Laurie's Motivating Example
> To: cap-talk at mail.eros-os.org
>
> > Ben Laurie has recently posted an interesting "motivating
> > example" (although motivating what we're yet to find out) on his blog.
> > It's an interesting "challenge problem" for security and access
> > controlin particular.
> > http://feeds.feedburner.com/~r/links/ZvUZ/~3/144078467/
> ...
>
> > It's one of those examples that appears to scream "capabilities"
> > straight away; who's current reliance on IBAC is the source of the
> > challenge problem, not its solution.
> >
> I agree that this example 'screams' capabilities - and it points to the
> exact problem that the "CapDoc" mechanism is intended to solve.
> Since 'CapDoc' is really just wideword and/or Tyler's Web
> Calculus/YURL (name?) mechanism with some additional
> facilities like 'deep attenuation' and Horton added, please
> imagine that structure.
>
> To solve Ben Laurie's problem imagine that both Facebook and
> Flickr make their services available with CapDoc capabilities.
> However, in this case a statement like:
>
...
> With the CapDoc approach of course either Facebook or
> Flickr can include the other services as capabilities in their
> exported objects. No "accounts" are needed except
> perhaps for responsibility tracking and identity based
> access control - as Horton supports.
>
> To me this example seems simple with CapDoc. If
> others see a problem then I'll certainly work to explain
> how it works in 'CapDoc' as this seems exactly the sort
> of thing CapDoc is intended to support.
I'd like to see the details fleshed out.
I imagine some sort of sealer/unsealer implementation might be required
in order to do this properly.
Lets presume that when viewing my Flickr page, one is returned a
capability to each picture I have there.
For publicly viewable pictures, Flickr returnes a cap to the image
itself. For Flickr-friends-only pictures, for each picture Flickr
returns a cap to an opaque box object that contains the image. Each of
these boxes can be unselealed only by the caps FF (FriendsFlickr) and MF
(MeFlickr). For private Flickr pictures (the ones only I can view)
Flickr returns a cap to a box that can be unsealed only by the cap MF
(MeFlickr).
Anyone who can login to Flickr as me, gets a copy of MF. My Flickr
friends each get a copy of FF.
Now my Facebook profile holds no special capabilities, except the cap
that allows it to view my Flickr profile. Hence, it is returned
capabilities exactly as above.
When viewing my Facebook profile, one presents their *F cap (for me, I
present MF, for my Flickr friends they present FF). This allows Facebook
to unseal the pictures and display them to the viewer. (We might give a
cap wrapped in the recently discussed revoking membrane that revoked
access after the images have been fetched.)
If I wish to allow my Facebook friends to be treated as Flickr friends,
then I place a copy of FF in the part of my Facebook profile that's
visible only to Facebook friends.
The main issue here is how to instruct the user to present their *F cap
when viewing my Facebook profile. This is the tricky part that I'm yet
to figure out.
Or perhaps there's a less convoluted way of solving this whole thing.
Cheers
Toby
More information about the cap-talk
mailing list