Add profile identifier to payment credential structure to support credential fetching?

[ianbjacobs]

Hi all,

In the SRC flow, a persistent user identifier is used to fetch card metadata for display and selection by the user. As browser behavior changes around 3p cookies, implementations are likely suffer.

I was chatting with @adrianhopebailie today about how we might address this (e.g., in a credential management API sort of way). We convered on a particular user experience that we liked and thought we could achieve this by building on top of the (still-being-designed) SPC payment credential data. Imagine for a moment that a payment credential can optionally include an identifier that means "This payment credential is part of a user profile that the RP identifies with this identifier."

We are very conscious of tracking, so this idea endeavors to only provide information with user consent.

Here's how it might work (all from a 3p context)

1. The user clicks a button in a 3p context, which calls Payment Request with payment method identifier "PMI"
2. In the API, the 3p requests that the browser prompt the user to select an identity for from the list
   of payment credentials associated with "PMI"
3. Results:
   0: silently return null
   otherwise: the browser prompts the user to choose an identity. The browser returns (only) the identifier
   associated with the payment credential. (For future discussion: optimizations)

Thus, the identifier is shared with the 3p after two user gestures:

1. Click a "buy" button
2. Select an identity to make a payment.

The identifier can be used to fetch more payment instruments associated with that user identity, and those can be displayed to the user for selection, followed by SPC authentication.

Thus we have parallel behaviors:

1. For identity: ask the browser to have the user pick an identity from stored payment credentials, otherwise silently return null.

2. For authentication: ask the browser to authenticate the user for a list of payment credential identifiers, otherwise silently return null.

[ianbjacobs]

At this point in version 1 of the API there is less and less instrument information stored in the browser. Therefore I am closing this issue for now.