Re: [oauth] OAuth only for HTTP request signing?

[Onyx Raven <[e-mail]>]

Sorry, I got ahead of myself about the signature/signing -
METHOD&RESOURCE&PARAMETERS, hashed with one of the accepted methods
(RSA-SHA1, HMAC-SHA1, PLAINTEXT).

On Thu, Feb 5, 2009 at 2:37 PM, Onyx Raven <[e-mail]> wrote:
> So, thats what I was trying to get at.  I agree that the excepted
> token consumer-request -> sp-auth -> consumer-access process should be
> HTTP based as it is defined now.  It was really more about the
> consumer -> sp request signing (with delegated access), which like
> below, could be XMPP, IRC, proprietary game protocols, etc.  At a
> basic level, signature signing is defined as
> METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs
> structured in www-form-urlencoded style).
>
> But like I said before, as long as the core standard has acceptable
> wording for other consumer -> sp request protocols to hook into, thats
> what matters there.  I just wanted to be sure we didn't get locked
> into something we might want alternatives to in the future.
>
> On Thu, Feb 5, 2009 at 2:21 PM, John Kemp <[e-mail]> wrote:
>> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote:
>>
>>>
>>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving
>>> that mechanism in HTTP.
>>
>> Right. The point being that there are at least two potentially-independent
>> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1,
>> PLAINTEXT), and an HTTP-based protocol for token exchange.
>>
>> [...]
>>
>>>
>>> To me, the most useful aspect of OAuth when applied to other protocols
>>> is a clearly defined way to generate signatures given constituent
>>> components.
>>
>> I think it's certainly reasonable to suggest that the signature mechanisms
>> be defined so as to be useful in contexts other than HTTP. Which apparently
>> already worked well-enough for XMPP with OAuth 1.0.
>>
>> - johnk
>>
>