At the risk of betraying my SAML roots, I'd suggest that if name-space and typing like functionality is desired, we not try and reinvent the wheel and actually use a schema. After all, <oauth_parameter name="oauth_token"> is effectively an attempt at nonstandard namespacing and <access_token type="string"> is the same kind of thing for data typing. XML Schema has its issues and I'm sure many on this list are not fans, but it is a standard and there are open source and commercial tools that support it. And it's pretty easy to ignore for implementations that don't want to care about it. I could draft something up, if there is interest.
Alternatively, keeping things really simple, along the lines of what Justin suggested, might make sense as well. Data types are implied/known by the names and any extensions or proprietary parameters will just have to make sure they don't have name conflicts. As far as I can tell, this is already the case with the other response types so it doesn't seem like a problem to have the same limitations for XML. On Fri, Jun 4, 2010 at 9:14 AM, Justin Richer <jric...@mitre.org> 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
