OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Assertion Validation Service


Philip Hallam-Baker wrote:
[stuff deleted]
> 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 compltely understand the session requirements, but I believe that
the intention is to provide, in a distributed environment, the same
functionality (user experience) found in a typical operating system.
Specifically:

1. If the user logs out anywhere, he is considered logged out every where.
2. If a user times out everywhere, he is logged out everywhere.
3. If an admin logs a user out, the user is logged out everywhere.

In general I don't believe it will be possible to guarentee that there will
not be unexpired assertions floating around in browsers, caches, etc.
Depending on what you mean by the phrase "the assertions fall when the
credential does." your proposed scheme may or may not meet the session
requirements.

> 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.

I absolutely agree with you. I did not intend to suggest otherwise. 

Further, the operation of the protocols should not change depending on the
specified assertion lifetime. In other words, I must have a fixed rule or
information available in the assertion or somewhere else that tells me if 1)
the assertion is valid until it expires or something it is bound to expires
or 2) I need to check if some authority has declared this assertion to be
invalid.

Hal


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC