RE: Assertion Validation Service

[Philip Hallam-Baker <pbaker@verisign.com>]

Let us break this down, in doing so note that the use cases glossary is
surely wong in its definition of logout.

Alice has assigned to her some long term credential.
	This may entail authentication by means of a password or 
	proof of possesion of a private key.

Alice enters into some authentication protocol
	As a result of which a short term access token is
	issued, or short term credential.

'Authorizations are attached to Alice via an assertion'
	The exact mode by which this occurs is not relevant.
	How the authorizations bind to alice is relevant however.


1) The assertions may bind to the name 'Alice'
	In this case the auth assertions exist independently of
	an authentication session Alice may have established.

2) The assertions may bind to the long term credential
	In this case too the auth assertions are independent
	of any session

3) The assertions bind to the short term credential in which
	case the assertions fall when the credential does.


At present we can support any of and all of these models.
There are advantages and disadvantages in each case.

The concept of 'log-in' and 'log-out' are not intrinsically
distributed events. In the case where the long term credential
is a public key authentication they map to availability or not
of the private key which is intrinsically a local matter.

I don't think it is the place of a standards committee to set
security policy. The length of time for which assertions may
be cached is not something this committee should be deciding,
the provision of a mechanism which allows the length of time
to be specified on the other hand is in scope.


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Tuesday, April 17, 2001 12:35 PM
> To: 'Philip Hallam-Baker'; 'Marlena Erdos'
> Cc: oasis sstc core
> Subject: RE: Assertion Validation Service
> 
> 
> 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
>

Phillip Hallam-Baker (E-mail).vcf