Hi kthrtty, You shouldn't put non-protocol parameters in OAuth Authorization header.
I had met a problem between our OAuth server and shindig (open-source OpenSocial container) before, because of this OAuth spec ambiguity. At that time, shindig had been using the header to send OpenSocial specific OAuth extension parameters like xoauth_app_url, opensocial_viewer_id etc. However PHP, Ruby and Python OAuth library ignores those non-protocol parameters in the header, so all request verifications had been failed. I hope this will be clarified in OAuth 2.0 spec. cheers nov On 2010/04/27, at 15:15, kthrtty wrote: > Dear experts. > > I read the two specifications(community/ietf hammer draft), and > confused to > interprete those specs about regulation of additional parameters. > > *This mail is reposted.* > (It was posted to IETF OAUTH-WG, but it seems not to be suit for the > ML's purpose.) > > - Community (http://oauth.net/core/1.0) > ------------------------------ > "5.2 Consumer Request Parameters" > In addition to these defined methods, future extensions may describe > alternate > methods for sending the OAuth Protocol Parameters. The methods for > sending other > request parameters are left undefined, but SHOULD NOT use the OAuth > HTTP > Authorization Scheme (OAuth HTTP Authorization Scheme) header. > ------------------------------ > "7. Accessing Protected Resources" > After successfully receiving the Access Token and Token Secret, the > Consumer is > able to access the Protected Resources on behalf of the User. The > request MUST > be signed per Signing Requests (Signing Requests), and contains the > following > parameters: > > oauth_consumer_key: > ・・・ > Additional parameters: > Any additional parameters, as defined by the Service Provider. > ------------------------------ > > I think this part of spec seems to say that HTTP Authorization header > MUST NOT > include "other request parameters"(which are not OAuth Protocol > Parameters). > > Do OAuth 1.0a allow to send other request parameters only in POST > request body > and as query string? > > And when Consumer access protected resources, is the same rule > applied? > (Must there be no other request parameters in OAuth Authorization > Header Scheme?) > > > - IETF (http://tools.ietf.org/html/draft-hammer-oauth-10) > "3.5.2. Form-Encoded Body" and "3.5.3. Request URI Query" say > ------------------------------ > The entity-body MAY include other request-specific parameters > The request URI MAY include other request-specific query parameters > ------------------------------ > but "3.5.1. Authorization Header" don't say > "The Authorization Header MUST NOT include other request-specific > parameters" > > Above discussed descriptions is so confusion at least for me. > > > If anyone knows the spec in detail, please let me know. > > > Best regards. > > -- > Tatsuya (=kthrtty) > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to oa...@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. > -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oa...@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.
