plenary

Dan: what's the current status?

Hadley: can come back to this next week, need to dig in

Dan: I want to know the implementation status. Worked on in the Web Payment WG. Multiple orgs working on it. What are the real issues?

Peter: Chrome shows shipping in 95, no signal from firefox or safari

Dan: we could ask multistakeholder

Ken: Stripe etc have been testing this. As I understand, we have this 3D secure in europe, whenever I use my card it has to go through this other authentication thing with my bank, I have to auth with an app on my phone. ???? Webathn and FIDO will provide the same security and avoid all these extra steps ?????

Tess: of issues I raised, one was answered to my satisfaction. Not excited that they're leaving in the callback mechanism for the future, but raising that didn't change anything.

Peter: come back to this next week

Hadley: looks early, mozilla and webkit haven't taken a stand

Ken: seems to be adding webauthn to payments.. assumption.. this is because eg in europe you have this 3D Secure and a lot of these could be delegated and use webauthn instead. The way I'm seeing this you use it the first time, do a payment then it uses a backchannel like 3DS to ask for credentials, whatever your bank or card is, but from that point it can register things and say use fingerprint in the future or something like that using webauthn. So in the future you just use yoru fingerprint r face to do 3DS. That is how I read it. Not really said in the explainer. What is a webauthn credential? Assume it's a fingerprint..

Hadley: proposed solution... says it builds on top of webauthn to add payment data

Ken: and to relax assumptin to allow api called in payment context.. I assume that means I can use my webauthn instaed of 3DS. Assume the way it works is I make a payment, goes to my bank or whoever, they have auth system like 3DS, they can say do you want to register with webauthn as well do you want to use that in future? and you can decide to do that on that device. But the text is very complicated..

Amy: I don't think I"m getting the same reading but I don't know it well... but we shouldn't be guessing what it means, explainer is not well written, not focussed on user needs

Hadley: the proposed solution is after you have registered with a given device and a given provider

Ken: I assume you do that on the first payment, and in the future just log in with your credentials. If I say yes it will register that on that device. A bit like how it works on native apps today.

Hadley: the 9 step process is what happens for any transaction after you've registered. That answers the question I had about the difference between registering and transactins after the registration. Be nice if they could explain the registration process

Ken: later it explains they're extending webauthn

Hadley: what else?

Ken: lots of improvements to explainer.. assumes you know about webauthn.. some examples of webauthn credentials. Generally I think it makes sense. Would make it more effortless to do payments. Today I have to sign in with this national ID.. open an app.. swipe... and people are using less secure things with phone numbers instead. Feature makes sense. Not sure if it's right with webauthn.. technicalities I don't know.

Hi, @ianbjacobs and @stephenmcgruer. We (@rhiaro, @kenchris and I) are looking at this in our [W3CTAG face-to-face](https://github.com/w3ctag/meetings/tree/gh-pages/2021/12-Madripoor). We are scrambling to follow the information flows in the explainer (perhaps a diagram would be a clear way to communicate this?), and to see how this works from a user's perspective (especially the registration process). Would it be possible to add those to the explainer? 

Also, it seems like the explainer assumes a strong familiarity with webauthn, which seems complicated in light of [the ongoing work with them](https://github.com/w3c/webauthn/issues/1667). It would help us a lot if you explain in plain English how you see those working together, again especially from the user's perspective. 

And finally, for our notes: we are reassured to see how much you're focused on privacy, based on the issues in your repo and the thorough Security and Privacy questionnaire responses. That's important in this area and we're pleased to see how much emphasis you are giving to it.

[issues rabbitholes]

https://github.com/w3c/secure-payment-confirmation/issues/128

https://github.com/w3c/webauthn/issues/1667

Hadley: did we review webathn?

Ken: 2015..... and 2020.. doesn't seem to have been deeply reviewed

Amy: I think there was a breakout about payments with Ian a while back that I wasn't in

Hadley: me neither

reviewing Ian's last comment

Tess: [regarding some of the feedback on this issue] (speaking about pragmnatism)

Hadley: in discussions with the automotive wg we still pushed them to be more webby.

Tess: the working group has taken [the] feedback and agreed to disagree ...

Dan: Ok we need to review the videos and the spec links that he's provided.

[we will try to make headway at the plenary]

[everyone watches videos: registration, authentication]

Dan: it's a seperate flow from webauthn even though from end user perspective they might be seeing similar kind of UI. Have we answered the question - is information being transmitted to the website that discloses something about the authentication capabilities of the client during this transaction? Ian is saying with web authentication only the RP... can the website tell something about which authn mechanisms exist on the client in a way they can't do in a webauthn session?

Hi @ian - it's not clear to me if the web site (or another party) would, in the context of this transaction, be privy to information about the authentication mechanisms on the client which might give them more info about the end user than the user would expect to be sharing?  For example - would the web site know that a biometric dialog had been shown to the user?  What if the user chose to dismiss that dialog and opt for another authentication mechanism?  In other words - they click "cancel" on this dialog box?  Would the web site be able to detect that?

Rossen: good question. I hope the answer is no the website doesn't learn anything other than if the transaction completed or not.

Peter: 3 parties - user, web site, bank... What about the Payment Service Provider - and an API... web site always uses an API to the PSP... I never talk to the bank. Like Stripe. I have an account with them - i give them the CC info and PSP handles the interation with the actual bank.

Rossen: that's the equiv of you working with the bank directly... where the middleman comes into play is they create a one to many relationship. From the PoV of you being hte web site author - whether is is PayPal or BofA - it's the same thing.

Peter: concern is - the way it works is that I register a public/private key pair with my bank as a consumer.

Rossen: which you have given to paypal...

Peter: I go to web site - they don't talk to my bank... they talk to paypal. is there a backchannel...

Hadley: PSPs are higher liability transaction providers...

Peter: one would presume the existing flow of dealing with a PSP - this would be the same. PSP should be able to talk to the bank ... Don't see it described anywhere.

Rossen: from my recollection - i'm convinced the range of parties are involved.

Peter: i want to talk to one payment processor. Comment from Ian that it doesn't depend on bank collaboration. Do I have to register with e.g. Stripe or Paypal?

Peter: [posts question]

Hadley: standardized payment method identifiers... behaves - you as merchant you need to have the URL to the payment provider that the purchaser intends to use...

Dan: that might be accomplished in a js library you bring down from stripe?

Peter: as a website developer I have refused to use js libraries that payment processors have asked me to use becuase they contain other things like unsanctioned tracking. So I don't want them to have to grab the whole bundle and let them run whatever code they like

Hadley: this is an important issue and we do need to go down this rabbithole. Do we want to open another issue for this? Wnat to make sure we can give it its full due.

Rossen: I agree. If we start it as part of this issue then fork it into a broader scope issue that will end up in their github repo that will give us better visibility to drive it.

Peter: I'm satisfied with Ian's response. Concerned about how it will evolve, but they're on the right path to evolve in the right direction. Depends how fast banks and payment processes catch up and that industry is slow, but they're doing what they need to do.

Dan: Ian responded in the affirmative to my privacy related question. I think that wraps this up and we should [close]

Rossen: and the conversation between Ian and cypherphone?

Dan: it's a conversation for them to manage..

Rossen: that it will carry on in the respective WG

Dan: Proposed closing comment:

Hi @ianbjacobs - thanks for all the great responses and engagement. The TAG is happy to close this review positively. 
I hope our feedback has been useful. I hope that further conversation on the additional issues raised here can be carried 
on in the appropriate working group forum.

closed