It would be useful to understand the token type as the AS and RS server may 
each generate and accept different token types

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Andrew Arnott
Sent: Friday, June 04, 2010 6:43 AM
To: George Fletcher
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Definition of XML response format

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 
<gffle...@aol.com<mailto:gffle...@aol.com>> 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#<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 
<andrewarn...@gmail.com<mailto:andrewarn...@gmail.com>> 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 list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to