[cap-talk] OAuth vs. CapDoc contrast

[Jed Donnelley]

At 04:40 PM 9/28/2007, Karp, Alan H wrote:
>Jed wrote:
> >
> > Thanks for taking time to write Blaine!
> >
>I had misunderstood some things about OAuth until I read Jed's
>discussion of Blaine's comments.  In particular, the use model is quite
>different from what I had thought it was because I hadn't read all the
>way to the appendices.  The one sentence in the abstract didn't make it
>clear that the user initiates the request made by the consumer.
>Clearly, Oauth is not the general purpose authorization mechanism I
>thought is was.
>
>I am still confused by some things.
>
>1. Much of the protocol seems to exist to protect the tokens and secrets
>when they are used over HTTP.  However, several sections in Appendix B
>recommend using HTTPS.  Why not just use HTTPS all the time and simplify
>the protocol?

I wondered some about this also.  I can see that perhaps OAuth is
intended to work with services that may not use HTTPS at all (though
one wonders how user authentication is generally done).  Possibly
some services that use cookies for authentication (though again
there would seem to be sensitive information going across in the
clear).

Still, even if there is a need to use un encrypted Web communication,
why not at least provide a simplified version of the protocol for
the case where the communication is actually encrypted?

>2. Appendix B.9 implies that the authorization token grants the consumer
>access to all the user's protected resources, not just the one the user
>authorized.  Is this choice just an optimization?

It seems to me that this new Appendix B.9 explicitly says that
the OAuth protocol (I'm not sure quite what to call it) doesn't
specify what the 'scope' of any granted access is.  That is,
it could be just a single resource with limited access rights
or it could be all a user's authority.

In response to my questions Blaine Cook said:

"OAuth is intended to replace Basic authentication"

That might vaguely seem to suggest that it would use
the scoping rules of Basic authentication based on
directory hierarchy.  Doing so would seem to be just
one of many possible implementations according to
this new B.9 appendix.

On this topic regarding:

>At 07:32 AM 9/29/2007, Ben Laurie wrote:
>On 9/29/07, Karp, Alan H <alan.karp at hp.com> wrote:
>...
> > 2. Appendix B.9 implies that the authorization token grants the consumer
> > access to all the user's protected resources, not just the one the user
> > authorized.  Is this choice just an optimization?
>
>It should not imply that. The token should grant consumer only to what
>the user authorised.

And what the user authorizes is up to the service provider.
It provides the user interface, sends out the token
information, and responds to the authorization request
from the consumer, so the service provider seems fully
in control.

>3. Can an authorization token be delegated?  For example,
>printer.example.com prints only text and farms out work on photos to
>images.example.org, which never heard of photos.example.net.  Does
>printer.example.com have to read the bits and forward them, or is there
>a way for images.example.org to read them directly from
>photos.example.net.  If so, can images.example.org further delegate the
>authorization?

I believe this is the same question I was trying to ask a couple
of times in perhaps awkward ways.

Regarding:

>At 07:32 AM 9/29/2007, Ben Laurie wrote:
>On 9/29/07, Karp, Alan H <alan.karp at hp.com> wrote:
>...
>No, but once OAuth is baked, I do plan to work on a delegation
>standard. Are you interested in helping?

The above seems to suggest that a fully authorized token
can only be used from a single what, consumer key?

If a consumer was to share it's key along with a fully
authorized token, would that suffice?

>4. Finally, I'll re-ask Jed's question.  Why not just use webkeys?  The
>user can go to her account at photos.example.net and be presented with a
>"Delegate" button for each resource.  Pressing that button returns a
>URL, which can be pasted into a form field at photos.example.net.  That
>URL can hold the relevant information granting access to the one
>resource being designated and can be revoked after a single use.

It certainly seems to me that there is a lot of overlap in
functionality.

On this topic regarding:

>At 07:32 AM 9/29/2007, Ben Laurie wrote:
>On 9/29/07, Karp, Alan H <alan.karp at hp.com> wrote:
>...
>Since I am also generally a fan of capabilities, I tend to wonder 
>this, too :-)
>
>One answer is that then you would not be able to delegate.

I don't understand.  It seems the opposite to me.  Namely
if one were to use webkeys for the authorizing tokens
in a protocol like OAuth then delegation would be automatic
as with any object/capabilities.  Did I misunderstand
what was being said above?

I bcc'ed three of the OAuth authors with my original message,
including Blaine Cook.  Unfortunately I don't have their
email addresses here at home nor time to find them again
this morning.  I'll try to get these questions to them either
tomorrow or at work Monday morning.

Perhaps Ben Laurie is able to represent the OAuth community?

Though when he says, "I tend to wonder this, too..."  perhaps
we need broader reach into the OAuth community to get fuller
representation, if possible?

It seems to me it would be great to get some of the OAuth
authors/proponents to come to one of the HP Friday
capability meetings, though I have no idea if that is
even remotely (double meaning intended) possible.

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