If we're tallying votes, I'll re-state my position that I'm also in favor of using the scope syntax definition per 6749 - otherwise it is confusing when writing guidance documentation.
If supporting JSON array syntax is important for this response value, Don's suggestion of introducing a new response parameter seems a good compromise. From: "Donald F Coffin" <donald.cof...@reminetworks.com> To: "'Richer, Justin P.'" <jric...@mitre.org>, Todd W Lainhart/Lexington/IBM@IBMUS, Cc: "'IETF oauth WG'" <oauth@ietf.org>, "Anne Hendry" <ahend...@gmail.com>, "Dave Robin" <dro...@automatedlogic.com>, "Edward Denson" <e...@pge.com>, "John Adkins" <j...@pge.com>, "John Teeter" <john.tee...@peoplepowerco.com>, "Lynne Rodoni" <mrod...@semprautilities.com>, "Marty Burns" <ma...@hypertek.us>, <pmad...@pingidentity.com>, "Ray Perlner" <ray.perl...@nist.gov>, "Scott Crowder" <scott.crow...@qadoenergy.com>, "Uday Verma" <uday.ve...@ilinknet.com> Date: 02/04/2013 01:56 PM Subject: RE: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax Justin, I am involved with the OpenESPI and OpenADE Task Force within the Smart Grid Interoperability Panel (SGIP) which was established to engage stakeholders from the Smart Grid Community in a participatory public process to identify applicable standards, gaps in currently available standards, and priorities for new standardization activities for the evolving Smart Grid. The SGIP supports the National Institute of Standards and Technology (NIST) in fulfilling its responsibilities under the 2007 Energy Independence and Security Act. My particular function is to chair the OpenESPI OAuth sub-committee which is chartered with the integration of the OAuth 2.0 Protocol and the ESPI Standard. Since OAuth 2.0 (RFC6749) has already established “scope” is a space-separated string, it will be very confusing to implementers to no define “scope” as a JSON array. While a JSON array may be what the current space-separated string is converted into when the application is written using Java or one of its variants, there are other programming languages that implementers may select to use. Having to deal with two methods of handling a “scope” response will require additional logic and merely complicate the coding task. Additional OAuth 2.0 specifications should not redefine data elements that are already defined by RFC6749. Implementers should be able to rely on data element definitions within RFC6749 being persistent throughout the OAuth protocol framework. If the OAuth introspective WG feels “scope” should be a JSON array, then the WG should define a new data element rather than changing the definition of an existing data element already defined by RFC6749. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Monday, February 04, 2013 8:24 AM To: Todd W Lainhart Cc: IETF oauth WG Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax I got the same reading of the list as you, and I could go either way. I believe we absolutely must pick one or the other though. If anyone has thoughts on the matter one way or the other, please speak up. The options are: 1) scopes are returned as a JSON array (current introspection text) 2) scopes are returned as a space-separated string (rfc6749 format for the "scope" parameter) -- Justin On Feb 4, 2013, at 10:06 AM, Todd W Lainhart <lainh...@us.ibm.com> wrote: Has there been any thinking or movement as to whether the scopes syntax stands as is, or aligns with 6749? Of the folks who chose to respond, it seemed like the position was split. From: Justin Richer <jric...@mitre.org> To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG <oauth@ietf.org> Date: 01/30/2013 05:34 PM Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax I should add that this is also a bit of an artifact of our implementation. Internally, we parse and store scopes as collections of discrete strings and process them that way. So serialization of that value naturally fell to a JSON list. -- Justin On 01/30/2013 05:29 PM, Justin Richer wrote: It's not meant to follow the same syntax. Instead, it's making use of the JSON object structure to avoid additional parsing of the values on the client side. We could fairly easily define it as the same space-delimited string if enough people want to keep the scope format consistent. -- Justin On 01/30/2013 05:27 PM, Todd W Lainhart wrote: That the scope syntax in draft-richer-oauth-introspection-01 is different than RFC 6749 Section 3.3, as in: "scope": ["read", "write", "dolphin"], vs. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) Should introspection-01 follow the 6749 syntax for scopes? _______________________________________________ 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
