Account selection, new accounts, and reauth

[davidben]

Some flows the provisioning state should probably integrate with:

1. The user may not be logged into the IdP on this device yet.
2. The user may be logged in with multiple accounts and need to pick one.
3. The user may be logged in with some accounts but want to add a new account.
4. The IdP may want the user to reauthenticate to the selected account.

(1) probably wants some provision for the IdP to open a window prior to the consent stage. (2) and (3) could also be IdP-controlled, though if we build account selection into the system, that gives room to solve the NASCAR flag problem in a later extension. (4) looks a lot like (1), though there is also the possibility of moving it post-consent.

[kenrb]

I agree there should be some text in the provisioning stage about disambiguating the different flows. (1) certainly needs to be done via a redirect to the IDP. (2) should probably have one as well, because profile images/avatars are usually displayed to help users choose, and I don't know that we would want to load those into browser Chrome.

For (3), it's the situation where the user has a cookie for exactly one account, but they want a different one. I think a good approach there would be having a "Select another account button" that triggers an IDP redirect from the browser Chrome. The browser needs user input to differentiate this case from the more common case of users wanting to use their currently signed-in account.

Good point about (4) but I think a post-consent sign-in would be confusing. You also have to think about scenarios where, say, (2) and (4) both apply.

[achimschloss]

I also agree that the above scenarios need to be considered, given not properly addressing them now might break usability/user expectation amongst other things. The current description would only work for some flows and assumes a certain state present as described:

• Provisioning stage assumes that the user is logged into the IdP in a prior interaction (ID Token present) (1). Which claims are present in this Token? The ones the first RP requested, the ones the last RP requested, a standard set defined for WebID?
• How would the first execution of the provisioning stage actually look like? In order to provide an ID Token to feed into the consent stage the user would need to sign into the IDP first. Given the proposal does not want to disclose the RP at this stage, effectively the IDP would need to tell the user to sign-into Chrome here and provide his profile? That would come closest to what it seems to be doing.
• The consent stage assumes that the user is registering with the RP. What about cases where the user is already registered with the RP and is only signing into an existing account? The IDP is aware of that, the browser on its own won't know. As described the consent UI provided by the browser would ask the user to register with an RP on every login.

Overall it would be really helpful to sketch out the UI Flow starting from a "blank" browser session and depict the steps for the typically use-cases.

[samuelgoto]

We are actively working on these problems, so I'm going to close this as a duplicate of the following - more recent - issues that we are working on:

The user may not be logged into the IdP on this device yet.

w3c-fedid/active-mode#2

The user may be logged in with multiple accounts and need to pick one.

This is already addressed because we offer a multi-account account chooser.

The user may be logged in with some accounts but want to add a new account.

w3c-fedid/active-mode#3

The IdP may want the user to reauthenticate to the selected account.

w3c-fedid/custom-requests#1

Closing this as a duplicate of these other (more recent) issues, feel free to re-open if you feel there is something that isn't covered.