User Story: Service collecting username, dynamically disclosing options for explicit authentication flow w/without federation service

[achimschloss]

User story

As a user I'm asked by a service to sign-in/up, initially I'm presented with a choice to provide my preferred username to proceed (there is no differentiation between sign-up or sign-in at this point). I'm providing my username preference, the service dynamically exposes me with options to proceed depending on this being a sign-up/sign-in, the services preferred federated login option(s), prior user choices to leverage federated login, characteristics of the username, ...

I'm opting to proceed with a federated login, the service initiates an authentication/authorization flow providing my preferred account to the federated login provider (c.f. login_hint) which runs me through a typical flow resulting being signed into the service (i.e. returning assertions about my identity to the service as authorized by me) .

As a user I'm not expecting that my username/account preference needs to be provided multiple times during this process, if already done at the service initially. As a user I'm expecting that the provided username is processed for the purposes of signing-in.

Context of the story

This story applies to any standard consumer authentication flow, both web and mobile.

Should this be considered sanctioned or unsanctioned tracking?

Sanctioned tracking

Explicit list of parties involved

• User
• Service (Logging into)
• Identity Provider
• Browser / mobile operating system

Complicating characteristics

Additional information

[hlflanagan]

Discussed during 22 October 2021 fedidcg call