Meeting minutes
SPC updates
Stephen's slides on SPC requests
smcgruer_[EST]: We'll start today with "what we heard at TPAC"
smcgruer_[EST]: We'd like to prioritize those things we've heard
smcgruer_[EST]: We've completed two things recently: (1) spc can be called without user activation; shipping in M118 (stable)
… this "no user activation" is limited to once per page load
… second thing done is (2) SPC support for device-binding extension (M120)
… SPC allows you to set web authentication extensions.
… this is distinct from DPK shipping....but the point is SPC allows you use these extensions
<rbyers> ian: Did allow extensions involve changes to the spec?
smcgruer_[EST]: there was no change to the spec (which already allowed this)
… it's just the implementation that caught up
<rbyers> Ian: Were the people who most wanted the no user activation informed of this? Do they know it shipped?
<rbyers> smcgruer: don't know, hope they're in the room?
Doug: We tested the "no user activation"; works well
smcgruer_[EST]: Now let's walk through the other requests we've heard. We'd like to start to understand priorities
… in the slides I've listed an approximate effort level required to implement
smcgruer_[EST]: "Support for userVerification=discouraged"; this would allow for some uses without full biometric.
rbyers: Re prioritization - we'd like to understand where we get bang for our buck. Are there things here that are adoption blockers?
… at this point we want to know if there are blockers or whether we should stop investing
JeanLuc: This userVerification=discourage could help with device recognition; I have been thinking about this for other use cases as well
JeanLuc: E.g., it might be used to identify the platform not just the user. I am doing more investigations.
smcgruer_[EST]: (2) Card art icon is too small. This is "moderate" effort because relates to UX
smcgruer_[EST]: (3) Fallback UX improvements. (No matching credentials UX).
… previously we have discussed tri-state outcomes.
smcgruer_[EST]: (4) Issuer/network icons (and more generally icons representing entities involved in the transaction)
smcgruer_[EST]: (5) Native SPC for Android
smcgruer_[EST]: (6) Allow normal WebAuthn credentials for first-party SPC.
… this is possible on both Windows and MacOS. We could add this support if there are e.g., banks who want to use existing credentials or simply don't want others to use their credentials
smcgruer_[EST]: (7) MacOS same
smcgruer_[EST]: (8) Support roaming authenticators. For this we would need to revisit SPC UX
smcgruer_[EST]: (9) Support hybrid authenticators
smcgruer_[EST]: (10) Minor experimental UX tweaks. This is low effort and we can experiment easily (behind a flag)
… if people have minor ux tweaks they want to experiment with, ask!
smcgruer_[EST]: (11): Remove/change primary iconography on SPC dialog. (e.g., vaguely fingerprint thing on MacOS). Moderate effort due to UX effort
smcgruer_[EST]: (12) Showing RP origin in SPC transaction dialog. This is low effort.
smcgruer_[EST]: (13) Recurring payments
smcgruer_[EST]: (14) Non-payment use cases
smcgruer_[EST]: We also have heard a number of requests related to capabilities not in browser control
smcgruer_[EST]: (1) Authenticator support for thirdPartyPayment bit in windows, macOS
smcgruer_[EST]: (2) Safari support
smcgruer_[EST]: (3) Require biometrics for an authentication
… this would require work across FIDO or the platform authenticators
Tomasz: Regarding these last 2-3 items. I think these are blockers to adoption of SPC.
… until there is more browser support (of SPC and thirdPartyPayment bits and UI improvements) we may not see more adoption
… perhaps as a WG we can exercise more influence on the other parts of the ecosystem.
rbyers: We generally have to build usage in a constrained way first in order to get broader browser adoption.
smcgruer_[EST]: Other things on the list - attestation, know which authenticator method was used, combine SPC with FIDO biometric, get platform auth dialogs to stop saying "sign in"
smcgruer_[EST]: There might be some work in WebAuthn on nature of biometric.
<rbyers> Ian: Anyone at authenticate conference have things to share?
Rolf: Regarding adoption, EMVCO has added SPC to 3DS, but to see adoption might take some time
… need to get this into ACS's then we can get more pilots out
… I am getting positive feedback on pilots.
Rolf: Regarding attestation; this is progressing (esp. for passkeys)
… we are seeing convergence to security-style attestation
… I think there's a new proposal for the device binding extension
… from a FIDO we should have done enough to allow the use of security keys for SPC
<rbyers> Ian: Talked with someone that device public key has some concerns, but perhaps less in SPC scenarios?
Rolf: There are regulatory environments where strong device binding is required.
rbyers: We do have DPK working behind a flag.
… I like the idea that the bar is different for SPC than WebAuthn generally
… if people would like to get SPC + DPK working, I could discuss internally a version of DPK with SPC before WebAuthn generally
Rolf: I don't think that the only need is SPC. There are two use cases - another one was implemented early on (MFA).
… those people need a solution quickly.
rbyers: Email Stephen if you want to test it out behind a flag.
smcgruer_[EST]: Any prioritization people want to discuss today?
… are there any suggestions that I've missed?
<rbyers> Ian: Ones Tomasz and Rolf mentioned was getting 2nd browser support and authenticator support for 3p payment bit. Why is that a high priority?
<rbyers> Tomasz: didn't mean to suggest 3p payment bit was necessarily high priority, not prepared to prioritize the list now.
<rbyers> Ian: maybe if folks could come back with their top 5 list? Maybe in 3DS working group?
SameerT: from a 3DS WG POV we can classify these
… and flag blockers
ACTION: SameerT to work with the 3DS WG to come with a priority list and identify blockers.
ACTION: Ian to send Stephen's list to the WPWG (and some non-WG partners) to ask for prioritization input.
Berlin Group meeting
Announcement of 30 October agenda with Berlin Group
JeanLuc: I read the doc. The proposal involves signing the payload. Maybe we should do the same with SPC.
… cf interesting Yubico proposal (see Using WebAuthn for Signing) involving hash of payload. Should we sign hash of payload?
… in SPC
… this would create synergy between our proposal and theirs.
Rolf: Whatever you get as client data is outside of control of authenticator
… maybe it's more like adding a transaction hash value to the collected client data...at the same level that SPC sits today
Rolf: So basically augment collected client data
<rbyers> Ian: if WebAuthn took as input to the client data a hash value (in addition to whatever else), that would work if just doing WebAuthn, right?
Rolf: What we really want with SPC is an assertion that the user has seen what they signed
… that's controlled by the client platform int he case of SPC
… in that case, it makes sense to include structured data, not just hash
… in WebAuthn Level 1 there's an extension (defined at authenticator level)
… that txAuthSimple Extension could be reworked to sit on SPC level.
<rbyers> Ian: So don't replace, but allow to augment with a hash? Did you think the Berlin group needed to modify their proposal so that SPC might be used with theirs?
JeanLuc: For JWS maybe
JeanLuc: But with XMLSig they are able to do it.
<rbyers> Ian: will you be on the call monday to carry forward your thinking?.
Rolf: How would the client platform verify it was shown to the user?
<rbyers> Ian: can't see SPC adding full content, and hash isn't useful without full content. But maybe worth discussing if we can add a hash to spc?
JeanLuc: Could the challenge provided to SPC be a hash?
Rolf: Yes, it's up to the RP. But if you want to convey "what the user has seen" that's different.
<rbyers> Ian: I don't see the challenge. Today challenge is used to avoide replay attacks. The fact that it might have meaning separately is nobody's business but RP. But if RP used challenge derived from data displayed (plus random number etc.) then they could make that cacluation without affecting anybody
Rolf: There might be additional value; we'd need to understand what it is. You might want to factor in the hash into the challenge (rather than replace the challenge)
rbyers: Agree that the key value of SPC here is trusting the browser that the user saw something. I can imagine an argument that the browser should include a hash of what the user saw, along with the signature.
… I could imagine a simpler version of the BG proposal. You can (kind of) imagine the browser doing a screen shot and making available both to the RP and a hash of it available as well.
Hybrid meeting?
Any conflicts in March?
Steve: No MAG meetings; there is an EMVCo one
<SameerT> don't see any FIDO meetings in March as of now