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