Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
berilee opened this issue Nov 10, 2021 · 9 comments
Open

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

berilee opened this issue Nov 10, 2021 · 9 comments

Comments

@berilee
Copy link

berilee commented Nov 10, 2021

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]

@berilee berilee changed the title User Story: User Story: Sign up to RP using a one-tap widget Nov 10, 2021
@brdaugherty
Copy link

@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
Copy link

brdaugherty commented Nov 12, 2021

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
Copy link

hpsin commented Nov 12, 2021

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
Copy link

yi-gu commented Nov 12, 2021

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
Copy link
Contributor

Discussed during the 12 November 2021 fedidcg call

@NekR
Copy link

NekR commented Feb 13, 2022

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
Copy link

NekR commented Feb 13, 2022

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
Copy link

dj2 commented Feb 14, 2022

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
Copy link

NekR commented Feb 16, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants