Hope a reply on this is ok, that i'm not hijacking and what what i'm saying is relevant here ...
I'm currently implementing OAuth 2.0 middlware for Python/WSGI ... I think that the natural presumption to want to split the compound response type on the '+' is the fault of programmer mentality, and I can see why the argument is being made. I do agree that http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.4 simplifies matters greatly regarding ordering and a lack of implementation significance of the '+' ... but ... I take the meaning that, if the '+' is for readability, then 'A+B's behaviour mustn't be dependent on 'A' and 'B' either, and that the value might as well be "foo" as it is for readability and the behaviour is as an entirely new type which requires consultation of the Registered spec (11.3) for an authoritative answer on how strong the association is. If the association is **always** strong between 'A','B' and 'A+B' and the response and future behavior of the values is tied to their non-compound definition then space delimiting and parsing seems more natural. In response to Eran's questions: 1. Do you find the + proposal as defined in -18 to be useful or confusing? No, not if you don't imply any significance of the value itself and treat it as its own type, in which case the '+' token may as well be '_and_' 2. Should the protocol support dynamic composite values with the added complexity (breaking change)? Only if each of the composite values is intuatively linked to their non-compound usage and that the 'for people' implications of '+' follow through with machine behavior, and you don't need to register the combination because of this, though surely there is alot of scope for clashing in Auth response? ... but then again, I liked code_and_token. --- Thanks and apologies if that was all jibberish or I missed something. Aiden Bell On 15 July 2011 18:44, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > I was only arguing against the proposed text which doesn’t accomplish what > you want from a normative perspective. I can easily address the use case > with very short prose but I would like to see more working group discussion > about it first.**** > > ** ** > > Seems like WG members representing three large OAuth implementations > (Facebook, Google, Microsoft) are very supportive. Does anyone objects to > making the change to allow space-delimited values in the response_type > parameter? Once we get consensus on that, I can proceed to offer a proposal. > The main difficulty is how to deal with errors.**** > > ** ** > > EHL**** > > ** ** > > *From:* Mike Jones [mailto:michael.jo...@microsoft.com] > *Sent:* Friday, July 15, 2011 10:16 AM > *To:* Eran Hammer-Lahav; oauth@ietf.org > *Subject:* RE: Issue 18: defining new response types**** > > ** ** > > Yes, that’s the intent of the change**** > > ** ** > > *From:* Eran Hammer-Lahav [mailto:e...@hueniverse.com] > *Sent:* Friday, July 15, 2011 10:14 AM > *To:* Mike Jones; oauth@ietf.org > *Subject:* RE: Issue 18: defining new response types**** > > ** ** > > You can’t have it both way. Either it is a simple string comparison or it > requires parsing of the string. The current prose is designed to offer a > visual cue without making any code changes to how response types are > compared. To allow different orders, we have to turn the value to a parsed > list.**** > > ** ** > > EHL**** > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Friday, July 15, 2011 10:02 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Issue 18: defining new response types**** > > ** ** > > I agree that this functionality is needed. However, I believe its current > embodiment is overly restrictive. I would suggest changing this text:**** > > Only one response type of each combination may be registered and used for > making requests. Composite response types are treated and compared in the > same as manner as non-composite response types. The "+" notation is meant > only to improve human readability and is not used for machine parsing. *** > * > > For example, an extension can define and register the token+code response > type. However, once registered, the same combination cannot be registered as > code+token, or used to make an authorization request. **** > > to this:**** > > The order of the composite response type values is not significant. For > instance, the composite response types token+code and code+token are > equivalent. Each composite response type value MUST occur only once. **** > > Thanks,*** > * > > -- Mike*** > * > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
