[Adrian Hope-Bailie slides on architecture]
Ian: Adrian and I have done some work in conversation with others to start thinking about architectural ideas that would build on v1 of PR API based on high value capabilities people have identified. We may find that we want to break PR API into smaller composable capabilities.
Adrian: There is no consensus on
this proposal; just for discussion with the WG
... Goals: (1) lower friction (2) high security (3) Privacy
protection
... want to reduce typing to lower friction, but also fewer
clicks
... we want high security to meet various SCA requirements,
risk-based requirements
... want user consent esp. for cross-origin data sharing
... Assumptions (1) origins security policy of the web (2) risk
is evaluated based on data (3) data collection is bad for
privacy (4) payment initiation often happens in 3p context (5)
browsers are limiting 3p powers such as access to cookies
[Adrian shows 4-corner generic payments model]
Adrian: The browser sits in the
"interop" domain, between user and merchant, and as a broker in
various relationshiops
... Our original thought was that the browser could open a pipe
between merchant and RP for data exchange (via the
browser)
... but our newer thesis is that we want to provide more
options
... we want to consider a wider variety of use cases directly,
rather than simply relying on the presence of payment
handlers
... we have endeavored to identify some primitives that can be
mixed and matched in various flows
... the first of these is instrument/payment method selection
... the user decides how to
pay and invokes (implicitly) a relying party.
... the RP may be invoked in a variety of ways
... some examples include entering card info in a form (and PSP
speaks to server) or selecting a wallet button
... we'd like to also include "selecting browser-stored
credential" to this list
... we are thinking about how to create a payment credential
selection UX that does not rely on Payment Handlers (but
without proposing to get rid of PHs)
... assume we have a credential stored in the browser that the
user can select (without going into details about the shape of
this credential).
... a couple of paths are possible: (1) responsible payment
handler is invoked to handle the payment or (2) the merchant /
PSP receives information about the selected credential and
interacts with the RP using traditional rails
... so there are two main paths: through merchant channels, or
through payment handlers
... today we'd like to talk about use cases for the
non-payment-handler use cases
... and talk about what might happen (e.g., event fires in
merchant environment when user selects an instrument)
... the merchant receives an identifier to contact the RP with
info about the selected instrument.
... in the case where we have browser-stored credentials, what
might the UI in the browser look like?
... could the UI vary based on the use case (e.g., minimal UI
we have discussed would not suffice if we are also taking into
account shipping addresses)
... A "payment credential"
is an abstraction that could represent an instrument, or a user
identity. From the user perspective, they see the same
thing.
... But either a PH could be invoked, or the payment credential
could be returned to the merchant
Gerhard: Do we know if there is interest from the merchant in getting a list back (that they can control)?
AdrianHB: I think we won't give
the merchant a list for privacy reasons.
... We've also thought about the "add new X" use case, where
the merchant can take the user down an enrollment flow
... we'll get to that shortly.
... Next assume that the RP has
received the payment request event. The PH can open windows,
authenticate the user, confirm the details
... and it would be great for the payment handler to be able to
invoke SPC without showing its own UI
... so the RP could have an easier time shipping a payment
handler if most of the time no UX is required
... the payment handler could get a list of credentials from a
server and invoke SPC to authenticate the user
... meanwhile, in use cases without payment handlers, it could
work as follows:
... the user has selected an instrument or a wallet...the
merchant (or PSP) should be able to use SPC to authenticate the
user based on the received payment credential information
... today merchants need to embed a RP in an iframe or, even
more commonly to redirect the user to the RP. But the redirect
is not a good UX and there's always the risk the user won't
come back.
... so another core architectural component we've heard
interest in is "in-context" display on the merchant side in a
payment context (similar to what Payment Handlers can do)
... this would allow the PSP to create a non-redirect UX for
enrollment flows and for "card-on-file" use cases.
... some questions: exposing the in-context display with a 1p
context...is that safe?
... one potential way to increase the security is that we limit
the origin of code that can run in the modal window to the same
origin as the selected payment method.
... so for example, suppose google stores a Google Pay
credential in my browser, and the user has selected to pay with
Google Pay, then the merchant could leverage the in-context
display, but only from the google pay origin
... Last piece: In the case of a payment handler, the payment
handler gets a payload from the RP and returns details to the
caller of PR API
... and that information is used for payment
authorization
... Summary: We are thinking of breaking functionality into
some component capabilities:
Adrian: A key idea here is to
enable some powerful capabilities but only in a "payment
context" after the browser has shown something to the user and
there is confidence that the user has explicitly entered a
payment context
... so, for example, the "instrument selected event" would only
be emitted in a payment context
... and in that event handler, could enable some powerful
features because user has chosen this path
... some examples might be:
[Reviewing primitives that are suggested by this architectural model]
[More on in-context display]
[More on SPC]
[More on stored credentials]
Adrian: We want something "like a cookie" that has a few properties:
Adrian: We need to figure out
what the identifier would look like....don't want it to be used
for tracking. But PSP needs to be able to route information to
the relevant party.
... Controlling origins of payment credentials can enumerate,
delete, add, update from 1p context
... but they are managed independently of cookies (and would be
more long-lived)
... The architecture intends to support both flows: selected
credential given to caller of PR API OR selected credential
given to responsible payment handler
... Payment credentials as a class could be managed separately
by the user in the browser (e.g., when to clear them or update
them)
[Adrian describes a flow using components from this architecture: instrument selection + 3DS + SPC]
[Adrian describes a flow with a traditional digital wallet where the handler info is stored in browser, and the handler opens the modal window]
[Adrian describes a flow where the user selects a credential linked to a payment handler that does SRC. User selects Visa payment handler invokes SPC to authenticate the user and doesn't open a window itself]
tomasz: You describe use cases where stored credentials are returned to PSP/Merchant or to payment handler. Payment handlers have limited storage capabilities, so if we could have more storage opportunities for key payment information, that would be interesting
mhofman: Great to see interest
into breaking PR API into smaller features that can be
leveraged by PSPs/merchants
... you mentioned a selector for instruments
... there might be ways to give more UI control to merchants on
how to present payment credentials
... e.g., opaque identifier and web components
... so the merchants could arrange things on the page without
knowing what's there.
AdrianHB: that might also help to solve for the hasEnrolledIInstrument challenge
mhofman: I've had an idea for a
while to get a list of credentials without knowing what they
are, just the number of them.
... other topic - if you need to re-authenticate there are
scenarios where (1) user has not selected instrument or (2)
instrument is known to user but not stored in the current
browser
AdrianHB: One idea for that is that the merchant provides credentials that could appear in the selector ("card on file integration")
mhofman: I am thinking of card-on-file but the card has no corresponding credentials in the browser. You'd have to go through 3DS enrollment.
AdrianHB: You can't be confident about the payment context, but still want the powerful features. Thanks for identifying that use case.
Danyao: Let's have a hallway chat on this!
IJ: How and in what forum should we continue discussions?
AdrianHB: My last slide shows important considerations. We'd love feedback. We can continue on the main WG agenda after people have reviewed the architecture proposal.
[Jonathan refers to objectives spelled out in the proposed architecture for SRC with PR API and specifically the value proposition for SRC through Payment Request]
JonathanG: Updates since previous
meeting on SRC-through-PRAPI using payment handlers. We'll also
look at potential benefits of SPC for these flows.
... Main objectives are
(1) streamlined user experience (2) authentication (3) merchant
choice
... Mastercard has been investigating use of payment handlers.
In April we discussed the user of a "common payment handler"
with limited functionality.
... the idea at the time was simply to redirect to an
SRC-I
... we have been exploring an alternative approach since April,
where there is one-card-per-payment handler.
... each SRC system would operate its own payment handlers.
Payment handler speaks to SRC system. is installed whenever the
user adds a new card.
... a benefit of this approach is that it leverages existing
browser capabilities
... network DCFs can install payment handlers during an SRC
checkout. Or, the bank can do push-provisioning. Or, the user
can install a payment handler when visiting the SRC
administration page.
... payment handlers can leverage indexDB to store information
used to authenticate the user for subsequent transactions
... payment handlers can be invoked using network-specific
PMIs
... payment handlers can already use issuer authentication or
FIDO authentication (but this requires opening its own
window).
[Slide showing benefits of using payment handlers ]
[Slide showing how SPC could further help]
JonathanG: We are excited by
these new capabilities; they are complementary to SRC.
... we wanted to be sure that SPC could be used in other
contexts, usable by merchants, payment handlers, etc.
... we can see two use cases:
JonathanG: in the second use case
the card payment handler can authenticate the consumer with
FIDO without the need of opening a new window (the browser
manages the auth)
... the displayed data is very useful for transaction
confirmation / dynamic linking use cases
... it's also good for payment handler to be able to return
authentication assertion data to the merchant in the PR API
response.
... Another topic of interest is the source of randomness as
input to Web Authentication. We are interested in avoiding the
roundtrip to a server and having the browser generate the
source of randomness; we realize this is still under
discussion
[JonathanG shows some user experience slides]
[JonathanG shows an example of how experience could be augmented through SPC authentication flow]
[Tomasz walks through flow diagrams]
<scribe> ACTION: Ian to ask Tomasz to add new flow diagrams to SRC flow page on GitHub
[UX question that appears on the slide: The browser will ask for consent to install the payment handler (at enrollment). Would it be possible to not prompt the user for consent given the context -- the user is either intentionally adding the card from browser settings or has already agreed to add the card to the browser.]
[Tomasz summary:]
Tomasz: Would be great to combine consent in a streamlined enrollment process
[Transaction flow]
Tomasz: The slide shows "index
db" but in the future that could be one of the "payment
credentials" that Adrian discussed
... it is also interesting in this flow that the authentication
flow could be achieved through SPC without the payment handler
opening a custom window
Chris_Wood: Why are you excluding roaming authenticates from the design?
Tomasz: The user experience with
roaming authenticators is pretty poor today, so we are likely
to skip webauthn in that case.
... We also plan for fallback authentication when built-in
authenticators not available. We want to keep friction low
JonathanG: We could, of course, expand the design as the ecosystem evolves.
Chris_Wood: Cf also my comment about discoverable credentials.
JonathanG: SPC will also facilitate the selection
btidor: I want SPC to address
this question. Part of the value proposition should be to
extend visibility into world of remote authenticatos
... I think the seamless fallback should be preserved
[Visa slides on SRC and SPC]
Gavin: What we'll show here first in mockups is
how we could use SPC with (basic) SRC
... here we are referring to SRC implemented on the user side
(without a payment handler)
... we are sharing mockups here (independent of the demo)
... user experience starts in the issuer's app on a mobile
device.
... the user can enroll a card for use in SRC flows.
... the user can check a box if the device supports a platform
authenticator to be authenticated in future transactions.
... the user enrolls the authenticator. The SRC system is the
RP in this flow.
... During the transaction flow, please note that the merchant
retains full control over the UX
... during checkout the user selects a card from a list. Under
the hood some stored data is used to store the user's SRC
identity.
... if the user consumer chooses a card enrolled to use SPC,
the user sees the SPC verification prompt, authenticates, and
that completes the transaction
Tomasz: Enrollment happens on the issuer domain. So isn't the issuer the RP?
Gavin: We want the SRC system to be the relying party.
IJ: What is the origin of the RP?
Jalpesh: Visa.com
[Manoj Kannembath does a demo]
JonathanG: Can Visa.com prompt
for SPC during enrollment as well?
... because the mocks show the bank's Web site. But the idea is
to enroll a credential with the SRC origin
<btidor> I think Tomasz is right -- the entity that registers the credential is what we've been calling the "controlling party" -- they enroll the credential, and have permission to update the name/logo/etc. in the future. But one of the properties we've been thinking about for SPC is that we want the credentials to be "independently verifiable", so if the public key is shared between the issuer and the SRC System, both parties can verify future assertions.
<btidor> Would that be helpful?
JonathanG: ...SPC allows "get" from another origin. Is it also possible to do "create" on behalf of another origin?
Danyao: Right now that's not
possible. We assume that enrollment requires the RP to verify
the user in a 1p context
... Does the user have to be on the bank's web site, or could
they do so on an SRC origin?
Tomasz: If visa is service provider for bank, then enrollment has to happen (today) on visa origin.
Manoj: When we register the credential, I am hearing that the user would have to see visa.com (instead of fdnb.com)
Tomasz: If you leverage SPC, you
don't need the SRC system to be the RP
... the bank can be the RP
<AdrianHB> A redirect to the RP for enrolment that immediately redirects back to the bank after would work...
btidor: I like this flow; I think
we should find a way to support it.
... I really like the "remember me" checkbox in the UX
JonathanG: Let's take this up in the card payment security task force
<AdrianHB> +1
[Demo shows user logging into issuing bank, seeing a list of cards that can be enrolled into SRC]
[During transaction, user pushes click-to-pay...merchant renders list of SRC cards available to the merchant through the SRC system]
[When the user selects the SPC-enabled card, the browser UX appears to allow the user to verify the transaction, then use biometric authentication]
IJ: How do you populate the list of cards across sites?
Manoj: The card is available across any merchant that is integrated across SRC
Jalpesh: The SRC system is using
local storage.
... in this case visa.com is using local storage in the
merchant site
... other origins can similar store cookies
<Zakim> Ian, you wanted to ask questions about what next for this in the real world?
<nicktr> ian: I am hearing mastercard has gained experience with a Payment Handler
<nicktr> ...that is a little different from the original architecture
<nicktr> ...Also, there is interest in the SPC features
<nicktr> ...So my question is "what would the schemes like us to do?"
Jalpesh: From a Visa perspective,
we'd like to scale the proof of concept and test it out
... we'll continue to work with the Stripe/Google folks on
this, and we'd like to get scale across more platforms
... we like the flexibility of the merchant having the choice
to list cards themselves, or for the browser to display payment
handlers
<nicktr> ian: what other features would make this even better?
JonathanG: I agree with Jalpesh's
point on merchant choice to manage the UX as they want
... I also agree with the idea of setting up a proof of
concept
... the common capability is SPC
... we can debate "what's missing" in the task force
tomasz: I would add to the list of desirable features: the ability of the payment handler to use SPC (specifically trigger webauthn without having to open a window). I would also like to see how we can leverage credential storage and have credential info pushed into the payment handler.
NickTR: Any comments from American Express, Discover, JCB?
Clinton: I think both proposals
are interesting
... more analysis is needed from Amex perspective. Much
appreciated for the overview!
NickTR: Thanks to all the contributors!
[Adjourned until tomorrow at the same time]