Collecting use cases that require payment handler window to be 1P context

[danyao]

Let's use this issue to track use cases for payment handler being 1P context to help find the right implementation path for #351 .

• Login persistence: so user doesn't have to sign in on each merchant. Note this is in direct tension with separation of personas.
• WebAuthn credentials can only be created in 1P browsing context

[marcoscaceres]

Maybe also Credential Management API... not sure, but could be useful in this context.

[adrianhopebailie]

As discussed in the meeting on 30 April I think it would be interesting to explore how the security policies of APIs like Credential Management could be changed when in a payment context (i.e. when invoked from inside a Payment Handler).

E.g. a possible flow:

• User visits RP origin in 1p context and authenticates using credential management API.
• RP stores credential using credentials API
• RP payment handler is invoked and it attempts to get a stored credential specifying a 'silent' flow. (i.e. It fails if that is not possible)
• If silent login is not possible RP does higher-friction login

This might not be allowed in a 3p content but perhaps could be allowed if invoked from the PH context.

[tblachowicz]

• I'd like to support the "login persistence" use-case. From payment app perspective It's important to maintain the login session across the merchant websites.
• default/last used payment instrument (card): the payment app shoudl be able to store recently used card or other payment instrument across the merchants.

[ianbjacobs]

Hi all,

I am newly aware of some potentially relevant work in the Privacy CG: isLoggedIn:
https://github.com/privacycg/is-logged-in