Oh, come on Phil, that's ridiculous. Everything not meeting your
taste is "secondary", buth the SAML is the holy bible and the
encyclopaedia galactia. As if the security community was just
waiting for SAML to redefine their terms.
If you get 30 security people together in a room and they argue
over these definitions for days followed by months on mailing lists
and con calls I will give the result rather more weight than
Merriam Webster or Checkpoint marketting litterature. dictionary
definitions are irrelevant to a standards discussion when the
word is already an established term of art in a specialist field.
Take a look at XACML or AAARG.
The weakness of your proposal is that you confuse two separate
points of view. Sure the data in the DNS reflects the fact
that the domain name owner has 'authorized' it to be there. But
the same can be said of every single action a computer takes.
A computer with security controls does not do anything without
an authentication and authorization process having taken place.
"We"? Who? Anyone authorized to arbitrarily define terms in
a way that all other definitions become wrong at once?
Take a look at the list of group members. Most of them are the
principal architects of the main authorization products.
Authentication - The PROCESS of determining that "alice" is
Alice
- The decision arrived at by an authentication
process
Authorization Decision
- A statement by the controller of a resource
granting access to Alice
Authorization Policy
- A statement of the criteria used to make
an Authorization Decision.
This is not convincing. An "authorization policy" is a special
kind of policy, this doesn't mean that every policy needs to be
an authorization policy.
Absolutely. That is the point. Policy has tended to be the catch
all bucket for 'something else'.
What we have in the DNS is not an authorization policy. It could
be called a credential policy.
It is certainly a policy though. The domain is saying 'my security
policy is that all messages that originate from this domain are
capable of presenting the credentials described thus.'
If your definition was applicable for policies in common, you
could never have a policy without authorization.
Policies is a broader term, certainly.
I am talking about the policy of the receiving MTA, the configuration
on which the decision to accept or not a message is based. That's an
Anti Spam Policy, not an Authorization Policy.
I will accept that term.
But how about we think about the general case. I could put a
record in the DNS saying 'all my email is S/MIME signed',
'my email servers always offer STARTTLS', 'My web servers
always offer TLs upgrade'.
Hence I prefer the term security policy as the most general case,
security credential policy.
You might continue to call the decisions whom to authorize an
Authorization Policy, but that's confusing and useless. Because it's
outside the scope to tell domain owner's whom to authorize. That's
their private business.
Actually that was the point I was trying to get across. I thought
you were the person pushing to use the term authorization.
A credential is a piece of data used to authenticate an individual.
usually it is the part carried by the user though rather than the
part used for verification.
E.g. A digital certificate, a password, a biometric profile.
So this is definitely not what we are storing in DNS.
The TCP sequence number is the credential here.
The TCP address is one credential. The sequence number is a
challenge/response token.
There is some precedent for calling the information in the DNS
a credential, but there is none for calling it an authorization.
Why should we call it credential, if it isn't involved in
authentication?
It provides the match criteria. Same as a biometric profile.
The owner of the resource here is the receiver of the message,
it is the receipt of email service that is being controlled.
No. Definitely not. That's nonsense. The resource is the e-mail
address to be used as a sender address.
I will have to think that one through. I believe my viewpoint is
valid. Yours may also be valid.
The problem here is that if you work from the viewpoint of the
email address it starts to look like a DRM problem.
It is my own decision and my policy and nobody else's policy whether
my MTA is accepting unauthorized messages or not.
My view is that if you accept a mail it is by definition authorized,
if you reject it is by definition nont authorized.
Therefore it is a logical impossibility for you to accept an
unauthorized message.
I think that it is completely valid for you to ignore the sender'
security policy or any third party accreditation information if
you choose.
My MTA under my control will enforce my policy only and nothing else.
I guess everyone else will agree with that.
This is consistent with my definition, but not with yours.
I don't think you have understood my position. I understand yours,
you are trying to protect the address as a resource.