User Story: Sign up to RP using a one-tap widget

[berilee]

User story

As a user I want to sign up to rp.example.com using the one-tap widget flow. The user is already signed into the IDP.

1. The user is signed into their IDP in their current browser
2. The user visits rp.example.com, which they have never signed up to before
3. The user sees the one-tap widget showing continue as bob
4. The user taps continue as bob in the widget
5. The user sees a “verify” message for 1s in the widget
6. The user sees the sign-up button in a new popup
7. The user clicks sign-up and is presented with the RPs screen as a successfully signed up and signed in user

Alternative, user cancels sign-up

1. The user is signed into their IDP in their current browser
2. The user visits rp.example.com, which they have never signed up to before
3. The user sees the one-tap widget showing continue as bob
4. The user taps continue as bob in the widget
5. The user sees a “verify” message for 1s in the widget
6. The user sees the sign-up button in a new popup
7. The user cancels either by:
   a) Clicking the back button in the browser and then sees the RP login page showing the IDP list to sign-up with
   b) Clicking the “x” button and then sees the original page without being signed in

Context of the story

Assumptions

• The new RP user already has an account with the one-tap IDP
• The new RP user is a logged-in user with the one-tap IDP
• The RP has integrated the one-tap authentication flow from the IDP

Scenario

• Consumer: Shows up on various sites on the internet prompting for authentication
• (Does one-tap get used elsewhere?)

Should this be considered sanctioned or unsanctioned tracking?

• Unknown / TBD

Explicit list of parties involved

• RP
• UA
• IDP
• A new RP user

Privacy Implications

• The new RP user should provide consent to sign-in with the IDP before any messages are sent
• The IDP needs to show the Terms of Service and Privacy Policy for the RP
• The IDP needs to inform the user of any shared information
• The RP should not know the user accessed the one-tap flow until the user provides consent

Complicating characteristics

[TBD]

Additional Information

[N/A]

[brdaugherty]

@berilee @hlflanagan if helpful, here are a couple of prior art examples of a one-tap widget to help anchor use cases. Ideally, a traditional "Sign In With IdP" button, manual sign-in method (user/pass), and/or other sign-in methods are surfaced on an account management page/popup with a one-tap dialog being deployed on individual pages across websites -- enabling low-friction direct access to individual pages by authenticated users without first requiring a visit to a sign-in page or dialog.

• academia.edu landing page
• direct navigation to a leaf page
• quizlet landing page
• direct navigation to a leaf page

[brdaugherty]

Google is in the middle of a migration from an old sign-in library that is heavily reliant on third-party cookies to manage user sessions: 1) between a website and the users, 2) between the user and Google. The new library described in this migration guide does not rely on cookies for basic functionality... assuming FedCM is successful.

Sign In With Google cookie usage describes both cookie and session behaviors in-depth.

[hpsin]

The RP should not know the user accessed the one-tap flow until the user provides consent

Should the RP be able to know the user is signed in with a Google account? It's not much entropy, but I imagine "did the iframe pop up" is an easy check to make.

[yi-gu]

The RP should not know the user accessed the one-tap flow until the user provides consent

Should the RP be able to know the user is signed in with a Google account? It's not much entropy, but I imagine "did the iframe pop up" is an easy check to make.

With FedCM, the RP won't know that fact until after the user has created an account with the IDP.

[hlflanagan]

Discussed during the 12 November 2021 fedidcg call

[NekR]

The user sees the sign-up button in a new popup

Is it in User Agent's UI or in website's UI?

I believe this things should be clearly defined. What UI is supposed to be on which end, how it's customizable if it's UA's, what it displays in general, etc.

[NekR]

As far as I understand, this use cases covers only "popup OneTap" which displays over a website. Also, AFAIK, current FedCM API also suggests such case. I would like to point out that there are other cases for OneTap, such as "inline OneTap UI". It can be a button or a whole block of UI. Here is an example: https://youtu.be/sbCU12GrMP8

[dj2]

The FedCM popup UI is browser UI, it is not controlled by the IDP. The name, email and profile picture come from the IDPs account list. There is minimal branding of the button and logo that can be done by the IDP to differentiate the display.

The current FedCM work is around handling the popup UI case and not the inline case. that doesn't preclude it from being provided in the future. We have just been focusing on the popup case as a starting point. The security and privacy considerations of the inline variation would need to be considered.

[NekR]

I believe inline case should be resolved before third-party cookie are removed, otherwise it's going to break products.