On Wed, Feb 4, 2009 at 1:36 AM, Eran Hammer-Lahav wrote:
>
> On 2/3/09 5:11 PM, "Perryn Fowler" wrote:
>
>> I'm probably being dense or ignorant or both here, but why is it an issue
>> from the OAuth prespective whether the payload is XML or something else?
>> Could you not just consider it as a byte-stream, or text in a known encoding?
>
> As long as you have access to the raw HTTP body, you can sign it regardless
> of what it represents. Multi-part bodies are tricky because you need to take
> into account the separator used, and the implication of manipulating the
> separator header.
Just to suss this out a little more, one of the design goals of OAuth
is for it to be usable in the context of web frameworks or
environments where the raw request may have been "massaged" before you
get it. It goes both ways, too -- most HTTP client libraries make it
really difficult to inspect and modify the request after it's been
fully composed but before it's sent over the wire. Real-live
implementations and interoperability is really important for OAuth, so
we decided to punt on the issue way back in the day.
As Kellan hinted at, the hope is that as we see a few real-world
body-signing usage of OAuth, we can extract those "best practices"
into a specification.
b.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---