The extensions of "accreditation, reputation, and rate limiting" which
Margaret describe fundamentally involve a 3rd party (since
rate limiting
only looks really useful if audited). If that is correct,
the question
becomes: are these third party assertions something that need to be
tied to the individual MARID assertions, are they an independent
pointer within the record, or are they out of scope?
As a matter of fact, I have made a proposal in this space that does not
require audit, except during the manufacture of trustworthy hardware.
ObDisc: Patent claims on the above are pending, no license is granted, etc.
Let's assume for now that at least the pointers to them are in scope.
Imagine for a moment that MARID includes an extension that
says: these
other people also wish to make assertions about me (with the
implication
that the domain knows about it and is willing to point to it). Is it
possible to extend MARID to do that? Sure. Give those records a
similar syntax
to MARID and it becomes a set of assertions made by two or
more different
parties about the same domain's infrastructure. Silly states
then require
meta-reputation to resolve, but that may not be a big deal.
I beleive that you will need meta-reputation here for any interpretation.
But that is quite easy to synthesize, you simply observe your own mail
and complaints from users about spam.
Is it also possible to do that such that it could be attached to other
assertions, as a generic mechanism for per-attribute
reputation/accreditation/certification?
I am less worried about the interpretation side as the collection side.
I don't want MARID to help interpret data, but I do need it to tell me
that data exists.
Any positive accreditation service that requires input from the subject
is going to be incomplete. Unless you assume that one company is going
to have a monopoly here you have to be able to link to the accreditor.
But the usefulness of either goes back to the issue raised by
Roy Badami--what
does this mean in the context of the extension processing?
Since you cannot be required to provide accreditation data a
processor can always choose to ignore them.
The WG discussions so far seem to have gone down two processing paths:
one in which MARID processing iterates through separate
assertions until
one assertion explicitly allows, disallows or marks unknown the
message traffic;
the other in which all the assertions are taken together to
create three sets:
allowed, disallowed, not known. In the first approach, new
assertions can
easily be defined to have a null affect.
I would term these 'authentic', 'forgery' and 'indeterminate'.
I am not so keen on the list approach since it does not allow
the semantic 'all messages come from this set of IP addresses
AND are signed'.
An alternate approach there is to
specify that
modifiers of a certain type can be ignored such that the base
processing
of the assertions can proceed if they are not understood.
That would mean that
the syntax of the "external pointer" could be left vague
right now, as long
as it is known to be of that type.
I think this is the best approach.
I view the IP address info as being authentication credentials,
the accreditation data is attributes that MAY be used in the
authentication process at the discretion of the recipient.
A
common, practical approach at that point is to limit external
assertions
to ones in which "pretend it wasn't there" processing does no
harm (
I think that we have no choice on this question. Publishing MARID
rules and processing MARID rules are both optional.
In SAML I used a three basket approach, an assertion consists of
a set of statements, a set of conditions and a set of advice.
If a condition is not understood then the whole assertion must
be discarded.
But SAML could do that because it was a completely new application and
there was no existing deployed base.
Without stepping on the toes of the original question asked by the
chairs, I'd be interested in hearing whether anyone believes MARID
will need the "set construction" mechanism, or whether it can
go forward with the iterative processing method. That may
tell us something about the extension mechanism choices and
what our core needs for syntax are.
I think it would be useful to introduce a slightly more expressive
authentication bucket in the XML syntax, specifically:
At present we have a list [A, B, C]
Which is A.B.C
I would like a set of lists {[A, B, C], [D, E], [F]}
Which is A.B.C /\ D.E /\ F
Where . is defined as: T.x = T, F.x = F, U.x = x
And T /\ x = T, x /\ T = T, U /\ U = U, U /\ F = U,
F /\ U = U, F /\ F = F
In other words the SPF precedence rules apply within each list but
the lists themselves are alternatives and the best alternative wins.