[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Interim requirements II!
Hi Bob, I meant the latter (verification of presence), but would also agree that the former should be considered. If we wanted we could generalise these to e.g. "authorization based on [X]", where X is: - freshness of user authentication - type of authentication mechanism - physical location - network location - toe smell (I didn't make that up, look at ECMA TR/46 if you can get a copy:-) - ... Could go on, so I guess we need to prune these at some point. It might be enough for the core assertions work, just to be able to indicate "based on [X]" where [X] is one of the above. Stephen. George_Robert_Blakley_III@tivoli.com wrote: > > Stephen, > > >[R-ReAuth] Ability for server to signal that re-authenticaiton is > >required where you'd normally expect an authorization decision. > > > >I didn't phrase that too well, but I guess folks'll recognize the > >issue. > > Let me test your theory that folks will recognize the issue. > > We discuss a requirement with our customers which may or may not be the > same as this. > We call it either "step-up authentication" or "authorization based on > strength of authentication". > The idea is that the authorization rules state that in order to be granted > access to a resource, > the requester must authenticate using a particular mechanism, which is > normally viewed as > "extra strong" or "strong enough for purposes of this specific access". > > We also discuss another requirement which is at least related to this. I > don't think we have > a name for it, so I'll make one up: "verification of presence". This > requirement says that > in order to perform some action the requester must re-authenticate (perhaps > using the same > mechanism as initial authentication) in order to verify that he or she > hasn't walked away > and abandoned a session which has subsequently been "adopted" by somebody > else. > People familiar with ATM machine security will recognize this one. > > Is either of these what you mean? Are both? > > --bob > > Bob Blakley > Chief Scientist, Security > Tivoli Systems, Inc. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC