Paul Madsen wrote:
Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary?
So in the draft... how does the RP ask for the user to be "up-authenticated"?  The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication.  That is what I really meant by the authentications being "standalone".  The RP may relate the two authentications in some way because it requested both.  Maybe that's good enough.

Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone?
Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case.

Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of  mechanism identifiers.
I agree that the combinations can explode... but they are also useful.  For example to hack my account you need both my "password" and my "hardotp". That's two "secrets" that need to be determined for my account to be compromised. (Not that this doesn't stop phishers).



George Fletcher wrote:
+1 simple and straight forward

Just curious about uses cases where the required authentication level changes over time.  For instance, a use case where to view my stock portfolio just requires "password", but doing a trade requires "voicebio".  Is the expectation that authentication events can be treated as "standalone"? or that it's the RP's responsibility to manage the combinations based on the identifier?

One final question... Is it valuable to provide a way to request two or more authentication methods be employed in the authentication event?  For example, administrators of a site must use both "password" and "hardotp".  Everyone else just needs "password".


general mailing list


specs mailing list

Reply via email to