Eran agreed to move the restriction on production rules into the core spec. That was what I was agreeing with.
I don't quite understand Eran's new position if he has one. I am in favour of restricting the input, however it is possible I am missing something in this long thread. John B. On 2012-01-25, at 5:37 AM, Mike Jones wrote: > 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: [email protected] [mailto:[email protected]] On Behalf Of > Eran Hammer > Sent: Tuesday, January 24, 2012 10:24 PM > To: Julian Reschke; [email protected] > Cc: The IESG; [email protected] > 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: [email protected] [mailto:[email protected]] On Behalf >> Of Julian Reschke >> Sent: Tuesday, January 24, 2012 3:24 PM >> To: [email protected] >> Cc: The IESG; [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
