[cap-talk] Please help us understand a protocol

[Jed Donnelley]

On 9/25/2007 11:52 AM, Mark Miller wrote:
> <http://oauth.net/documentation/spec> presents the OAuth protocol,
> whose purpose seems to be more flexible identity-based access control
> for the web. At
> <http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/09/21/oauth-your-valet-key-for-the-web/1550>,
> the main claim made for OAuth seems to POLA. They use the metaphor of
> the valet key, which is one we've used to explain how capabilities
> differ from ACLs (<http://eros-os.org/essays/capintro.html>,
> <http://combex.com/tech/edesk.html>). However, the OAuth spec is
> complex and not explained in access control terms. I do notice some
> things which might be capability-like, or perhaps
> split-capability-like, but I can't tell. From an access control
> perspective, what kind of thing is OAuth? How is valet-key-like
> authority expressed and communicated in OAuth? Is it vulnerable to
> confused deputy problems? How would it handle Ben's "Motivating
> Example" <http://www.links.org/?p=246> or Alan's Zebra Copy scenario
> <http://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf>?
> 
> Given the backers of OAuth, it would be valuable for us to understand
> it in access control terms, and to explain how its properties relate
> to IBAC, ABAC, and capability-based access control.

I read through both the description above and the spec for OAuth.

I'm confident I understand the basic idea.  I believe
enough so to answer MarkM's questions.

I think the basic idea of this OAuth protocol
is to allow two providers ('consumer' and 'service')
to communicate designation information and to
allow a user on one provider to authorize access
by the other provider - essentially as a
capability (authorized token).

What I'll do here is describe the protocol in a
way that I hope simplifies things a bit for
others (especially those familiar with cap-talk
terminology) reading the protocol spec.  I've
bcc'ed a few of the OAuth authors/developers in
the hope that they may correct any errors in my
description, perhaps even with a reply to
cap-talk:
http://www.eros-os.org/mailman/listinfo/cap-talk


I believe for this spec it helps to first read the
example near the bottom where Jane has accounts on
photos.example.net and on printer.example.com
and she wants to print one of her photos on
the printer.example.com service.

The basic idea is that Jane is interacting with
her services and she says to her printer.example.com
service

Print: http://photos.example.net/photo?file=vacation.jpg

where the URL is one that with her authorization
allows her to view the photograph that she wants
to pint.

printer.example.com attempts to comply and discovers
that the object to print is protected by access control.

That sets into motion the OAuth mechanism.  In their
discussion photos.example.net is the "service"
provider and printer.example.com is the "consumer".
The essential step is the authorization by Jane
(via her photos.example.net account) of the
access to this one object (designated by
token, in this case the photograph designated by
the above URL) by printer.example.com.

Prior setup:
_____________
One thing to note is that before anything happens
there is an assumed shared secret between the
consumer and the service provider.  That is both
are assumed to know the:

    * Consumer Key : dpf43f3p2l4k3l03
    and
    * Consumer Secret : kd94hf93k423kf44

through a prior registration (discussed as
the first step in the example).  I don't know
how essential such a "registration" of the
"consumer" service is to the whole protocol
(that is, since any such consumer can so
register, what additional value does that
registration add?), so I suggest others
watch where that shared secret shows up.
______________

Now once printer.example.com (the 'consumer') gets the:

HTTP 401 Unauthorized

error indicating that the object is protected,
it puts together a "request token" to send to
the service provider.  It's basically saying,
here is the 'name' (designation) of an object that
I would like to access.  Unstated is the fact that
the request is on behalf of "Jane".  The 'user'
"Jane" doesn't show up in the protocol as far
as I can tell except for the authorizing of the
request token.

The consumer sends this request token to the
service provider which then asks the user (through
a UI that I believe is unspecified) to authorize
the request token.  About this step they say:
___________
The Service Provider asks Jane to sign-in using
her username and password and if successful,
asks her if she approves granting printer.example.com
access to her private photos. If Jane approves
the request, the Service Provider redirects her
back to the Consumer’s callback
___________

Once the request token is authorized it becomes
an "authorized request token" which then acts
much like a capability as data as far as I can
tell.  Besides the designation information, the
two "secret" pieces of information that go into
the finalized request on the authorized request
token are:

The Consumer Secret : kd94hf93k423kf44
<established by the registration step,
any "consumer" can so register it seems>

and the:

The Token Secret : pfkkdhi9sl3r4s00
<returned in response to the authorization
of the request token by user Jane>

Along the way they deal with issues like the
communication between consumer and service
provider not being encrypted and the hashing
of the consumer and token secrets into the
message for safe communication.

In this message I'll confine myself to just
trying to help others to understand the protocol.
We can leave any discussion of the value of the
protocol, how it relates to capabilities and
such for later messages.

Their blog:

http://oauth.net/blog

is amusing...

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