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-24 19:04:10
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:julian(_dot_)reschke(_at_)gmx(_dot_)de] 
Sent: Tuesday, January 24, 2012 4:19 PM
To: Mike Jones
Cc: ietf(_at_)ietf(_dot_)org; 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-25 01:03, 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 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."

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:

    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.

(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 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.

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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

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