Thanks, George.  From that I get this:

<response>
        <oauth_parameter name="oauth_token">token</oauth_parameter>
        <oauth_parameter name="oauth_token_secret">secret</oauth_parameter>
</response>

>From the text around it, it sounds like SPs were permitted to add to this
(presumably using their own element names).  While this seems reasonable, it
seems that SP-specific extensions that used alternate element names would
then be incompatible with JSON and url-encoded responses since they cannot
include this extra element metadata.  (well JSON could, with some breaking
changes to the format).

So with that, it seems like we should eliminate the redundant
oauth_parameter element name in favor of just using the name of the
parameter as the element name.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Fri, Jun 4, 2010 at 6:34 AM, George Fletcher <[email protected]> wrote:

>  I don't know if this is helpful or not... but there was a proposed
> extension for OAuth 1.0 dealing with encoding OAuth responses in different
> body formats... this can be found on the now extinct oauth-extensions google
> group.
>
>
> http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en#
>
> Thanks,
> George
>
> On 6/4/10 8:56 AM, Andrew Arnott wrote:
>
> In the absence of anyone else volunteering an XML format, what would you
> say to this as a proposal (because the implementation of which happens to be
> simple for me):
>
> <root type="object">
>    <access_token type="string">some access token</access_token>
>    <refresh_token type="string">some refresh token</refresh_token>
>    <expires_in type="number">235298298</expires_in>
> </root>
>
> So the main points here is:
>
>    1. no namespace
>    2. root tag is called "root"
>    3. each parameter is an element
>    4. each element has a type parameter that is either string, number, or
>    object to assist the deserializer to understnad how to cast the contents.
>
> We may axe #4.  In fact we may want to switch all the elements to
> attributes because it's slightly more compact which might help small
> devices.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott <[email protected]>wrote:
>
>> Where is the definition of how a auth server response in XML format should
>> look?  At the least we need an XML namespace and root node name.
>>
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>
>
> _______________________________________________
> OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to