I'd personally rather see something flatter, even with an implied root
namespace defined in the spec. Maybe like:
<oauth>
<access_token>asdfasoij234f</access_token>
<refresh_token>2f098jadfasdfasdf</refresh_token>
<expires_in>300</expires_in>
</oauth>
Mirroring the key-value format for the JSON and form-encoded forms, this
keeps the field names as elements and the values as text node values.
I'd rather not see us hang a "value=" attribute in all of these.
-- Justin
On Fri, 2010-06-04 at 09:42 -0400, Andrew Arnott wrote:
> 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 list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
