So, now that OAuth 2 is not solely SP-centric, it probably makes sense
to change some of the encoding (this was written in 2008) :) Also, the
interaction with the Authorization server is more constrained than the
interaction with the resource owner so that also allows for simplification.
I do think that even in the calls with the Authorization server there is
going to be the need to add parameters via some profiling/extension
mechanism. Is your thought that those documents would describe the XML
and JSON structures as well?
As an aside, we also support PHP and Flash serialization. Do we need
separate docs for each format so that it can be native? I think the
approach of the extension was to provide a generic container. Not as
pretty but maybe transformable across formats.
Thanks,
George
On 6/4/10 9:42 AM, 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
<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#
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
--
Chief Architect AIM: gffletch
Identity Services Engineering Work: george.fletc...@corp.aol.com
AOL Inc. Home: gffle...@aol.com
Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
