[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] AI 60 - Dynamic Session Material
See below. -----Original Message----- From: John Kemp [mailto:email@example.com] Sent: Friday, October 24, 2003 5:24 AM To: Beach, Michael C Cc: Steve Anderson; firstname.lastname@example.org Subject: Re: [security-services] AI 60 - Dynamic Session Material Mike, On Thursday, Oct 23, 2003, at 19:04 US/Eastern, Beach, Michael C wrote: > Based on yesterday's F2F discussion, I am of the impression this item > may change significantly. OK - well, I hope there are some notes from the meeting ;) > However, there is a point in this I am adamant about: > >> From the business perspective, an information/service owner (i.e. - >> Service Provider) is the ultimate authority with regard to its own >> security requirements. > > That would mean the SP would specify the minimum acceptable > authentication "strength", maximum length of timeout settings, and > complete set of authorize-able users. Then potentially an SA or user > could request "stronger" authentication, shorter timeouts, and/or a > subset of the authorize-able users. Neither the SA nor the user can > do the inverse of any of these. OK. I am assuming that you are referring only to the SPs *local* session for that resource? Not that the SP would be specifying the timeout value for a session that was shared with resources at other SPs? Or, are you suggesting that if the SA will not use the timeout value specified by the SP (or shorter) then the request for a session MUST or SHOULD fail? [Mike] - Yes, I am referring only to the SP *local* session. Hadn't really thought about it, but if we go down this road, your failure scenario could be a workable approach -- not that I am encouraging more complexity in this already hard area. > In thinking through how this might work, it seems providing a logical > user experience means not mixing SPs requiring timeouts within the > same session. Today in our real production environment, we have been > unable to mix SP timeouts within the same SSO environment without > introducing user interaction anomalies. This is not a technical > limitation, the anomalies exist even in a perfect environment. I agree with this. I can't see any good way to have a single session that covers resources with different timeout values. - JohnK To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.