[cap-talk] OAuth vs. CapDoc contrast

[Jed Donnelley]

On 9/26/2007 12:48 PM, Blaine Cook wrote:
> On 9/26/07, *Jed Donnelley* <jed at nersc.gov <mailto:jed at nersc.gov>> wrote:
> 
>     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
>     <https://facebook.net/doc/qK5YapH6WRcL6R7RZ9vhDA%3D%3D>>Vacation
>     pics</a>.
>     ____

Thanks for taking time to write Blaine!

> This is definitely a useful use-case. Flickr does this, and so do many
> sites, through the use of hard-to-guess tokens. It works well enough,
> and is simple to implement. I'm sure the concept of capabilities goes
> beyond the simplest case,

Not much if at all.  The basic idea of object/capabilities
is to have as simple as possible a token that can be
communicated which binds an object designation with access
to the object, and then to build services on top of that
base mechanism.

> ...but my impression is that whatever decisions
> are made are very application-specific.

Just as with objects in OO languages what one can
implement through an object/capability interface is
completely flexible, but of course application specific.
The richness of any object/capability environment comes
from the services that are built on the base infrastructure.
Some services such as membranes for revocation are in
some sense meta services (though implemented with just
the base object/capability mechanism) and other services
(e.g. files, directories, etc.) are simple services
such as for storage, management, etc., etc.

> OAuth doesn't attempt to solve this problem, and isn't intended to
> enable you to share your data with other people. It's strictly an
> extraction of existing practices: Google AuthSub, Flickr Auth, Amazon
> AWS Authentication, AOL OpenAuth, and Yahoo BBAuth all use essentially
> the same mechanism as OAuth for token exchange and authentication of
> requests.

Thanks.  I think I understand the basic idea, though I didn't
know there were so many existing comparable mechanisms.

Can you tell me (us) whether the sort of final form authorized
token (e.g. from the spec:

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

) can be used in a source independent way for access
to the object - in this case to the vacation.jpg file?
I'd like to distinguish the final authorized token from
a capability (e.g. as you say a hard-to-guess string).

> The only stated goal of OAuth is to enable a user to use their own data
> from a given site on other sites and downloaded applications without
> revealing their username and password.

A useful goal to be sure, but of course there is more than
one way to do it.

>     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
>     <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. 
> 
> 
> The comparison isn't quite fair, since in the above example, the
> capability is valid only for a single photo (vacation.jpg), and relies
> on the provider to keep track of all capabilities granted. OAuth is
> intended to replace Basic authentication, and when using header
> authentication, one would only need to request:
> 
> http://photos.example.net/photos?file=vacation.jpg&size=original
> <http://photos.example.net/photos?file=vacation.jpg&size=original>
> 
> or if the provider had an api that allowed for simplified access to the
> photos (for example):
> 
> http://photos.example.net/photos/vacation
> 
> in addition to the OAuth headers, of course.

Hmmm.  I think there is something in the above that I'm not
understanding.  Are you suggesting that once an authentication
happens with a full "authorized token" then other requests
can be made for other objects without fully "authorized token"s?
That is, that in some sense the authorization for an
authorized token can be reused somewhat along the lines
of how basic authentication works and can thereby provide
access to other objects?

Perhaps what I'm missing is that if the request with
the fully authorized token provides access to what amounts
to a web 'page', then whatever is 'below' that Web page
(in a directory hierarchy sense) is available for access
without requiring fully authorized tokens of their own?
This along the lines of how basic authentication works?
I think I'm missing something here and would appreciate
any clarification.

> But, I think the bottom
> line is that they're different things. Strictly speaking, OAuth could be
> simplified to just passing the token across, but there are multitudes of
> problems with this approach unless you're using SSL (see the PLAINTEXT
> signing algorithm for an example of this).

I recognize that some (much?) of the work and complexity
in OAuth went into dealing with the fact that the communication
is done unencrypted (not across SSL for example).  In that
sense the comparison is indeed unfair.  It would be unwise
to communicate a simple 'password' capability (a capability
as data token with a simple unguessable 'swiss' number)
across an unencrypted link.

On that topic, however, let me ask in a slightly different
form a question related to what I asked above - namely:
If the communication of a final authorized token request
could be captured, what would stop it from being replayed
from another source to effect access.  I didn't seem to
see the sort of handshake that I would expect in the OAuth
protocol to defend against such a replay attack.  Perhaps
I just missed that?

>     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 agree that OAuth is relatively complex, compared to simple
> "hard-to-guess" strings (which definitely have a place), but it's
> already widely in use at Google, Flickr, Yahoo, Amazon to name just a
> few, and it's a definite need for many startups, especially in the realm
> of dealing with APIs and OpenID.

Where do you see that need deriving from?  Is a large part
of the need in dealing with unencrypted communication
where hard to guess strings would be unsafe?  If more,
what is the most substantive added value that you believe
OAuth provides that simple hard-to-guess strings can't
provide.

>     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. 
> 
> The OAuth group was formed by myself and Chris Messina in January, with
> early help from David Recordon and Larry Halff and increasing numbers of
> people as time went on. OAuth is not by any means a "standard" in the
> "Standards Body Approved" sense; it's more of a standard in the
> Microformats sense, with a tendency towards OpenID's approach. You're
> not bound by it, and you have no obligation to implement it. We created
> the spec based on a pattern that was successful in the wild, and wanted
> to stop re-inventing that particular wheel.

Laudable work!

> I think really, we're talking about a diversity of tactics, based on
> appropriateness of those tactics. If / when Twitter implements sharing
> of updates to those who aren't already "friends", I'll definitely look
> at the capabilities stuff, since it sounds like a useful description of
> a pattern I've used before.
> 
> If my assessment above is incorrect, please let me know, but I really do
> think Capabilities and OAuth are two different things, both with
> strengths and weaknesses that suit different applications.

I expect this discussion will go on for some time on the cap-talk
list.  You could join:

http://www.eros-os.org/mailman/listinfo/cap-talk

if you'd like to watch or to participate.  Otherwise I
won't bother you or your colleagues unless something of
a 'big picture' nature comes up with respect to OAuth.
Your initial message will only be visible to the list
through this reply of mine (the list is limited to
registered email addresses), so I kept all your original
content.

Thanks again for taking time to reply!

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