This feature came up in conversation, so it is probably time to re-evaluate.
Certain assertions in an OpenID request will change over time, and the RP needs to have an up-to-date view of the information. The best way to handle this is by using a short session time on the RP (say half an hour), and then reauthenticate the user when the session expires.
If e.g. the wiki is reauthenticating the user every 30 minutes, the existing authorisation form will be a pain. Pre-authorizing the user for e.g. a day would limit the number of authentication forms presented to the user while keeping the RPs up to date.
One use case for this is disabling abusive user accounts. Due to the distributed nature of OpenID, this would just stop the user from logging in again -- they'd still be able to use sites for which they had an existing session. In this case, the session timeout used by the RP determines its period of exposure.
This feature came up in conversation, so it is probably time to re-evaluate.
Certain assertions in an OpenID request will change over time, and the RP needs to have an up-to-date view of the information. The best way to handle this is by using a short session time on the RP (say half an hour), and then reauthenticate the user when the session expires.
If e.g. the wiki is reauthenticating the user every 30 minutes, the existing authorisation form will be a pain. Pre-authorizing the user for e.g. a day would limit the number of authentication forms presented to the user while keeping the RPs up to date.
One use case for this is disabling abusive user accounts. Due to the distributed nature of OpenID, this would just stop the user from logging in again -- they'd still be able to use sites for which they had an existing session. In this case, the session timeout used by the RP determines its period of exposure.