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:26:49
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: oauth-bounces(_at_)ietf(_dot_)org 
[mailto:oauth-bounces(_at_)ietf(_dot_)org] On Behalf
Of Eran Hammer
Sent: Wednesday, January 25, 2012 7:32 AM
To: Mike Jones; 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

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:Michael(_dot_)Jones(_at_)microsoft(_dot_)com]
Sent: Wednesday, January 25, 2012 12:37 AM
To: Eran Hammer; 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

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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>