Re: #320: add advice on defining auth scheme parameters

Dear Julian,

I think you're asserting that
> Undefined means undefined, so recipients essentially can do whatever
> they want.
and that recipients are NOT REQUIRED to reject such undefined inputs.
I am right on that, but is it really true as blessed by the specification?

Assuming that, I generally agreeing with the general direction that
new schemes should not break existing generic parsers (but not only the one
you're mentioning).  Especially, it is really bad that <<someparam="1">> and
<<someparam=1>> have different meanings.

The summary of my points are:

1) Allowing, not mandating receivers to accept tokens as
   strings is enough for "generic parsers" you have mentioned.
   The original claim "This is necessary so that
      recipients can use a generic parser that applies to all
      authentication schemes"
   seems theoretically unsound (too strong) for me.
   At least I want to replace this claim with more modest one.

2) It is really meaningful for ABNF to specify
   what kinds of values are expected.
   One example is the stale parameter definition in RFC2617, saying

      stale  = "stale" "=" ( "true" | "false" )

   It is clearly saying that either true or false are accepted,
   and that they are case insensitive.

# Don't take that I am specifically saying about the stale parameter.
# It is just a example of the set-limited-tokens parameters.

3) Then, the rule << realm = quoted-string >> makes sense
   that it says that arbitrary list of ASCII characters are accepted.
   At least it is not as "bad design choice" as you said,
   as receivers are currently not required to reject any token realms.
   I also want to remove this declaration or replace with more modest one.

I don't want the stale rule to be any of the below:

   "stale" "=" word  # it should be either true or false, case insensitive

   "stale" "=" ( "true" | "false"
               | DQUOTE "true" DQUOTE | DQUOTE "false" DQUOTE
               | ...<too much more rules for deprecated excess backslashes> )

   "stale" "=" ( <either token or quoted-string representing
                  case-insensitive name either true or false> )

The current definition is the most clear and informative for implementors,
given that RFC2617 currently does not define generic framework for
the way of parsing you have specified as "ought to be".
What you are saying specifically for the realm parameter
seems to be the same class to the above thing, lacking symmetricity.

You're saying that <<"realm" "=" quoted-string>> is really bad and
should have been defined as <<"realm" "=" (quoted-string | token)>> in the past,
but it also means the stale should have been define as above.
Is it really a choice?


Also, is it too hard "for senders" to require realms to be quoted?
Do we really need senders to be allowed for randomly quoting any parameters?
You really want my parsers (generic in another way) to be rewritten for just
allowing senders for this capability?

# Alternatively, I would be happy if we really define the new generic semantics
# framework for parsing and interpreting the auth-param syntax at this moment, #
and define the realm parameter *using that* (with a caution that senders
# SHOULD send realm in quoted-string for backward compatibility, other Digest
# params SHOULD be cared too), without just saying the previous designers were
# bad.  This is really consistent, and give a clear straight-forward way for
# future designers (including me and OAuth-MAC people) that "syntactical
# constraints ought to be defined on the field value after parsing".

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Thursday, 3 November 2011 23:24:29 UTC