Meeting minutes
PR API update
ian: In the process of getting Payment Request to REC, we got a few expressions of support for our CFC
<Ian> request to advance to CR
ian: the next step is the request to advance to Candidate Recommendation
… (there is cool new tooling)
… with the Director's Approval, we will publish, then there is a 2 month window
… Marcos and I met yesterday to clean up the Implementation Report. We are in good shape.
ian: I expect it to be smooth sailing
… The bigger discussion is probably what happens next after publication
… That will be part of our chartering discussion in the Autumn
SPC discussion
ian: We had a robust discussion at the Task Force on Monday
… We thought we could continue that discussion today
ian: we are moving to store less and less in the browser
… there may be implications for functionality
… The question is "Is this a WebAuthn thing or a Payments thing?"
… Are there other design considerations
smcgruer_[EST]: Emerging questions about "how can these credentials be used"
… at this time, the enrollment UX we added did come partially from a privacy discussion
… to be sure user knows enrollment is for payment
… but the conversation is ongoing whether the UX is necessary
… personally I would like to see enrollment be just a WebAuthn thing. On the server the RP maintains information.
… but auth flow we are discussing is definitely a payments thing
… the various stakeholders need to know what the browser is presenting to the user
Nick: I agree. The authentication piece is definitely a "payment-specific" thing
<Gerhard> present_
Gerhard: There's a simplicity if the browser doesn't have to remember any additional information
… but the CONSENT needs to be clear. I can imagine three levels:
1) The credential can be used for anything
2) The credential is for a specific use case (e.g., log in v. payment)
3) The credential is for a specific instrument
Gerhard: I doubt we will do the first one; but probably likely to do 2 or 3
Ian: I think "enrollment" in upgrade case means "use get() instead of create() with a consent dialog"
clinton_: If you look at this from issuer perspective, if an issuer looks at this credential in a year, it needs to be known specifically 'this is for payment'
Clinton: It doesn't have to be "your card". If an issuer is taking a consumer through an enrollment process. Issuer might want credential bound to "account" rather instrument.
… what you use to pay online securely might be secondary
Rolf: For me, the "credential" term is just a tech term; users don't know what they are.
… we don't want users to think of "one password for card one, one password for card 2"
… we designed WebAuthn with flexibility, so an RP can bind a single credential to an account or even multiple accounts.
… my suggestion here is "assume there is one user to be authenticated" and what the user agrees to may very
… some banks may want the user to enroll a credential with specific instruments, others might want per-account
… so let's not over constrain WebAuthentication credentials
… let the RP decide
… when the bank looks at the assertion, the bank can observe what the user was trying to do
… the assertion looks different, so no need to differentiate the credential
[^^^key observation :) ]
… so the bank can decide whether to accept an assertion based on previous interactions (enrollment time) with the user
<smcgruer_[EST]> +1 to rolf's comments
Gavin: +1 to what Rolf said; don't need 1:1 mapping of credential to instrument
Action: Ian to update requirements document regarding the binding discussion
<clinton_> +1
Gavin: If Visa is the RP party, I should be able, for example, to have one auth credential for all cards associated with the user
<Rolf> makes sense
[Emerging consensus that the RP should decide what binding to use]
Gerhard: There are potential risks of more flexibility (broader binding); we need to think through these.
Gerhard: I think people likely want as few credentials as possible
Gerhard: There's a risk of confusion of binding instrument at the last moment
<Zakim> Ian, you wanted to ask about API implications
PROPOSED: Any WebAuthn credential can be passed to SPC authentication requests.
smcgruer_[EST]: The RP gets to decide whether to give the merchant credential and whether it accepts the usage of that credential.
<Zakim> smcgruer_[EST], you wanted to ask gerhard to clarify the concerns here
smcgruer_[EST]: I'd like to understand more Gerhard's concerned about "which payment instrument."
… there are multiple protections:
1) User sees the information
2) Information is signed
3) RP can decide whether to accept it (and maintains definitive binding)
Gerhard: I've heard concerns about "informed consent" including PSD2 rules
… I think there may be risks here. Has the user given enough consent for payment?
smcgruer_[EST]: I agree with the concern. The argument being made to me from the WebAuthn side is that it's up to the RP to get the consent
… if the bank is going to accept auth for payment, then I am presuming the bank has gotten user consent
Ian: For out-of-band auth flow, does SPC api need special capability (e.g., interrupted since auth now happening out of band)
rolf: There are two options:
a) RP decides to trigger SPC on mobile device
b) ....
… From a usability perspective, I might prefer that auth happens on one device rather than another.
clinton: You need to know who the person is, and what avenue of payment they want to use before you do SPC
smcgruer_[EST]: There might be a related concept that may be lower priority: cross-device authentication
… your browser is doing SPC but your browser has a relationship to a phone
rolf: Special case of smart phone as Roaming authenticator
rolf: Nice thing about this case is phone has a display
… so it would be good for the desktop browser to send the display information to the smart phone
… need to convey payment details to authenticator
rolf: Let's clarify what we mean by "out-of-band"...server reaches out to me on different device
… system we just spoke about (using smart phone as roaming authenticator) is not this use case
Ian: Is out of band an important use case?
Gavin: I think so, but not for SPC
… 3DS has to deal with it.
<smcgruer_[EST]> +1, nothing to do with SPC :)
PROPOSAL: It is not an important use case to trigger SPC on a mobile device via a push notification to fulfill out-of-band use cases
Rolf: +1. We don't need SPC for this. They do this already today with other protocols.
<nicktr> +1
(JeffH: +1)
smcgruer_[EST]: +1
Next meeting
8 July