RE: Assertion Validation Service

[Hal Lockhart <hal.lockhart@entegrity.com>]

Phillip Hallam-Baker wrote:
> On the need for an assertion validation function, this issue 
> is tightly
> bound to the idea of assertion validity. In particular is it 
> possible to
> revoke an assertion after issue? This by necessity involves a lot more
> mechanism than is currently in the SAML core assertions spec.

Funny you should mention this. This is one of my concerns about "rich
sessions". It seems to me, on a commonsense basis that if somebody "logs
out." That should mean all associated assertions should immediately be
considered invalid. On the other hand, if the assertion is bound to a
transaction document, this case cannot occur and any sort of checking that
requires sending network messages is undesirable. 

This means before I evaluate an assertion, I must have some way to determine
if it might be invalid and who I can ask to find out.

> At present SAML clients ask a question and get to cache and rely upon
> whatever response they recieve until the validity interval 
> expires. This is
> a perfectly reasonable engineering approach for assertions 
> with validity
> intervals tuned to a day or less, it is unreasonable for 
> assertions with
> validity intervals of a year or more.
> 
> I certaqinly agree on the need for assertions with very long 
> lifetimes, I
> have made a status management proposal to manage such 
> assertions. I have not
> made that proposal to the SAML group because I see it as a 
> significant leap
> in the complexity of the client implementation.

I think this is an over simplification. It is natural for a AuthN Assertion
to have a lifetime which repersents how long before we force
reauthentication. Some form of this is present in many distributed
Authentication protocols, e.g. Kerberos.

The lifetime of an Attribute Assertion reflects more how long the
information is expected to remain unchanged, which typically will be
considerably longer. In a business transaction context, it may be convenient
to have the assertion be valid for several days to accomodate overnight
processing cycles, weekends, holidays, etc. This kind of delay is typical in
clearinghouse networks, for example.

Session Assertions have not been defined, so that their lifetimes are not
understood (by me at least) but I expect that they will mostly mark a state
transition (logged in -> logged out) so in effect have an infinite lifetime.

Decision Assertions should have a very short lifetime. It is arguable that
they should not be cached at all. Many products (including ours) support
time of day checking as a part of access policy. This means, the answer may
be different one second from now if the current time happens to be 16:59:59.
Other kinds of dynamic policies can affect this in other ways. 

Marlena Erdos wrote:
> >   Today, attribute authority-like things within enterprises 
> tend to be
> > considered by relying parties as authoritative for all 
> > information they
> > emit.  But in a federated system, a given AA may be trusted 
> > for certain
> > attributes that it issues and not for others.
> >   I'll again  use the notion of a clearinghouse.  A relying 
> > party might
> > consider the clearinghouse AA as authoritative with respect to some
> > sources but not others. Given that one possible attribute query is
> > "Give me all the  attributes for the following principal", 
> the relying
> > party might wish to pick and choose among the attributes it receives
> > back.

I have no problem with this, but I do not see how it relates to "assertion
validation"

To me assertion validation means "I already have an assertion. I will now
check with somebody (same authority or different) to validate the
assertion." As previously mentioned, I would exclude the case of
cryptographic validation, which should be called something else and
considered on its own merits.

It seems to me that a PDP (for example) might make use of assertions from
any number of authorities and combine them in a variety of ways all based in
its internal and invisible to SAML, policies. It might prefer one to
another, it might require them all to agree or some other scheme. In
general, the "same" attribute asserted by a different authority means
something different. This is obviously true in the case of
Entegrity:employee vs. Verisign:employee, but also in the case of
Entegrity:EntergrityEmployee vs. Verisign:EntegrityEmployee.  However, none
of this requires "assertion validation."

Another possibility is that a PDP previously obtained a Attribute Assertion,
but its internal policy says "Assertions may be no older than 5 minutes." In
this case, it can simply request a new assertion from the same place it got
the last one. There is no need for a special "validation" mechanism.

> >   This sort of "attribute validation" mirrors real life (well, my
> > life :-)). There are people I trust to give me certain sorts of
> > information but not other types of info.
> >   There isn't anything spooky about this -- it is just that some
> > people tend to exaggerate and/or distort in certain areas.
> >   Here's a specific example: I had a marketing person who though
> > basically  competent was totally unreliable when it came to 
> > the Federal
> > systems market.  Why?  She never did her own research, but 
> > instead just
> > passed on the pronouncements of the notoriously flaky 
> Federal Systems
> > sales guy.
> >   Why she did this is a whole can of worms, but suffice it to 
> > say, that
> > I learned to regard her information about the Federal market in a
> > different way than I did her info for other markets.
> > 
> >   I believe that in a truly federated system, a relying party will
> > want and need to go through a validation process on the information
> > *in* an attribute assertion.  This strikes me as quite 
> different than
> > validation of authentication information about the asserting party.
> > (I tend to think of that as "around" the assertion.)

In my view all of this processing is a part of the internal policy model
maintained by the PDP or Authority and does not have to be visible to SAML.

Hal