Fynbos Update

[Fynbos slides on payment pointers and SPC flows]

AdrianHB: Omer is a colleague working on SPC experiments; we'll look at those today. Since stepping down as co-Chair I've been working at Fynbos on a digital wallet; we are live this week in beta in the US
… one of the main features we include are "payment pointers"
… our hypothesis is that we need a better way to refer to accounts
… payment pointers are really just URLs (a subset of them)
… payment pointers need to use HTTPS and have a path component
… we have a shortened form of it that makes them easier to use
… the URL is the entry point for interacting with the wallet
… payment pointers use content negotiation; apps can use them or they can be used in a browser directly
… e.g., bank allows user to create a "payment request' and they get a payment pointer they can use
… we have an authorization protocol on top of the APIs called GNAP (a successor to Oauth2; developed by same folks; currently in last call at the IETF; expect it to be finalized in the next few months)
… it's a nice way to use OAuth for authorization
… we've defined an extension to GNAP for SPC
… GNAP lets you send a request to a server and request a grant; the authorization service lets you select an authentication mechanism.
… the one written into the spec is a redirect.
… there are also possibilities to do app redirects
… GNAP useful to access open payment APIs
… SPC fits nicely into GNAP
… Omer is writing up a spec based on the work he's done
… so suppose I've been given a card number and a payment pointer by my bank
… I can just enter my payment pointer
… the merchant will initiate interaction on the backend with my wallet.
… the wallet, for example, can redirect me to a site to share some personal information that is part of a single consent

<rbyers> Love the single unified consent, something I've argued we need to be guiding the web towards!

[Basic Flow slide]

Adrian: After authentication, issuer gives a token back to Shopify to execute the payment
… one example we've been thinking about is where a wallet executes a card payment, but rather than doing a follow-on authorization, the authorization happens up front. The token is exchanged for a (tokenized) card on the backend after the authorization has been completed.
… so the issuer authorizes the payment, then gets the access token later from the acquirer

[Video of using SPC]

Adrian: In the demo, there's no redirect. The user types in a payment pointer; the bank gives credential IDs to the merchant who triggers SPC; the merchant sends the assertion back and the issuer returns an access token

Adrian: Next steps would be to experiment with eCommerce with tokenized cards
… the payment pointer becomes a way to initiate a negotiation; but the actual payment rail (backend) does not change
… Open Payment APIs are being documented as formal spec and updated to support multiple payment methods
… our focus has been on the user experience
… we've sought to push complexity to the backend
… normally when you do a delegated authentication it's hard to avoid front-channel interactions
… but we've been trying to move those interactions to the back channel

[Second demo]

Anthony: Love it. Given open banking in the UK running Oauth2, what would the transition be from Oauth2 to new protocols?

Adrian: If you look at the GNAP spec, there's a section mapping to Oauth2. There was an early design decision regarding transition and compatibility
… even if you didn't switch to GNAP, this is not a bad reference to show how easily you can bring in SPC

<rouslan> present?

Adrian: you need to (1) identify whom to speak to to get credentials and (2) get the credentials

Ian: Suggest using FedCM to get the payment pointer

Adrian: Or a payment handler
… e.g., payment handler without UI

rbyers: I love seeing these simple payment demos with minimal UI. Obviously the typing feels like the one piece left.
… how confident are you that issuers are ok with this minimal amount of UI. Should we add more to SPC to increase chance of issuers being happy?

AdrianHB: It think it depends on the use case
… for small amounts in e-commerce may be ok
… we'll have to wait and see, I suppose. We've got a P2P wallet and I suspect will iterate on P2P for the next few months, but e-commerce also on our roadmap
… if we have positive feedback from partners, we'd be keen to do that.
… I'd guess that the UI is the place where the discussion would need to happen. It's the interop domain....but since details are not in specs, we'd need to navigate that carefully.

rbyers: To the extent that people want to adopt, we are open to making changes

AdrianHB: One immediate question form us -- we show the payment pointer
… but if you were to use something else, like choosing a bank (in open banking) and then an account...I'd probably need to see an institution logo
… choosing accounts also interesting

<Zakim> rouslan, you wanted to ask about similarity between CC #s and payment pointers, re: are browsers expected to autofill those, keep it in settings, or pass it through some API?

Issue 197 on logos

SameerT: Very interesting concept. I'd like to break down the flow. When the pointer is typed, is the PSP following an interface?

