Sorry about the partial message, hit send by accident.
------
In order to do that well it would be nice if some further restrictions were
imposed on extending rather than responses can be any valid JSON doc. In JSON,
keys can be any string, so you can not use them as tags or attribute names in
XML. Any XML extension spec if it wanted to support other extensions would
just be a generic JSON to XML conversion which will look verbose and ugly.
Maybe the spec on extending OAuth 2 should explicitly restrict the allowed
characters in JSON keys, avoid mixing types in arrays, etc. Just to keep it
simple but still take advantage of the JSON structure.
Otherwise an XML extension will look something like:
<object>
<member>
<key>scopes</key>
<value type="array">
<element type="string">http://example.com</element>
<element type="string">http://foo.com</element>
</value>
</member>
...
</object>
While I do think it is weird for example to need a JSON parser to read an
authenticated ATOM feed and also think it is pointless now to support XML as an
alternative format in an OAuth 2 protected API – I'm cool with JSON only.
-Kris
On Jun 15, 2010, at 12:02 AM, Eran Hammer-Lahav wrote:
> Since XML was dropped, if you feel strongly about this, please submit a new
> I-D extending the spec to allow XML format responses. Don’t worry about how
> to extend it, just add parameters or whatever for now.
>
> EHL
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Andrew Arnott
> Sent: Friday, June 04, 2010 5:56 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Definition of XML response format
>
> 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:
> no namespace
> root tag is called "root"
> each parameter is an element
> 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> 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
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
