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

Eran,

Is the plan to put the existing SBS stuff in IETF OAuth Core or in a  
separate HTTP binding?  Perhaps that would be a reasonable compromise,  
leaving OAuth Core protocol agnostic.  Of course, the WG could only be  
responsible for creating the HTTP binding, not any other protocol.   
But it would leave OAuth Core flexible enough to support future  
protocol bindings in the future without modification.

Or am I missing something?

-will

On Feb 5, 2009, at 1:50 PM, Eran Hammer-Lahav wrote:

> The fact the signature base string today is compatible with XMPP  
> (but taking a liberal view of the workflow), is mostly luck. It just  
> happened that a solution that was optimized for HTTP seems to work  
> well for XMPP with some clarifications.
>
> It is very likely that we will be defining a new signature method.  
> If non-HTTP considerations will make it any more complex than it has  
> to be, I will find it problematic. If it doesn't, great. I am happy  
> to allow the charter to "review the applicability of existing and  
> new signature methods to protocols other than HTTP", but that is  
> where I think we should draw a line.
>
> The charter should allow a signature method that does not support  
> XMPP, if it makes HTTP better. In other words, I am against putting  
> any other protocol at equal consideration as HTTP.
>
> EHL
>
>
> On 2/5/09 1:37 PM, "Onyx Raven" <onyxraven@gmail.com> 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 <john@jkemp.net> 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
>>
>
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth