Meeting minutes
See recap by John Bradley:
https://
More from John on some options:
https://
smcgruer_[EST]: Summary of where I think we are:
1) Path #1 - namespace concept
… with a change to WebAuthn one could make the namespace concept work with login flows as well
… you'd have to say "I want to use for SPC AND login"
… it's a minor change but not great ergonomics
2) Path #2 - do the right thing
a) CTAP would need to change to allow for more bits, and authenticators would need firmware updates
… but platform authenticators could change sooner
… not sure what the timeline would be, but would be faster than remote authenticators
smcgruer_[EST]: We could take either or both paths
<Zakim> Gerhard, you wanted to option 1 (space), would it work on browsers that does not support SPC.
Gerhard: Obviously doing it the right way would lead us to better long-term outcomes. How quickly do platform authenticators change?
… if we go with the namespace approach ("spc:") - question is who defines the space?
… what would the implication be for other implementations?
smcgruer_[EST]: Authenticators would need to support the Webauthn change
smcgruer_[EST]: Browsers would have to implement the WebAuthn change (to allow namespaces) even if they don't do SPC.
Gerhard: I think that the dialog is more important than the cross-domain capability in SPC.
John_Bradley: I got the impression that there was an objection to allowing a vanilla WebAuthn credential to be used in a payment flow.
Stephen: I disagree with that view.
[Discussion of clientJSONData]
JeffH: We have the term "client platform" in the spec...that line can move depending on platform
JeffH: Why shouldn't a vanilla WebAuthn credential be used for payment?
Rolf: If in a 1p context, isn't it up to the RP?
John_Bradley: I tried to make the argument that regular WebAuthn in the WebAuthn namespace should be usable in SPC in a 1p context, but not sure I convinced the person
John_Bradley: So the special namespace would only apply to 3p SPC
… there could be 2 namespaces (one for 1p, one for 3p) but more complicated
Gerhard: It's perhaps interesting to hear the comment. EMVCo's usage of FIDO in 3DS 2.3 suggests "FIDO is good for payments" so to hear "not good for payments" is unexpected.
Ian: Can we write up a short term /long term proposal with (1) 1p and 3p implementation today and (2) changes to CTAP further out
John_Bradley: There seemed to be less resistance to some tweaks to allowing SPC for login; some client platforms could be adjusted
Ian: Would WebAuthn be modified to allow this? Or just implementation?
John_Bradley: Extension definition
… we'd need something to (1)make the extension and then (2) accepting them.
Ian: Where do we define the spc: namespace?
John_Bradley: WebAuthn extension defines the namespace; how you make it and look for it. SPC defines browser behavior in SPC terms
<Zakim> smcgruer_[EST], you wanted to react to Gerhard
smcgruer_[EST]: What if our 1p/3p immediate solution is the current hack in chrome. What would a namespace give us beyond that?
… maybe some small benefits like "could work across different browsers"
… but SPC also currently relies on the conditional UI concept
… we still need local cache
John_Bradley: So the question is - other than the cross-origin authentication property of an SPC credential, what other properties would need to be tracked?
… what needs to be added to a generic WebAuthn discoverable or non-discoverable credential?
Gerhard: (1) payment (2) cross-origin
<Rolf> In WebAuthn-L2 (https://
<smcgruer_[EST]> Rolf: I maybe misunderstand, but thats why https://
<Rolf> So why do we want the Browser to not show the specific SPC UI even before.
<smcgruer_[EST]> Rolf: https://
<Rolf> I think I don't understand the concerns that drive the need for the namespace.
John_Bradley: Let's sort out 1p context first, then 3p context.
… do we need to do anything special in 1p context?
<Ian> Next meeting: 13 Dec
ACTION: Ian to write down a proposal that allows 1p usage, 3p usage, and future CTAP tweak
<Gerhard> Dropping off.
<Gerhard> Thanks everyone.