Re: [OAUTH-WG] Definition of XML response format
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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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.commailto: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
Re: [OAUTH-WG] Definition of XML response format
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 e...@hueniverse.comwrote: 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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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
Re: [OAUTH-WG] Definition of XML response format
Why use CDATA? Why not just use unary tags with all the data in attributes? 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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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
Re: [OAUTH-WG] Definition of XML response format
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 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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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
Re: [OAUTH-WG] Definition of XML response format
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 keyscopes/key value type=array element type=stringhttp://example.com/element element type=stringhttp://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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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
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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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.comwrote: 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
Re: [OAUTH-WG] Definition of XML response format
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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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 https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Definition of XML response format
Thanks, George. From that I get this: response oauth_parameter name=oauth_tokentoken/oauth_parameter oauth_parameter name=oauth_token_secretsecret/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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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.comwrote: 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 listoa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Definition of XML response format
I'd personally rather see something flatter, even with an implied root namespace defined in the spec. Maybe like: oauth access_tokenasdfasoij234f/access_token refresh_token2f098jadfasdfasdf/refresh_token expires_in300/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_tokentoken/oauth_parameter oauth_parameter name=oauth_token_secretsecret/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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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
Re: [OAUTH-WG] Definition of XML response format
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_tokenasdfasoij234f/access_token refresh_token2f098jadfasdfasdf/refresh_token expires_in300/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_tokentoken/oauth_parameter oauth_parameter name=oauth_token_secretsecret/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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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
Re: [OAUTH-WG] Definition of XML response format
It would be useful to understand the token type as the AS and RS server may each generate and accept different token types From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Andrew Arnott Sent: Friday, June 04, 2010 6:43 AM To: George Fletcher Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Definition of XML response format Thanks, George. From that I get this: response oauth_parameter name=oauth_tokentoken/oauth_parameter oauth_parameter name=oauth_token_secretsecret/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.commailto: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#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=stringsome access token/access_token refresh_token type=stringsome refresh token/refresh_token expires_in type=number235298298/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.commailto: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.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
