[cap-talk] Ben Laurie's Motivating Example, OAuth vs. CapDoc contrast

[Jed Donnelley]

On 9/26/2007 12:56 AM, Ben Laurie wrote:
On 8/16/07, Jed Donnelley <JEDonnelley at lbl.gov> wrote:
...
>>
>> Thanks for taking time to work through
>> this example of "CapDoc"!
> 
> OK, so I've taken forever to respond to this. Sorry.

No problem.  I'd say your timing is propitious.  It will
allow us to contrast a network capability structure like
CapDoc (Waterken, E's vats, DCCS, Amoeba/NLTSS/Monash, etc.)
with OAuth.  I expect the timing of the response was
no coincidence.

For others for reference, here is the CapDoc example
that Ben and I are referring to above:

http://www.eros-os.org/pipermail/cap-talk/2007-August/008850.html

which in turn refers to Ben's motivating example:

http://www.links.org/?p=246

> So, nice to see Horton worked into this, though explaining it to an
> audience not immersed in caps might take some effort.

Perhaps, but I believe the notion of an identity is not
difficult to explain.  In some ways a Horton identity
serves a function similar to the "consumer" registration
with OAuth.  It allows for revocation by identity (e.g.
potentially misbehaving).  However, it is important to
note that the Horton mechanism is a service that can
be built on top of the basic ocap paradigm and is not
built into it (as the "consumer" notion is built into
the OAuth mechanism).

I believe the user interface to manage identities can be
made so simple (is so simple in the CapDoc approach that
I described above) that people not immersed in capabilities
will have no problem. I also argue that the capability
concept (a permission that can be sent in a message as
a parameter) itself is so simple that there is little
problem even for non-technical people to understand it
(see the valet key discussion below).  Where people get
the idea that capabilities (permission parameters, merely
object references in object languages) are complex or
difficult to understand is beyond me.  Of course getting
into use nuances such as deep RO attenuation, Horton,
membranes, etc. can become complex as can use of any simple
underlying paradigm such as that of a simple subroutine call,
but these facilities are largely invisible to users who
instead have interfaces with operations familiar to them
such as send a message with a 'key' (permission), revoke
Joe's access to my stuff, etc.

> Anyway, you have dealt with the mechanics of getting the right
> capabilities into everyone's hands, but without, it seems to me,
> addressing the core problems, which are:
> 
> a) How does Flickr/Facebook know where to send these capablities?

Neither Flickr nor Facebook needs to send the capabilities
anywhere.  They only need to service requests on them.
Some of the requests on the Facebook objects may fetch
(return) capabilities that then get sent to whatever
process made the request.

To be explicit, let's suppose that it is you that are my
friend Ben.  In that case I can create a Facebook CapDoc
page that I might call "Ben's stuff."  I send you a deeply
attenuated RO capability to this page in a message as
described in my CapDoc example (think of it as an email
as it could be with a bit of care).

Then later if I want to share some of my Flickr pictures
with you I link capabilities to them into this page.  It
might look like this added text:
____
Hey Ben, here are some pictures from my recent vacation:

<a href=https://facebook.net/doc/qK5YapH6WRcL6R7RZ9vhDA%3D%3D>Vacation pics</a>.
____

(I could also just send you the above in another message).

You could then fetch the above capability from your
Facebook page (or out of the later message) that you
might refer to as "Stuff from Jed".  When you look inside
that "Vacation pics" facebook page you see described links
to the Flickr pictures from my vacation.  All Flickr needs
to know is that if somebody presents it a valid capability
for one of it's pictures that it needs to return the content.

> b) Once they do know, didn't I just reveal all the linkages between my accounts?

Of course not.  I (in this case) only revealed capabilities to
whichever Flickr pictures I put into my vacation pictures
page.  Even at that by the time you fetch them they have
been "attenuated" so that if at some point I decide I
don't want to share with you any longer I can revoke
your access to them.  It's actually a Horton intermediary
that does the fetching of the picture contents from Flickr,
but of course that is invisible to you - unless or until I
revoke your access.  The whole idea of capabilities is of
course POLA - just share the capabilities you want to
share.


At this point I think it might be appropriate for me
to state an opinion on OAuth.  I believe it is
overly complex and doesn't add value with it's
complexity.  Just consider the contrast between, for
example, a wideword style photo capability:

https://photos.example.net/photos?qK5YapH6WRcL6R7RZ9vhDA%3D%3D

and an OAuth photo 'capability' (what one needs to "invoke"
to get access to an object):

http://photos.example.net/photos?file=vacation.jpg&size=original&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=nnch734d00sl2jdk&oauth_signature_method=HMAC-SHA1&oauth_signature=3a4df91bba14e81cde073c9070beec993e45a2d6&oauth_timestamp=1191242096&oauth_nonce=kllo9940pd9333jh

not to mention all the registration and assembly steps.
Many of these steps are not unreasonable by themselves,
but having them built into the base access control mechanism
is quite unwise, in my opinion.

I believe that if this OAuth proposal goes forward and
is widely implemented we will end up being saddled with
a very complex mechanism with less functionality than
a simple network capability mechanism with supporting
services.

I believe the valet key analogy for capabilities (e.g.
for network capabilities) is rather accurate:

http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/09/21/oauth-your-valet-key-for-the-web/1550

On the other hand the complexity of OAuth mechanism with
it's required consumer registration, token generation and
authorization for every communication I believe to be
significantly more complex than the valet key metaphor
would suggest.  For example, how would one valet share
a 'key' with another?  In principle I believe one could
construct a sharing mechanism based on the ultimate result
of the OAuth mechanism - namely the authorized tokens like:

http://photos.example.net/photos?file=vacation.jpg&size=original&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=nnch734d00sl2jdk&oauth_signature_method=HMAC-SHA1&oauth_signature=3a4df91bba14e81cde073c9070beec993e45a2d6&oauth_timestamp=1191242096&oauth_nonce=kllo9940pd9333jh

, which I believe can act like network capabilities, but
why saddle something so simple with such a complex
mechanism?  Using such a mechanism one valet could
just send such a 'capability' to another.  However, in
that case why not allow that much simpler mechanism
to be used for communicating permissions in general
rather than requiring the whole OAuth mechanism?

I ask: Which mechanism (OAuth or support for network
capabilities) adds the most complexity to network
services?  Which mechanism provides the most value
in terms of flexibility of managing permissions
(ultimately authority)?  For me the answers are clear.
I'll be interested to hear what others think.

Who knows how the political and implementation
decisions will go?  How did we get stuck with ambient
authority in operating systems when much more effective
POLA examples were already available?  We all do
our best to move things in positive directions.
The choices we make are inevitably driven by
our unique experiences.

I've again bcc'd some of the OAuth developers for
possible comment.

--Jed  http://www.webstart.com/jed/