search

fedidcg / use-case-library

Other
11 stars 2 forks source link

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

Open berilee opened 3 years ago

berilee commented 3 years ago

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

Scenario

Should this be considered sanctioned or unsanctioned tracking?

Explicit list of parties involved

Privacy Implications

Complicating characteristics

[TBD]

Additional Information

[N/A]

brdaugherty commented 3 years ago

@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.

brdaugherty commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Discussed during the 12 November 2021 fedidcg call

NekR commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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