And by 'restrict the encoding' I meant limit the allowed character-set in the value to remove the need for encoding (but encoding which results in a valid value - as unnecessary as it may be - is still allowed). EHL > -----Original Message----- > From: oauth-bounces@xxxxxxxx [mailto:oauth-bounces@xxxxxxxx] On Behalf > Of Eran Hammer > Sent: Wednesday, January 25, 2012 7:32 AM > To: Mike Jones; Julian Reschke; ietf@xxxxxxxx > Cc: The IESG; oauth@xxxxxxxx > Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > > Didn't change my view. I'm expanding it to say that we should restrict the > encoding but at the same time reuse the exact same syntax as the default > header. It's bad for the web if developers write custom parsers just for > Bearer that will break on any other scheme. For example: > > WWW-Authenticate: Bearer realm="example", OTHER-SCHEME > param=something > > Is a valid header but one that will cause clients written to the Bearer spec to > fail. > > EHL > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@xxxxxxxxxxxxx] > > Sent: Wednesday, January 25, 2012 12:37 AM > > To: Eran Hammer; Julian Reschke; ietf@xxxxxxxx > > Cc: The IESG; oauth@xxxxxxxx > > Subject: RE: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > Eran, do I then correctly understand that you've changed your mind on > > the position you took in http://www.ietf.org/mail- > > archive/web/oauth/current/msg07698.html, which was: "All I agree with > > is to limit the scope character-set in the v2 spec to the subset of > > ASCII allowed in HTTP header quoted-string, excluding " and \ so no > > escaping is needed, ever."? I ask this, because if I correctly > > understand your statement that you agree with Julian, you are now > > taking the position that you are OK with recipients being required to > > perform escape processing for the scope (and > > other) parameters and with them being required to accept them either > > as tokens or as quoted strings. > > > > This raises a question I'd like to ask John Bradley, William Mills, > > Phil Hunt, and Justin Richter: Since all of you replied with a +1 to > > Eran's original statement, are you still in agreement with it, or are > > you now possibly reconsidering your position, as Eran apparently has. > > I'm asking, because your messages have been part of the basis upon > > which I've been taking the position as editor that the working group > > consensus is that no quoting may occur. (The other reason that I > > believed, as editor, that this was a consensus position is that this > > syntax restriction has been present in every Bearer draft, as it was > > in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) > > If that's not the actual working group consensus (or it's not anymore), it > would be good to know that now. > > > > Finally, I'd like to respond publicly to a comment made to me in a > > private note sent to me about the current discussions. In it, the > > sender (an IETF "old > > hand") observed that it could appear from the strength of my responses > > to Julian's feedback that I might be trying to defend a particular > > personal view of how these issues should be resolved. I responded to > > him that the irony here is that I'm not trying to representing a > > personal position. Rather, I'm truly trying to do what I believe an > > IETF editor is supposed to do, which is to represent the working group's > positions. > > > > I'm quite open to the working group making it clear that its position > > has changed with respect to Julian's comments and equally open to the > > working group standing behind the text in the current draft. If the > > chairs would like to help bring this issue to successful closure, I > > would highly welcome their participation as well. > > > > Personally, I'd mostly just like to see the spec finished! > > > > -- Mike > > > > -----Original Message----- > > From: oauth-bounces@xxxxxxxx [mailto:oauth-bounces@xxxxxxxx] On Behalf > > Of Eran Hammer > > Sent: Tuesday, January 24, 2012 10:24 PM > > To: Julian Reschke; ietf@xxxxxxxx > > Cc: The IESG; oauth@xxxxxxxx > > Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > I fully agree with Julian's perspective. I believe there is sufficient > > feedback requiring further review of this issue. If the editor cannot > > facilitate a path forward, I request the chairs to intervene. > > > > I will make sure this feedback is fully applied to the MAC token > > specification in the next draft. > > > > EHL > > > > > > > -----Original Message----- > > > From: oauth-bounces@xxxxxxxx [mailto:oauth-bounces@xxxxxxxx] On > > > Behalf Of Julian Reschke > > > Sent: Tuesday, January 24, 2012 3:24 PM > > > To: ietf@xxxxxxxx > > > Cc: The IESG; oauth@xxxxxxxx > > > Subject: Re: [OAUTH-WG] Last Call: > > > <draft-ietf-oauth-v2-bearer-15.txt> > > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > > Standard > > > > > > On 2012-01-23 16:58, Julian Reschke wrote: > > > > On 2012-01-23 16:46, The IESG wrote: > > > >> > > > >> The IESG has received a request from the Web Authorization > > > >> Protocol WG > > > >> (oauth) to consider the following document: > > > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > > > >> <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard ... > > > > > > > > Please see my comments in > > > > <https://www.ietf.org/mail- > > archive/web/oauth/current/msg08120.html> > > > > which I think have not been addressed. > > > > ... > > > > > > In an off-list conversation I heard that what I said before may not > > > be as clear as it could be. > > > > > > So... > > > > > > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication > > scheme. > > > > > > 2) In the IANA considerations, it references the registration > > > procedure defined in > > > <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section- > > > 2.3> > > > (now -18, but that doesn't matter here). > > > > > > 3) That document recommends in > > > <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1>: > > > > > > o The parsing of challenges and credentials is defined by this > > > specification, and cannot be modified by new authentication > > > schemes. When the auth-param syntax is used, all parameters ought > > > to support both token and quoted-string syntax, and syntactical > > > constraints ought to be defined on the field value after parsing > > > (i.e., quoted-string processing). This is necessary so that > > > recipients can use a generic parser that applies to all > > > authentication schemes. > > > > > > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has > > > been mentioned that it might not have ignored it if it had UPPERCASE > > > requirements, but in HTTPbis we try to restrict BCP14 keywords to > > > the actual protocol, not on recommendations on other specs. > > > > > > 5) The registration requirement for a new scheme is "IETF review", > > > which RFC > > > 5226 defines in <http://tools.ietf.org/html/rfc5226#section-4.1> as: > > > > > > IETF Review - (Formerly called "IETF Consensus" in > > > [IANA-CONSIDERATIONS]) New values are assigned only through > > > RFCs that have been shepherded through the IESG as AD- > > > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > > > intention is that the document and proposed assignment will > > > be reviewed by the IESG and appropriate IETF WGs (or > > > experts, if suitable working groups no longer exist) to > > > ensure that the proposed assignment will not negatively > > > impact interoperability or otherwise extend IETF protocols > > > in an inappropriate or damaging manner. > > > > > > In this case the WG exists (it's HTTPbis), and the OAuth got two > > > reviews from HTTPbis pointing out the problem -- from Mark > > > Nottingham, the WG chair, and myself, one of the authors. > > > > > > And yes, I believe the way OAuth defines the syntax *will* impact > > > interoperability. > > > > > > Also, I haven't seen any explanation why OAuth can not follow the > > > recommendation from HTTPbis. > > > > > > Hope this clarifies things, > > > > > > Julian > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@xxxxxxxx > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf