Dan,
Thanks, I think that the "basic" and "digest"
may be a start at providing values for transport
level authentication, in addition to the
changes in CertRef for Arvola's
client-side SSL/TLS authentication descriptions.
I am, however, concerned that
we may need to add some more
information to reflect agreements
that nail down the factors needed for
interoperability for authentication at
"transport layers".
For example, the "basic" authentication
scheme might be augmented by information
about the realm. For the "digest" authentication
scheme family, it looks like more mechanisms
have been added since rfc 2617-- e.g., those
of rfc 2831. Also, parameters like "qop-options" may
be used, and are consequently matters that
a CPA might specify, because an interop.
issue might stem from different capabilities
among implementations. Likewise, a server
may optionally choose to specify that
the authenticator use some other digest
algorithm than MD5, which might frustrate
interoperability. If we do decide to add
specifying these functions in version 1.1, we should have
a survey of specified and/or used-in-practice
mechanisms, and their parameters, whose
configurability or optionality may impede
interoperability.
I only "half follow" all the variants in
this area, and do not have a good sense
for what is really used in practice
(especially for b2b communications)
and/or what is just specified in some rfc.
If someone could create a table/list/
/spreadsheet enumerating the existing
variants, and the optional parameters
in these variants, we could then proceed
to propose the additional elements and
attributes needed in CPPs and CPAs for
HTTP authentication.
So, do we have voluteers?
Dale Moberg