[Webkit-unassigned] [Bug 209586] recent ITP changes causes breakage for seamlessaccess.org

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=209586

--- Comment #2 from John Wilander <wilander at apple.com> ---
Hi, and thanks for filing, Leif!

(In reply to Leif Johansson from comment #0)
> Hi,
> 
> The seamlessaccess.org project aims to improve the login user experience in
> the case when the user needs to select among a large number of IdPs (aka the
> NASCAR problem) without revealing any personal information to the site
> before the user has decided to proceed through an authentication flow via an
> external IdP. 
> 
> Our approach to the UX is to only force the user to identify (typically
> through search at seamlessaccess.org) their most commonly used IdP once and
> remember that and provide a way for sites to initiate a login flow to that
> IdP without learning the IdP until after the authentication response comes
> back to the site. 
> 
> Our current implementation (which we believe suffer breakage as a result of
> recent ITP changes) stores the users choice of IdP in localStorage at
> seamlessaccess.org

Does this mean the user goes to seamlessaccess.org as first-party website and log in there? Do users then revisit seamlessaccess.org or is the login kind of a one-time thing?

> and we provide a component for inclusion on sites which
> makes it possible for users to initiate a login flow.

How does this component work? Is it an iframe from seamlessaccess.org or some other subresource from seamlessaccess.org?

How does the login flow work? Does it take the user to seamlessaccess.org for confirmation and then back to the relying party with some token? Or does the login flow happen in an embedded fashion on the relying party's website?


> This is an approach
> similar to google accountchooser but unrelated to that implementation. An
> important difference is that we do not store any personal information (aka
> account) data but only the public URL of the IdP.
> 
> The part that seems to break under recent ITP changes is that we provide a
> login button as an iframe component (our implementation uses zoid) which
> displays the login choice to the user but without exposing the information
> to the top page; the component iframe wraps an inner iframe with which it
> communicates using postMessage calls to retrieve the IdP choice.

>From and to where does this postMessage communication go? I mean origins, such as seamlessaccess.org.

> The top
> page is not providing an API into the data displayed in the iframe and only
> after the user has clicked the button does the login flow eventually reach
> the site.
> 
> - We are aware that our service *could* track users if we wanted to. We rely
> on community audit and oversight to ensure that we behave responsibly.
> - We understand that our pattern may be indistinguishable from sites that
> engage in predatory tracking behaviour

Thanks for acknowledging these things. It's so much harder to reason about issues and solutions when there's a disconnect on these fundamentals.

> - We understand that we may need to find other ways to implement our pattern.
> - We believe that switching to the recommended oauth2 flow would actually
> increase the amount of trackable state available about users in the whole
> system. Currently the service has no information about who the user is other
> than which IdP they have chosen to use.

I would need more information to understand this. May using some concrete example will get me there?

> We do not see what mechanism is available to us now or in the near future
> for the webkit platform to achieve our goals while maintaining user privacy.
> 
> Please advise.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200326/483c05eb/attachment.htm>