ietf
[Top] [All Lists]

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

2012-01-25 12:27:31
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: oauth-bounces(_at_)ietf(_dot_)org 
[mailto:oauth-bounces(_at_)ietf(_dot_)org] On Behalf Of Eran Hammer
Sent: Tuesday, January 24, 2012 10:24 PM
To: Julian Reschke; ietf(_at_)ietf(_dot_)org
Cc: The IESG; oauth(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org 
[mailto:oauth-bounces(_at_)ietf(_dot_)org] On Behalf 
Of Julian Reschke
Sent: Tuesday, January 24, 2012 3:24 PM
To: ietf(_at_)ietf(_dot_)org
Cc: The IESG; oauth(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>