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