sign-in flows underspecified

[erik-anderson]

When a user encounters a site that support an IDP for which the user has an account but for which they are not currently logged in, it's not currently clear to me how the user flow is supposed to work in terms of getting signed into the IDP so that they can proceed with the RP sign in.

Is the RP site supposed to ask the user to nav away and/or open a new tab to sign into the IDP site directly before returning to the RP site? That would be unfortunate loss of context and be a significant speed bump for users.

I'd imagined there might be some flow where the site might actually want to present a list of 1 to 10 IDPs they support and let the user indicate which one they actually want to try. If not signed in, the WebID flow could allow the IDP to offer a sign-in page.

We should also think about how things should work if the user is signed in with IDP 1 but for that specific RP wants to use IDP 2 even though they have not yet logged into IDP 2 in that browser session.

If we do end up having a model where the WebID flow itself has a sign-in option, implementers should think about through what mechanism browser password extensions should be able to interact with the dialog.

[samuelgoto]

I'd imagined there might be some flow where the site might actually want to present a list of 1 to 10 IDPs they support and let the user indicate which one they actually want to try. If not signed in, the WebID flow could allow the IDP to offer a sign-in page.

Yes, that's my intuition of how this should behave too: " the WebID flow could allow the IDP to offer a sign-in page.".

We should also think about how things should work if the user is signed in with IDP 1 but for that specific RP wants to use IDP 2 even though they have not yet logged into IDP 2 in that browser session.

From a user-behavior backwards compatibility perspective, I was thinking that we would start with a 1:1 mapping: you click on "sign in with X", the WebID account selector only contains accounts from X. If the user is not logged in to X, we fall back to the algorithm you mentioned above, "the flow allows you to login to X".

If we do end up having a model where the WebID flow itself has a sign-in option, implementers should think about through what mechanism browser password extensions should be able to interact with the dialog.

Sure.

[cbiesinger]

this is basically a duplicate of #442 and will be fixed by the proposal in #442 (comment)