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

From: Mike Jones <[email-masked]>
Date: Wed, 25 Jan 2012 00:03:15 +0000

Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working group's rationale for supporting quoted-string but not token syntax for these parameters, and for requiring that backslash ('\') quoting not be used when producing them is as follows:

"Once again, the current text reflects a consensus decision of the working group.  It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it."

Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to a subset of the syntax allowed by HTTPbis.  No non-standard code is needed to use parameters in the manner described in the Bearer spec.

The current text is the result of thorough and informed discussion among the working group, and reflects the best consensus available as I understand it in my role as editor, attempting to accurately represent the working group's decisions and rationale.

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Tuesday, January 24, 2012 3:24 PM
To: [email-masked]
Cc: The IESG; [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 01:19:07 +0100

> "Once again, the current text reflects a consensus decision of the working group.  It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implement…

Mike, you continue to ignore that WWW-Authenticate needs to be processed 
by generic parsers, as a single instance can contain challenges for 
different schemes.

If you disagree with the text below:

(which is from the text defining the registry you are using), then 
please come over to the HTTPbis WG and ask for a change. It's 
work-in-progress.

> Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to…

That is not true. Using standard components will cause recipients to 
accept invalid field instances, which *is* an interoperability problem.

This has happened before: RFC 2617 states that the realm parameter needs 
to be quoted, but we see that all browsers accept the token form as well 
(<http://greenbytes.de/tech/tc/httpauth/#simplebasictok>). That's not a 
surprise because it's the natural thing to do with a generic parser.

Please don't add to the mess. In particular when there really is no 
reason to do so. All I heard from you is: "we prefer it that way". I'm 
sorry, but that's not sufficient.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Jan 2012 00:52:24 +0000

Thanks for asking, Martin.  That's effectively what the spec does already.  It restricts the input values of these parameters to be quoted strings containing no backslashes.

As long as that syntax restriction remains in place, it wouldn't actually matter whether the BNF for "scope", "error", "error_description", and "error_uri" continues to be defined as "quoted-string", is defined as "token / quoted-string", per HTTPbis, or defined by referencing the HTTPbis "auth-param" definition and containing no parameter-specific BNF declarations.  The meaning of the spec would remain the same.

It's written the way it is, at present, because it would seem to be clearer to implementers what the restrictions are by using the "quoted-string" BNF production, rather than by imposing the restriction only in prose.  But if deleting the BNF definitions and leaving the syntax restrictions in the prose would resolve this issue for people, I'm pretty sure the working group would be fine with that, as it would be a non-normative change.

				Best wishes,
				-- Mike

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2012 4:29 PM
To: Mike Jones
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The

Mike Jones wrote:
> 
> Per the discussion at
>    http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html,
> the working group's rationale for supporting quoted-string but not 
> token syntax for these parameters, and for requiring that backslash 
> ('\') quoting not be used when producing them [...]

I'm slightly confused...

Instead of inappropriately re-specifying the WWW-Authenticate:, how about referencing the original specification an rules, and then add your desired requirements for *creation* of the contents on top of that, so that oauth-bearer can permit recipients to reject stuff that doesn't fit the additional "send-requirements" when processing the request.

I would assume that pretty much all authentication schemes will effectively require subsetting of what can be conveyed to what they can parse, and further subset this to what they can successfully verify, and reject everything else -- without having to rewrite the WWW-Authenticate syntax.

-Martin

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Jan 2012 01:03:32 +0000

Typically "interoperability" is only meaningfully defined over legal inputs to a protocol.  There is no expectation of interoperability when values outside those specified as being legal by a protocol are used.

The case you cite below of implementations that "accept invalid field instances" is then, almost by definition, not an interoperability problem, as what you're concerned about is the behavior of implementations when sent illegal inputs - not the behavior of implementations when producing and consuming legal protocol values.

I believe that that's the key distinction that is causing you to look at this issue differently than much of the working group.

				Cheers,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2012 4:19 PM
To: Mike Jones
Cc: [email-masked]; The IESG; [email-masked]
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

> "Once again, the current text reflects a consensus decision of the working group.  It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implement…

Mike, you continue to ignore that WWW-Authenticate needs to be processed by generic parsers, as a single instance can contain challenges for different schemes.

(which is from the text defining the registry you are using), then please come over to the HTTPbis WG and ask for a change. It's work-in-progress.

> Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to…

That is not true. Using standard components will cause recipients to accept invalid field instances, which *is* an interoperability problem.

This has happened before: RFC 2617 states that the realm parameter needs to be quoted, but we see that all browsers accept the token form as well (<http://greenbytes.de/tech/tc/httpauth/#simplebasictok>). That's not a surprise because it's the natural thing to do with a generic parser.

Please don't add to the mess. In particular when there really is no reason to do so. All I heard from you is: "we prefer it that way". I'm sorry, but that's not sufficient.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 09:37:14 +0100

+1

 > ...
> If you want to keep the distinction, you should offer an argument why
> this is something individual schemes should regulate (since having the
> same rules for all schemes is much simpler).
 > ...

Exactly. I've been asking this many times, but I'm not getting any 
answers except "we prefer it this way".

Best regards, Julian

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jan 2012 01:28:58 +0100 (MET)

Mike Jones wrote:
> the working group's rationale for supporting quoted-string but
> not token syntax for these parameters, and for requiring that
> backslash ('\') quoting not be used when producing them [...]

I'm slightly confused...

Instead of inappropriately re-specifying the WWW-Authenticate:, how about
referencing the original specification an rules, and then add
your desired requirements for *creation* of the contents on top of that,
so that oauth-bearer can permit recipients to reject stuff that doesn't fit
the additional "send-requirements" when processing the request.

I would assume that pretty much all authentication schemes will effectively
require subsetting of what can be conveyed to what they can parse,
and further subset this to what they can successfully verify, and reject
everything else -- without having to rewrite the WWW-Authenticate syntax.

-Martin

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 25 Jan 2012 03:14:26 +0100

* Mike Jones wrote:
>Thanks for asking, Martin.  That's effectively what the spec does
>already.  It restricts the input values of these parameters to be quoted
>strings containing no backslashes.

Most XML parsers do not tell you, and most XML generators do not allow
you to control, the difference between <x y='z' /> and <x y="&#x7a"/>.
You could make a specification that says the value of the y attribute
on the x element must not be z, but it stops there. The difference be-
tween the two XML elements is in the lexical space, not in the value
space, the attribute value in both cases is "z", it's just encoded in a
different form.

Try writing a C function `int example(int i)` that returns `1` when it
is called like `example(00)` but returns `0` for `example(0)`. Without
some hack you can't do that because the C specification defines that it
does not matter whether you write `0` or `00` for an int. Same problem,
just as the C specification does not give you an interface to tell the
two inputs apart, the HTTP specification does not give you an interface
that allows you to tell `x` and `"x"` apart in this particular case. If
the draft said "When using WWW-Authenticate: Bearer ... then the header
name must be written `wWw-authenTICate`, same problem. HTTP says case
does not matter, and if another specification says "Yes, it does" then
it is overriding the underlying specification, to some degree anyway.

This is not always wrong, you might have coding guidelines for example
that tell you to write `example( 0 )` instead of `example(0)` and that
may work well with limited scope, but with coding guidelines people are
typically aware that they impose limits on formally equivalent things,
along with the understanding that if someone ignored the restriction the
code would work just as well, but that does not seem to be quite the
case here. If I make another scheme, WWW-Authenticate: Example, and say
all the parameters must be tokens, not quoted strings, and the tokens
must not contain "q" characters, but they are case-insensitive so you
can use "Q" to the same effect, would that be just as well?

If you want to keep the distinction, you should offer an argument why
this is something individual schemes should regulate (since having the
same rules for all schemes is much simpler).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jan 2012 04:48:48 +0100 (MET)

Bjoern Hoehrmann wrote:
>                   the HTTP specification does not give you an interface

Of course, what oaep-bearer could _not_ "define to not exist"
(no matter how much anyone (group) might desire this), is those
transformations, and their complexity, that are permitted on HTTP
that headerfield, e.g. through "middle-boxes", such as client-side
HTTP proxies or server-side reverse-proxies between the original
creator and the final consumer, as well as permitted side-effects
of other application components sharing the same client (like a browser).

-Martin