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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] Use Cases


> without requiring any global protocol to manage it. With the ability to 
> force re-authentication at a certain time after the previous 
> authentication, through the protocol, they get even more control over 
> this process. I've cc'd Scott who's working on the SSO 
> requirements to make sure he sees this.

I guess the question I have is one I've seen raised before, namely what
exactly does ForceAuthn mean? How can the IdP have that kind of control when
there are authentication technologies that make it impossible to know for
sure whether the user will even be prompted.

Client certs are tops on that list, since the cert store usually caches the
PIN and repeatedly authenticates with the key for a length of time, often
controlled by the browser, not the IdP.

Even basic-auth behaves this way, though the IdP can work around that one
with a challenge header.

So even if you grant that the SP can somehow "bypass" what we would normally
consider to be SSO processing, that's fairly distinct from actually
reauthenticating the user in a real sense. Or is the implication that the
IdP MUST insure that this happens and cannot rely on technologies that don't
provide that assurance if the Force flag is present?

-- Scott



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