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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]