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]>]

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
>