How about keeping it even more flat and compact: <oauth access_token="asdfasoij234f" refresh_token="2f098jadfasdfasdf" expires_in="300" />
This also is more simple on the DOM side, just doc.root['access_token'] instead of traversing or xpath. Anyway, I think OAuth 2 is better served in general by the KISS principle <http://en.wikipedia.org/wiki/KISS_principle>. -Kris On Jun 4, 2010, at 8:14 AM, Justin Richer wrote: > 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 <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# >> >> 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> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
