dbsc
dbsc copied to clipboard
Question RE: Tracking and Identity Providers
The draft proposal currently specifies:
This API—which allows background "pings" to the refresh endpoint when the user is not directly active—must not enable long-term tracking of a user when they have navigated away from the connected site.
I'm curious as to the authors' opinions on whether identity providers should be allowed (where explicitly consented to by the user, perhaps as through FedCM) such tracking capabilities. Here's my background for this inquiry:
Any IdP servicing sessions established with AAL2 or AAL3 per NIST 800-63B are subject to the same session management rules as relying party applications requiring that sessions must be terminated after 30 or 15 minutes of inactivity, respectively.
This impacts user experience in single sign-on in environments with high authenticator assurance levels. As users navigate through different relying party sites through their daily activities, they may continuously be prompted to re-authenticate, depending how recently they last had an interaction with the identity provider. This new proposal seems like an opportunity to solve this problem, by incorporating a mechanism through which the user agent can signal participating identity providers (where consent is obtained, perhaps through as part of a FEDCM implementation) of user presence as part of maintaining a session.
As it currently stands, any person utilizing sites that require AAL2 or AAL3 are essentially forced to re-authenticate when accessing a site after 30 or 15 minutes (respectively) of having last accessed the identity provider (either directly or indirectly), even if the user agent/operating system has knowledge that the user was actively present that entire time. In worst-case scenarios, during an average workday, this could cause 31 additional authentication events for a user.
Please consider this as an opportunity to solve this long-standing usability issue for single sign-on in secure environments.