Meeting minutes
Issues list review
https://
Gerhard: Interesting discussion of "what's stored" v "what's passed as input"?
… late binding is nice, but what are you registering for?
… do all the underlying protocols need to pass the data for authentication time?
IJ: What are the benefits to auth-time binding?
Rouslan: (1) Allows credential updates (instead of updating stored information).
(2) If we want to work across multiple profiles or browsers, the way that WebAuthn does that today is data is stored in the authenticator (the browser doesn't store data in webAuthn case)
(3) Private browsing mode is a separate profile; so you could not access the stored data from that mode...but if we pass the data as a parameter, you could still use SPC during a transaction in private browsing mode
… there is an option question: "What would we do during enrollment?"
… if the only thing that's created is a credential, do we need UX?
… we think that the UX is beneficial; we are experimenting with it but don't have enough data yet
… however, the UX would be a privacy and security requirement if we want to allow enrollment of credentials from an iframe
Gerhard: Thanks for the context. It's not insurmountable for browsers to share state. If I register a credential in a browser and give consent to use my Visa card ... we need to be sure that it's the same card I've consented to use the next time
… as service provider, we'd like the browser to store the association instead of us having to keep track of some of the information.
AdrianHB: If I enroll a new FIDO credential with an instrument, in the late binding model is there any binding at all?
… any hints up front to help the user choose the credential I want to use?
… what's the actual relationship between FIDO token and instrument?
Gerhard: It seems there's no need for instrument registration. You are basically consenting to use a FIDO token to be used for "any payment"; not a specific instrument.
… it's not clear all the underlying protocols would support passing of data.
rouslan: We are thinking of multiple instruments should be usable per credential.
… the user would know how the FIDO credential is being used through the browser-native UX
… if a bank participates in the WebAuthn ecosystem, what happens if bank loses credential IDs?
… wondering if it's an issue if a merchant has access to credentials illegitimately; I think it's not a problem since there is still an authorization phase
AdrianHB: RP is responsible for validating instrument is correct.
Rouslan: Correct. In the happy path, the issuer provides a list of credentials and an icon/name and a nonce.
… the merchant invokes SPC
… browser gets the icon/name...once user authenticates, authenticator signs over ALL the information provided as input.
… the relying party can validate the data (also, who is merchant, transaction id (?))
IJ: Does this work for push payments?
AdrianHB: Whoever authorizes the transaction confirms that what the user saw was ok.
rouslan: We are thinking that no instrument info will be provided. And at authentication time it will be provided. There are tradeoffs to consider if we want to allow both.
… at enrollment time it might improve enrollment rate to provide instrument information
… it would be good to experiment with both ways
… a use case of interest for us is for user to reuse FIDO credential to bank for N cards
… I am leaning more towards "just one way to do it"
AdrianHB: This feels like a clean model, but it also allows us to consider payment instruments independent of SPC
… this flow would be interesting:
* merchant declares payment method support
* browser shows list of instruments
* merchant gets back some blob that can be passed as input to SPC for authentication
<Gerhard> Have to drop off guys.
<Gerhard> Thanks for a great discussion.
Next meeting
21 June