Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

[Eran Hammer <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Eran Hammer
> Sent: Wednesday, January 25, 2012 7:32 AM
> To: Mike Jones; Julian Reschke; [e-mail]
> Cc: The IESG; [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, January 25, 2012 12:37 AM
> > To: Eran Hammer; Julian Reschke; [e-mail]
> > Cc: The IESG; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Eran Hammer
> > Sent: Tuesday, January 24, 2012 10:24 PM
> > To: Julian Reschke; [e-mail]
> > Cc: The IESG; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Julian Reschke
> > > Sent: Tuesday, January 24, 2012 3:24 PM
> > > To: [e-mail]
> > > Cc: The IESG; [e-mail]
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth