[cap-talk] Please help us understand a protocol

[Ben Laurie]

On 9/26/07, Jed Donnelley <jed at nersc.gov> wrote:
> 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.

The point here is that the service provider can switch off a malicious consumer.

[snip]

> 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>

OAuth does not specify how consumers register, so it is a bit of a
leap to assume that any consumer can register. That is entirely up to
the service provider.

> 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.

OK, but I would note that the fact that the consumer has to sign any
requests they make with their secret means that the OAuth token is not
a pure capability.

> Their blog:
>
> http://oauth.net/blog
>
> is amusing...

I think that is an aggregator.

Cheers,

Ben.