Murray S. Kucherawy wrote:
An issue has been raised regarding the name of the proposed header
field. Some of the methods supported by the draft are specifically
message authorization and not authentication (e.g. SPF, Sender-ID) and
Let's be clear that auth-header already has an operational base and that that
base hasn't complained about its utility. Quite the opposite. The
specification is being submitted into the IETF process because there is already
a community of users who find the current work simple, clear and useful.
So the current discussion is more in the category of considering an enhancement
with respect to possible, unvoiced market benefits. It's important to consider
questions raised about such possibilities, but it is even more important to
keep
them from distracting work that is already vetted.
Unfortunately, your message presumes that the community has a clear and
consistent distinction between the two words, authentication and authorization.
However, the latter term isn't used much in the email authentication and
evaluation game and tends to be used ambiguously or inconsistently... because
it legitimately refers to different things.
In reality, "authorization" comes into play at several stages in a sequence.
Increasingly, the term is proving more distracting than helpful. Any
"authentication" carries an "authorization". Authorization to use the name.
There can be finer-grained authorizations, such as authorization to use the
name
for a particular class of message, or a particular message. There can be other
authorizations. It's a multi-faceted, multi-authorized world out there.
I will claim that none of the discussions here are ever really about
authorization. Even ADSP isn't really in that realm, though one might have a
reasonable, academic discussion that question. However as discussed in the
current draft, ADSP is merely reported as a kind of authentication failure.
First principles: The purpose of auth-header is stated simply, clearly and, I
believe, correctly, as being:
"to indicate the results of message authentication efforts."
Whether those results go to some sort of authorization process or a reputation
process or a network management process, or... doesn't matter. It reports the
results of an authentication phase.
(Separate possible distraction: The document's reference to "so that a Mail
User Agent (MUA) can provide a recommendation" is overly specific and, for that
matter, not all that well tested, IMO. It implies that the results can't be
used
for other purposes. I suggest making the MUA stuff an exemplar rather than a
sole motivator.)
One might have an interesting discussion about creating a more sophisticated
model, in which there might be some sort of post-authentication/pre-reputation
phase that performs some sort of authorization.
But pursuing that sort of paradigm-enhancement now will merely distract and
delay the current effort. It doesn't really affect the current work, so it
should be de-coupled from it.
Because of the existing installed base of code doing this work,
splitting the header field into two (one for authentication and one for
authorization) seems like it would work but something easier could be done.
You left off an easier and, IMO, more appropriate choice: Defer the question
of
authorization. It is a theoretical topic with no demonstrated impact on the
current work.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html