Paul Madsen wrote:
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
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
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?
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).
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.
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