Meeting minutes
BBK features
stephen_mcgruer: This is an overview of BBK features we've discussed as part of the SCP MVP
stephen_mcgruer: One question I have - there might be a "double confirm" situation even if "discouraged" is honored. The authenticator may require user presence via a confirm button. We might be able to avoid that in some cases.
Henna: A big reason this came up is confidence that GPM will honor this; so we need to hear more from them before committing to these features.
… this is an easy fix to a big part if GPM can honor this.
JohnBradley: uv=discouraged will more or less be honored, but it will depend on the authenticator
… the double confirm will be harder to get rid of
… some people may be nervous that will allow attacks
… not having any user dialog could be difficult to work around
Henna: Double confirm is new information. Let's find out if GPM can be smart to not do a second confirm
stephen_mcgruer: It's more likely we can make this work on Android (in part due to limitations on what can be considered a browser)
Ian: Any way to provide input to the authenticator confirm dialog?
Henna: At TPAC I thought we also talked about using GPM on Windows
stephen_mcgruer: We could switch to GPM with Chrome on all platforms but it would have downsides (and be sad from an open web ecosystem perspective)
Henna: Is there a way on windows through GPM or another means to get similar behavior
John: Yes, but only using GPM.
… or better integrate SPC into WebAuthn
… using the credential manager on android, if that passed through transaction information as part of what gets into user data
Ian: Would there be appetite for that?
John: Might be interesting to discuss with platforms.
stephen_mcgruer: This should already be possible via our extension
… the authentication time extension includes all the payment data.
John: WebAuthn WG rechartering discussion has started (yesterday)
… a better architecture would be to push this into credential manager and authenticator. I don't think people would be against this.
… the credential manager APIs are proprietary
(Tradeoffs include os- or authenticator-dependent display of transaction data)
Ian: Recall EMVCo emphasis on importance of consistent UX
ACTION: Stephen to talk to GPM folks about uv=discouraged and double-confirm situation
Ian: Does it make sense for browser to pick first credential ID that has a matching BBK?
stephen_mcgruer: That makes sense. But in practice we pass single credential at a time (to avoid selector). So we will have to do a different prioritization.
… we should probably spec this out: pick the first one that matches some criteria
BBK Feature detection proposal
w3c/
Darwin: The proposal is to have a new method on Payment Request that returns a map of capabilities.
… so you'd make a static request first, and track the results. If BBKs are available in the map you make your decision
… we picked map in case we introduce new features like BBK-through-software
… this lets us add to the enum
… see other ideas for approaches but those are less appealing.
See also privacy considerations discussion in the proposal
Ian: This is backwards compatible?
Darwin: Yes
Ian: I'd like to connect this to the conversation we just had about using uv=discourated. Would it make sense if one of the values that might appear in the map indicated "uv=discouraged is likely to be honored here"? That way a caller might have some idea of what the UX will be, and could decide to authenticate some other way.
stephen_mcgruer: You probably can know whether uv=discouraged will be honored just by looking at the OS.
John: Maybe, but you might also have multiple authenticators on a given OS.
… question is the more esoteric: "Do I believe that the authenticator would honor discouraged?"
… I think it is unlikely that browser would know the answer
Tighter integration of SPC into WebAuthn
At this point in the meeting, the WG began to contemplate the tradeoffs if SPC were embedded more deeply into Web Authentication. For example, what if the operating system authentication dialog were to include the transaction data? On the one hand, that might reduce some UX friction. On the other, it would likely make the transaction dialog UX must less consistent across platforms, and we know from EMVCo research that consistency in the UX is an important factor in user trust.
Payment Handler
Ian: We are planning to rename the payment handler specification to be "Web-based Payment Handler API"
(No comments)
Roaming authenticator requirements for SPC
Bjorn: We are looking at roaming authenticators with SPC. Where would you like input to be captured?
Ian: Let's at least attach the input to issue 12.
John: I agree that a pull request on the spec only covers a portion of the broader topic.
Ian: Let's start with requirements (either input directly into issue 12 or linked from there).
Next meeting
26 February