Question RE: Tracking and Identity Providers

[whitehatguy]

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.

[arnar]

Thank you for this note, this is an interesting point! I think whether or not DBSC (or any non-interactive device binding) addresses this issue depends on whether the 15/30 minute timeout exists because

a. after 15/30 mins we don't have AAL3/2 level assurance that the same person is operating the device, or
b. after 15/30 mins we think the risk of session exfiltration (i.e. cookie theft) has invalidated the assurance level.

If it is b, then I think emergence of any successful device binding mechanisms should affect the definitions and requirements of the NIST 800-63B assurance levels; and that should probably not be limited to DBSC.

If it is a, then device binding doesn't help and indeed a user-interactive authentication ceremony is required.

I suspect the distinction is not that clear.