Subject: Re: [OAUTH-WG] Definition of XML response format

From: Andrew Arnott <[email-masked]>
Date: Fri, 4 Jun 2010 05:56:03 -0700

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-masked]>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
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 04 Jun 2010 09:34:53 -0400

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">
>    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-masked] 
> <mailto:[email-masked]>> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Andrew Arnott <[email-masked]>
Date: Fri, 4 Jun 2010 06:42:48 -0700

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.

On Fri, Jun 4, 2010 at 6:34 AM, George Fletcher <[email-masked]> wrote:

> 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.
>
>
> 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">
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 04 Jun 2010 10:13:03 -0400

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:
> 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).
>
> On Fri, Jun 4, 2010 at 6:34 AM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> 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">
>>        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.
>>
>>     attributes because it's slightly more compact which might help
>>     small devices.
>>
>>     --
>>     Andrew Arnott
>>     On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         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
>>
>>
>>
>>     [email-masked]  <mailto:[email-masked]>

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          Home: [email-masked]
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

---

From: Justin Richer <[email-masked]>
Date: Fri, 4 Jun 2010 11:14:59 -0400

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:
>         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.
>         
>         > 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">
>         >      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
>         > 
>         > 
>         > <[email-masked]> 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
>         > 
>         > 
>         >

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Jun 2010 10:03:44 -0600

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 <[email-masked]> 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-masked]> 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-masked]
>>         > https://www.ietf.org/mailman/listinfo/oauth
>>         >
>>
>
>

---

From: Kris Selden <[email-masked]>
Date: Fri, 4 Jun 2010 10:42:20 -0700

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

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 4 Jun 2010 22:08:05 +0000

It would be useful to understand the token type as the AS and RS server may each generate and accept different token types

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Friday, June 04, 2010 6:43 AM
To: George Fletcher
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Definition of XML response format

<response>

</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-masked]<mailto:[email-masked]>> 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#<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">

  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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 00:02:17 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Friday, June 04, 2010 5:56 AM
To: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Definition of XML response format

<root type="object">

 1.  no namespace

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 15 Jun 2010 07:03:53 -0700

Nope.  I'm happy to see it dropped.
--
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 Tue, Jun 15, 2010 at 12:02 AM, Eran Hammer-Lahav <[email-masked]>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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Andrew Arnott
> *Sent:* Friday, June 04, 2010 5:56 AM
> *To:* OAuth WG ([email-masked])
>
> *Subject:* Re: [OAUTH-WG] Definition of XML response format
>
>
>

---

From: "William Mills" <[email-masked]>
Date: Tue, 15 Jun 2010 09:33:00 -0700

Why use CDATA?  Why not just use unary tags with all the data in
attributes?

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andrew Arnott
	Sent: Friday, June 04, 2010 5:56 AM
	To: OAuth WG ([email-masked])
	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>

	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.

	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.

---

From: Kris Selden <[email-masked]>
Date: Tue, 15 Jun 2010 09:57:41 -0700

In order to do that
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
>  
> 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.
> On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott <[email-masked]> wrote:

---

From: Kris Selden <[email-masked]>
Date: Tue, 15 Jun 2010 10:28:33 -0700

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