Consider moving the loginURL behind a .well-known

[bvandersloot-mozilla]

...so the privacy loss occurs when a credential is returned to the RP, not on navigation.

This has the benefit of showing the credential in the prompt, not a generic IDP information

[bvandersloot-mozilla]

Con: this rules out the enterprise use case of many IDPs on a single site.

[bvandersloot-mozilla]

Con: this could be circumvented for widget mode by collecting with "silent" mediation and opening a popup anyway.

[bvandersloot-mozilla]

Pro: this more closely matches FedCM's discovery pattern for button mode

[bvandersloot-mozilla]

Pro: This provides a more informative UI to the user in the not-yet-logged-in use case

[bvandersloot-mozilla]

Important questions:

Should we make the navigation gated by consent or constrain the navigation?
Should the prompt be before or after the login popup is shown?
Which is worse, a "your account on auth.example.com" prompt for not-yet-logged-in-users or introducing a hard requirement on a site-level .well-known and making us keep the requestParameters function?

[bvandersloot-mozilla]

Con: no annotations allowed on the login url, so we would need to add request data parameters and could not remove the pendingRequests call

[bvandersloot-mozilla]

Con: We couldn't even have pendingRequests! we would need to have the IDP store all potential credentials on login, not knowing the RP. I don't think this works, because we need to provide a token on store.

[bvandersloot-mozilla]

@samuelgoto : I think there may be a critical issue here. The IDP needs to know who the RP is when minting a credential under our model. That was made to work (and opened up the timing attack) in FedCM by splitting out the token and accounts endpoints and providing minimal credential and referrer information to them. This model has a single round trip, so I don't think that a RP-blind loginURL works. Thoughts?

[samuelgoto]

The IDP needs to know who the RP is when minting a credential under our model

What for? Wasn't it the case that the IdP could store a credential while logging in the user, before the get flow gets initiated by the RP?

[bvandersloot-mozilla]

I was assuming that the credential's token may need some RP specific information in it in some use cases, as in indie auth's use of it.

[samuelgoto]

Isn't the token something that is produced after a browser prompt, through the id assertion endpoint or through the SAA auto grant?

[bvandersloot-mozilla]

I have been treating the IDP page as the id assertion endpoint (as well as account chooser), so that you can use a credential obtained via Lightweight FedCM the same as one from regular FedCM- otherwise there can be no token member on the lightweight credential.

Another reason to expose the RP is that this allows the authorization flow to work in the same IDP-controlled window.

[samuelgoto]

I'm not sure I'm following you ... Indie Auth works fine with a login-url that is RP agnostic in the well known file ... And it could work equally well with a light weight credential store AND and id assertion endpoint.

[bvandersloot-mozilla]

Actually reopening as this is now an open question.

[cbiesinger]

As you mentioned, this is equivalent to window.open from a privacy perspective.

But my question is, window.open may eventually get some kind of bounce tracking protection (or maybe already does, in Firefox?). The use here, however, has to bypass any such protection. So opening this popup without user action seems potentially problematic, without some kind of protection?

[bvandersloot-mozilla]

Bounce tracking protection is actually easy to prevent from firing here because the popup only needs to get user interaction to prevent it from clearing state.

The more general case of navigational tracking protection is the hard problem, however identifying what is and isn't navigational tracking in the first place is a hard problem that there are no general proposals for at this time.