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

From: Mike Jones <[email-masked]>
Date: Wed, 25 Jan 2012 08:37:22 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Tuesday, January 24, 2012 10:24 PM
To: Julian Reschke; [email-masked]
Cc: The IESG; [email-masked]
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-masked] [mailto:[email-masked]] On Behalf 
> Of Julian Reschke
> Sent: Tuesday, January 24, 2012 3:24 PM
> To: [email-masked]
> Cc: The IESG; [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Jan 2012 10:06:23 -0500

My agreement was, and is, to the *production* rules and not the 
*parsing* rules. So long as the former is a proper subset of the latter, 
everything is fine. What's happening here is that the spec is being read 
-- by experts -- as if it were superceding the latter, and that's not a 
good thing.

So as that's the case, I think the solution of using an existing grammar 
by reference but further restricting input to that in the surrounding 
text makes sense to me.

  -- Justin

On 01/25/2012 03:37 AM, Mike Jones wrote:
> Subject: Re: [OAUTH-WG] Last Call:<draft-ietf-oauth-v2-bearer-15.txt>  (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
>
>> Subject: Re: [OAUTH-WG] Last Call:<draft-ietf-oauth-v2-bearer-15.txt>
>> 5226 defines in<http://tools.ietf.org/html/rfc5226#section-4.1>  as:
>>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Jan 2012 08:31:52 -0700

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

> From: Mike Jones [mailto:[email-masked]]
> Sent: Wednesday, January 25, 2012 12:37 AM
> To: Eran Hammer; Julian Reschke; [email-masked]
> 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.
> 
> Of Eran Hammer
> 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.
>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Jan 2012 08:35:35 -0700

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

> Sent: Wednesday, January 25, 2012 7:32 AM
> To: Mike Jones; Julian Reschke; [email-masked]
> 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:
> 
> > Subject: RE: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt>
> > 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.
> >
> > 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.
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Julian Reschke
> > > >> The IESG has received a request from the Web Authorization
> > > >> Protocol WG
> > > In an off-list conversation I heard that what I said before may not
> > > be as clear as it could be.
> > >
> > > So...
> > >
> > > requirements, but in HTTPbis we try to restrict BCP14 keywords to
> > > the actual protocol, not on recommendations on other specs.
> > >

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Jan 2012 13:33:36 -0300

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.

---

From: William Mills <[email-masked]>
Date: Wed, 25 Jan 2012 09:49:19 -0800 (PST)

What I was +1 to there is that it makes sense to limit the character set, and I still think limiting the character set is the right thing to do.  

I have said before in other threads, and still believe, that all of the definition for things like scope need to be in the OAuth2 base spec and should be included by reference in all profiles like Bearer and MAC.   

I also find the argument that we need to make sure that this stuff is parse-able by generic HTTP header parsers to be a compelling one, because the more implementers can lean on extant working parsers the more likely they are to be successful, i.e. let's make sure that PHP can just parse this stuff by default and then we do input validation.

-bill

________________________________
 From: Mike Jones <[email-masked]>
To: Eran Hammer <[email-masked]>; Julian Reschke <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: The IESG <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Wednesday, January 25, 2012 12:37 AM
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

                -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Tuesday, January 24, 2012 10:24 PM
To: Julian Reschke; [email-masked]
Cc: The IESG; [email-masked]
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Jan 2012 14:26:08 -0700

<hat type='TechAdvisor'/>

(see http://tools.ietf.org/wg/oauth/charters )

On 1/25/12 1:37 AM, Mike Jones wrote:
> 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.
> 
> 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.

Yes, input from those (and other) OAuth WG participants would be helpful.

> 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

And that's just what a document editor should be doing.

> would highly welcome their participation as well.

In my role as Tech Advisor, I have reviewed the discussion threads to
date. Julian has pointed out text from the specifications being worked
on in the HTTPbis WG. I concur with Julian's assessment: it would cause
interoperability issues for individual authentication schemes to
special-case the rules about parsing of challenges and credentials.

However, I think it might be acceptable (as Martin Rex suggested) for
such schemes to make recommendations about the actual data that is
conveyed, without special-casing the parsing rules as such (if the OAuth
WG wishes to go down that path, then further discussion with the HTTPbis
WG would probably be helpful so that we get the layering right and set a
good example for future schemes).

> Personally, I'd mostly just like to see the spec finished!

I think we can all agree on that. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/