Additional Use-Cases: Active Session Discovery, Auto Sign-On

[achimschloss]

@samuelgoto @kenrb

In addition to the already discussed flows there are additional ones which typically have bespoke implementations, but are quite relevant here:

1. Session Discovery: Allowing a publisher to determine if there is any active user on this device (prior authentication with the IDP happend) - this is highly use-full to adress challenges like NASCAR and allowing the publisher to engage with users based on the IDP choice. Information can be binary, no need to share any user information. This is used with nytimes/medium with Google as an IDP for example, we have similar mechanism.
2. Auto-Sign In: Based on explicit user opt-in per publisher, a user might want to automate the sign-in procedure. That means after authentication with the IDP, visiting a site with the respective opt-in set the user would be signed in automatically. I think this is also a Google IDP feature, we have similar mechanism.

I could think of making

1. part of the publisher side API, as it would be quite simple technically. Another option would be trust tokens, the use case would be similar to calling document.hasTrustToken(IDP) although this seems to be a bit over-engineered given we could just extend the API explicitly.
2. would need consideration in the flows as it relates to skipping parts of it after user choice.

[kenrb]

The first one is certainly something we are interested in and have discussed, for the reasons you describe. There are a couple of technical considerations: first, the browser has to know (or have a way of finding out) which IDPs the user has a session with, which is currently not the case. There are other reasons that might be a good idea. The second consideration is that this becomes a vector for user agent fingerprinting, if a site can enumerate the set of IDPs the user has sessions with. That might not be insurmountable but would need to be analyzed in the context of broader anti-fingerprinting efforts.

For (2), can you explain a bit more how that works? Is it basically a reauth flow, where a user returns to an RP, has an older session cookie for it, and the RP wants the user to authenticate to the IDP again for a fresh ID token? I believe this flow is currently done with cross-origin iframes today but I could be misunderstanding.

[achimschloss]

The first one is certainly something we are interested in and have discussed, for the reasons you describe.

Ok good to hear - in terms of fingerprinting you`re refering to a vector with a bit per IDP login state? Understood, but that would require users the have quite a large number of IDP accounts to become tangible I guess.

For (2), can you explain a bit more how that works?

Yes its a reauth flow by means of a user already having registered with an RP previously + enabeling that. Its an extension of 1) in that sense where an RP would discover that there is an active IDP session and then start a (re-)auth flow. The IDP can assess based on his out-of-band interaction that this a) is a re-auth b) that it was enabled. Technically it could be done in different ways - as you said via third party iframes with postMessage mechanism to pass a token (I think this is how Google does it) or via CORS protected third-party XHR calls.

[achimschloss]

Based on the low level implementation both are of course hard to classify/mediate for browsers, as generally described by @samuelgoto - we can of course split them up as they are related, but can be discussed separately.

[kushal]

FWIW, we'd be quite interested in this for Scroll, and I'm sure similar services would be also. It sounds similar to the idea of supporting isLoggedIn within iframes, which we'e also advocating for.

[samuelgoto]

Ok good to hear - in terms of fingerprinting you`re refering to a vector with a bit per IDP login state? Understood, but that would require users the have quite a large number of IDP accounts to become tangible I guess.

Yep, I think it is clear to me too that we are going to need to support some form of (1). As a reference, here is the API that the Google Sign In SDK exposes:

https://developers.google.com/identity/sign-in/web/reference#googleauthissignedinget

GoogleAuth.isSignedIn()

I agree that we have to be careful about exposing extra fingerprinting bits, but I think that post-consent (i.e. after the user has already signed-in), this seems less troublesome (although it is true that this would always return false pre-consent, which I guess could be used ...).

So, ack, I think you are right that some form of (1) is going to be needed.

I'm still reading and digesting (2), so will come back to this.

[samuelgoto]

On (2), maybe I'm misunderstanding this, but wouldn't this be something that the IDP would know about the opt-in-ness of the user and be able to signal it to a browser? That is, maybe the IDP can return some special status code to the browser and say that no user mediation is required as far as the IDP is concerned (which, I guess, the browser could chose to only obey in case it has seen a sign-in before from this user in this IDP? but ignore otherwise?)?

[achimschloss]

I agree that we have to be careful about exposing extra fingerprinting bits, but I think that post-consent (i.e. after the user has already signed-in), this seems less troublesome (although it is true that this would always return false pre-consent, which I guess could be used ...).

So, ack, I think you are right that some form of (1) is going to be needed.

Ok good that we agree that this is a vital use-case

On (2), maybe I'm misunderstanding this, but wouldn't this be something that the IDP would know about the opt-in-ness of the user and be able to signal it to a browser? That is, maybe the IDP can return some special status code to the browser and say that no user mediation is required as far as the IDP is concerned (which, I guess, the browser could chose to only obey in case it has seen a sign-in before from this user in this IDP? but ignore otherwise?)?

Ack, that is something that the IDP is sure of (given its out of band knowledge) and could be signaled to the browser.

[rblanck]

Because origin trails and features are moving forward, I wanted to know if this feature is part of the trials or is still considered important? For Publishers using ID Login Services, its very important to steer them in the right way to the user. Therefore we need to know which services the users have available in the browser to trigger the right one or the right choice on the page.

I don't see a fingerprint issue when this information is only available for the specific website. As a publisher, we dont need any fingerprint information. We want the users the easiest way to log in.

Any news on this one?

[npm1]

These features (active session discovery and auto sign-in) are both not part of the Origin Trials being done at the moment, but we do consider them important and plan to actively work on the problems discussed here.

I don't see a fingerprint issue when this information is only available for the specific website. As a publisher, we dont need any fingerprint information. We want the users the easiest way to log in.

I believe browser vendors do consider this to cause some fingerprinting issue. A malicious website could abuse the API to determine various different sites on which the user is logged in, thus helping to uniquely identify the user.