Adrian: The payment pointer is a URL-as-shortcut
… users could, in theory, also just type in a URL, but we experimented with that and it failed.
… we want the origin of the account issuer
… we don't want to redirect through another origin (e.g,. user's email account)
… URLs also allow redirects.
… on the backend, then, the PSP sends a request directly to the origin of the URL. The negotiation involves (1) what payment methods are available (2) who is payee / who is payer
… the way that GNAP works, your requester is basically asking for a _grant_
… usually what you get back from GNAP upon receiving a request is a request that the user authorize the grant issuance
… and then the user authenticates.
… so the merchant looks to see if browser supports SPC, then initiates GNAP request with SPC; if fails (e.g., no credentials) can fail silently and the merchant can request a different authentication method
… then we imagine exchanging an access grant for a card token to initiate the actual payment
… we are adding extensions to GNAP to support SPC
… when the client requests grant; the server needs to support SPC and have credentials for the account.

[We review the pre-authorization flow]

Gerhard: Any extension required to SPC?

Adrian: I've been looking at SRC to see if it might replace some SRC-I functionality up front
… it's a bit difficult knowing in detail what would be the most sensible way to use the token in a card payment
… but if issuers are satisfied with raw SPC output, great; but if more data is required we can discuss

Adrian: We could find a way to include data in the merchant's initiate request, and the issuer could say "no strong authentication needed"

Gerhard: Should we explore more interactions with IETF re: SPC as a standard option?

Adrian: We've discussed that with them
… e.g., having a generic WebAuthn interaction; the reality is we could have both
… all the modules define in the framework is what data is exchanged
… issuers and servers will decide which one they want to use
… another one we've been discussing is an iframe interaction, where the response is just a URL to use for an embedded iframe; the issuer can do more to gather data (a la methodURL) to decide what to do next
… so first interaction would be "inject iframe"; second would be "step up"

Gerhard: Sounds similar to 3DS merchant app options

JeanLuc: Regarding card-based transactions -- this looks like an alternative to 3DS; however for 3DS there is a proof of authentication that is expected to be re-introduced in the authorization method. I understand this would be an access token
… but there is no card network token definition for this type of token

Adrian: The access token format is not strictly defined
… in theory it could be the same as for an ISO 8583 message
… but I think a more elegant solution would be the token+URL combination from the issuer would be used to make a request to a service and get back what you need for the 8583 message
… so there'd be a round trip before authorization request

JeanLuc: So the access token could either be the proof of authentication, or it could be used to fetch relevant data

Adrian: The advantage of the fetch is that you can decouple the systems
… you could have a separate system that does risk mitigation

<Zakim> Ian, you wanted to suggest IETF/W3C chat at April meeting

Ian: Perhaps there are ways to experiment with this protocol...but implemented as 3DS under the hood.

Adrian: Yes, I could see GNAP as an interface atop existing business functions

clinton: I think the energy towards recognition to payments is critical for browser-based payments. If we had a longer session on this, it would be great (with issuers, payment networks)
… this is a great step; feel like we need more time

Ian: +1 to longer session

<benoit> kudos Adrian .. I echo Clinton's comments that this a huge step forward

fdelache: How does enrollment work?
… have you thought about facilitating enrollment?

AdrianHB: I think the enrollment challenge is outside of the payment flow; but I imagine similar flows after ID&V to prompt the user to enroll
… if the user does not have SPC on the device and are redirected to the issuer; the issuer could enroll the device at that time.

Autofill

smcgruer_[EST]: Regarding autofill (e.g., used in guest checkout): we've been taking a step back lately and want to work with web developers more on autofill to understand needs
… in the world of payments in particular

smcgruer_[EST]: For example, some sites want to disable autofill; we want to understand the use cases
… and are interested in other issues around autofill.

<benoit> google form for comments?

rbyers: We've looked at autofill as a "browser feature" ... developers can see autofill usage; we hope to see more data on how autofill can affect conversion rates

<rbyers> https://www.irccloud.com/pastebin/DLRDBuJj/

<rbyers> Sorry: Example code for detecting whether a field was filled with autofill in chromium browsers at least:

<rbyers> el.addEventListener('change', e => {

<rbyers> console.log('change', e, el.closest("input:-webkit-autofill")==el);

<rbyers> });

Extended meeting planning

<Ian> We are starting to look at dates (late march or early april) for a remote meeting. I hear that there's interest in continuing today's topic as one extended conversation; perhaps we can have a joint conversation with the IETF group working on GNAP.

Payment industry trends?

PSD3?

Update from open banking colleagues

Next meeting

2 March