Meeting minutes
Web Authentication / WPWG joint meeting
<AdrianHB_> ian: SPC is built on WebAuthn
<AdrianHB_> ... there have been discussions at Google about the relationship btw the two and some have surfaced into the WebAuthn WG
<AdrianHB_> ... let's start by hearing the "Where are you going" from WebAuthn
<AdrianHB_> tony: [Pinky voice] TAKE OVER THE WORLD!
Tony: We are currently revising the WebAuthN WG charter
… once our charter has been officially approved we will begin to work on next things.
What we are thinking about for WebAuthn Level 3:
a) Delegation. You want to use WebAuthn in a "lights out" situation where you want to log into a computer, on behalf of someone else.
… we don't know what solution there is yet.
b) Non Modal UI
c) Reautthentication from the discretion of the RP
… how does the RP signal a desire for re-authentication
d) Recovery
… how do I do backups / recovery?
… there have been some discussions
… some things in crypto we might be able to use
… e.g., storage of private keys or syncing of keys across boundaries
Tony: We expect to run another year or so. I have not heard rumblings that we would go beyond level 3
John_Fontana: Last week there was vigorous discussion about key sync
… in the FIDO Alliance
<Zakim> AdrianHB_, you wanted to understand "non-modal UI". Does that mean the UI presented by the browser? What is the use case/requirement?
AdrianHB: What does non-Modal UI mean?
… what's different?
Tony: There are some situations where usability is an issue.
… non-modal UI comes into play there.
… I think Google introduced this topic
John_Bradley: A problem that RP's have is not knowing whether the user has a credential. This integrates discoverable credentials into a password-manager type flow.
… the RP fires off a Promise in JavaScript. The UI waits for the user to click on the username dialog box where the browser would get a list of discoverable credentials and would present them along with any stored passwords (for example). At the bottom of the dialog box there could also be UX to enable the user to use another authenticator (e.g., roaming)
… the user would select an option and the results returned to the RP
… so the RP does not find itself in a situation where there is UX without any WebAuthn credentials being available.
… this mechanism might be of interest to SPC.
There are technical considerations that would need to be worked through depending on the platform (whether browser is separate from authenticator)
… making sure only appropriate applications get list of payment credentials would need to be "seriously looked at"
… but at a high level it does sound like what you want
AdrianHB: Could you filter the results (e.g., if the RP wants the user to pick from a particular subset)?
John: No. Only filtering is by RP ID
… in principle you could filter on user ID or other piece of metadata.
… we'd have to address the question of how to indicate whether a credential is useable cross-site, is used for payments, etc.
… when we figure out how / whether to store the info, the next question is how to filter on the information
smcgruer_[EST]: There are two reasons why SPC needs changes in WebAuthn in the near term:
a) The first is the bit in the credential to know it is related to Payments and can be used in a cross-origin ceremony. We need that to prevent usage of credentials not so enabled.
b) Ability to ask the authenticator for a list of credentials. The transaction dialog is only usefully shown if there are credentials.
Tony: You are looking basically to attach metadata on credential usage
smcgruer_[EST]: Yes. We discussed in WebAuthn a bit on this
<Zakim> rouslan, you wanted to mention that the key idea is not "the website does not know which cred was selected", but "the website does not know whether or not the user has an enrolled credential, until the user selects one of the credentials."
rouslan: I think the privacy we are talking about comes from the site not knowing they have an enrolled credential until the user has selected one in a modal UI.
AdrianHB: yes, that's what I meant. In Payment Request we are asking the user "how do you want to pay"? Then with SPC, we find credential IDs for that payment method. I was hoping we could combine them but maybe we cannot.
AdrianHB: Can we leverage new features of WebAuthn to in some sense replace what we are doing with PR API...but we've not solved instrument stuff yet.
Gerhard: Here's a use case: A RP may wish to enable the FIDO token for payments, but might not want it to be used cross-domain.
... I can see some issuers saying "I want to use transaction confirmation UX, but don't want this credential to be used by other parties than me"
<AdrianHB_> +1 - it's tempting to try and solve both problems with one bit but they are different
Action: Gerhard to raise issue on distinguishing Payment type from cross-origin support in SPC repo
Tony: I wonder whether that is too much policy that is dealt with by the browser.
Gerhard: I may be wrong, but I think some issuers may wish to restrict users. I think we should explore this.
Tony: I get worried about management
Gerhard: Understood.
John: I agree that if we are opening can of worms to give back attribute we need to look at the granularity. I agree that "can be used for payment" and "can be used cross-origin" are distinct.
Gerhard: We also wonder about "can do payment and "can do login"
Rolf: The RP can already figure out whether the credential was exercised cross-origin.
… the question is whether one can TRIGGER the operation cross-origin.
<Gerhard> That might be too late to allow the customer to perform the challenge but then the issuer may decline it, and the customer performed an invalid action (bad UX)
Rouslan: Is the non-modal UI used in a "hanging Promise" scenario?
… related to conditional UI?
John_Bradley: Yes, I believe that is the current proposal.
JeffH: Even if not the formal term (if any) "hanging Promise" good enough for now
Sameer: +1 to Gerhard's use case for limiting cross-origin use of payment credentials
… in terms of discoverable credentials, today in 3DS, issuers try to get data from users.
smcgruer_[EST]: I think Sameer said "You'd prefer that the credential cannot be used across browsers?"
Sameer: I think that the requirement is "Credential tied to device" and when the user changes devices, it's seen as a new device.
Stephen: You mean "browser on a new device"
Sameer: Yes. We'd also consider "different browser on same device" to be a "different device"
Stephen: WebAuthn ties two browsers together. SPC does not yet.
… is that useful for you to have the two browsers tied ?
Sameer: That data might not be sufficient.
JeffH: Has the device-bound public key extension been discussed yet? Google is proposing in WebAuthn that authenticators will generate on demand a guaranteed device-bound key pair
...and the public key is shared with the RP consistently to give a strong signal to the RP
… the way it would work: the RP would request this extension on all registrations and authentications and would be able to see if there's a new device at the user's end.
Gerhard: Is user gesture required?
JeffH: This is an extension which would just be submitted as part of auth/reg operations; the usual caveats would apply.
… if a response successfully returns to the RP, there will be a key and a signature included, and if the device is different or a different authenticator was used, the signature and key will be different.
… there's a pull request on this already for Level 3 (as an EXTENSION)
… it's up to the RP to utilize this
… highly security conscious RPs may wish to utilize this.
John_Bradley: The default credential is bound to the "user". You need to include the extension to get the device-bound credential.
… I expect for payments RPs will want both signals: "same person" and "same person on same device" or "same person on different devices"
JeffH: It's not appropriate for every RP, and, by design, requires work to parse and understand the data.
AdrianHB: When we talk about "same device" do you mean "authenticator" or something else?
Jeffh: Short answer is "it's mapped to the authenticator". It's most appropriate for platform authenticators. But there's nothing in the protocol design that would restrict roaming authenticators from implementing it.
… but those roaming authenticators may have constraints that make it infeasible for them to implement.
John_Bradley: Imagine remote authenticators WERE capable of doing this (and, e.g., if caBLE comes into existence), a person could be on a Mac laptop but the authenticator might be on an Android phone.
… the authenticator credential would be the same as it is when they authenticate on their phone.
AdrianHB: What does this feature give you that you don't already get today with Web Authentication?
JeffH: We are imagining that user credentials can be synched by platform providers in the future (and are thus not hardware bound)
… this extension gives a more hardware bound continuity signal
Gerhard: In 3DS, in step one data is passed to the ACS which then decides whether to challenge explicitly.
AdrianHB: I am hearing a question about the use of WebAuthn for risk assessment
Gerhard: I am still interested in the use of FIDO but with less user presence check
Ian: What is the status of caBLE?
Jeffh: caBLE v2 for 3p is pushed out into one of the channels.
… that can be experimented with.
… status is "Google experiment"
Jeffh: we would hope that down the road other platforms would take advantage of this such that it could even work cross-platform
Tony: There is an issue open
AdrianHB: Can you stay what the status in WebAuthn is of allowing an RP to mark a credential as usable cross-origin (in an SPC sense)?
smcgruer_[EST]: We don't yet have a clear path forward. We did have a conversation with the WebAuthn WG and that led to an issue about cross-origin authentication.
… it's not clear to me yet on how to make SPC properly integrated cross browser
AdrianHB: Could you summarize the ask?
… e.g., "We'd like to be able to mark a credential as usable cross-origin"?
smcgruer_[EST]: That captures it.
AdrianHB: The goal is to let the user register a credential and allow non-RP origins to initiate the auth ceremony for payments
Ian: Should we reactive the joint task force (e.g., put SPC TF on hold)? Or just go to GitHub?
JeffH: Opening issues as needed on WebAuthn GitHub is just fine.
ACTION: Stephen to open N issues (as appropriate) on WebAuthn GitHub about which features from SPC would be "best part of WebAuthn"
User Recognition Use Cases
[Sameer Tare presents]
Sameer: there are two parts to my presentation today (1) refresher and (2) some ideas
...When we say "frictionless" we mean "no challenge to the user"
[Review of data that is used as part of frictionless flow part of 3DS: Browser/Device Data, User Data, Transaction Data]
Sameer: In a common card payment flow, the user pushes the pay button and there is no challenge if the risk assessment is satisfied, and payment is authorized in the background.
... Browser data is vital for issuer's Transaction Risk Assessment. Issuers collect different data via different methods. Risk assessment methods vary widely.
… so there's no way to say "this particular data element in the browser suffices"
… issuers rely on a combination of existing identifiers for device identification, even though some of these identifiers may not have been created for that purpose.
… increased privacy controls can inadvertently affect browser data for risk assessment which can lead to more user challenges (read: more friction and higher risk of cart abandonment)
… using cookies is not a viable approach (3p cookies being removed)
… there is lack (today) of hardware based identifiers
Rouslan: Could you state in one sentence what is the guarantee that you'd like to get during a transaction?
… e.g., I want to know that I have seen this device
… or I want to know that I have seen this user
… or I have seen this card with this device
… or I have seen this user using this card on this device
Sameer: I think "I have seen this device"
… we get some other data about card and user in the transaction data.
… what we are interested in is "this is exactly the same device we've seen before"
Rouslan: What is the purpose of knowing you have seen the device?
<Gerhard> Suggestion: I have seen this user on this device for this payment instrument, and they have consented to be identified with this device to make their payment checkout experience better.
Sameer: Goal is to reduce total number of challenges; want to know whether this device has been seen before
Rouslan: Is the concern with the new device "this could be stolen card"?
Sameer: Ultimately yes.
… each issuer has secret sauce, but device change is an important element typically.
Rouslan: If it's the same device but different card or user, do you care?
Sameer: Yes, but that's part of the overall data that's provided to the issuer
Rouslan: If a user says I don't want to share my identity and I'm ok with step-up, is that ok?
Sameer: Yes, we want to talk about that today
Rouslan: In apps like Google Pay or Apple Pay there is a device-specific card number. That gives you a guarantee about the device (where the bank has approved usage of the card) but doesn't share the identity of the device beforehand.
… is this slightly weaker guarantee for your use case?
[Ian missed reply]
Rouslan: If there is a step in the browser to say something like "Enroll this card on this device" that will tell the issuer that this card bound to this device in some way, but without necessarily sharing any more detail, would that suffice in follow-up transactions that "this card is enrolled on this device"
Sameer: Potentially, yes.
Weiler: Why don't cookies suffice?
Sameer: They sort of do, but 3p are going away.
… in real world checkouts, parties act in 3p contexts
… and some iframes may be sandboxed
Weiler: For knowing "same device" is it sufficient to know "this is the same FIDO authenticator token"?
Sameer: It falls into middle area between 'user' and 'device'. If identifier is same, then it could work
Weiler: I heard you say you want to build a capability for a particular purpose. It's hard to build a capability and at the same time stop it being used for nefarious purposes. I want to know how the "for payments" part will happen
Sameer: I agree with you.
...the idea is to understand a payments context
… we do something similar where merchant sets "allow" attributes on iframe
<nick_s> +1, I would like to see the proposal and then will probably have some questions
Gerhard: Some additional context - first, people are doing this to make a decision whether to
(1) outright decline a transaction
(2) Outright approve a transaction
(3) Choose how to challenge
… browser data collection serves three purposes:
1) New device or bad device
2) Tampering
… "not a real users"
3) Recurring good users
… I think we'd like to solve for "recurring good users"
Gerhard: I think the problem statement is "I have seen this user on this device with this instrument, and they've consented to be identified with this device to make this payment experience better."
… and make sure it's happening now. (Avoid replay attacks)
AdrianHB: A lot of this happens before there's any interaction with a hardware authenticator.
Sameer displays content that is also in the 3DS requirements repo
Sameer: If a hardware-backed authentication has taken place, this is a good way to establish 'good user'
[Sameer moves on to a proposal]
Sameer: In native platforms, there is more structured device data available
… today on browsers, device data is collected via (1) 3DS Method ... URL from the issuer/ACS (2) Authentication Request (AReq)
… we gather device data in a way that does not interrupt user flow
… summarizing the need: "find a way to identify a browser in a unique, privacy aligned manner to be used exclusively for Transaction Risk Assessment in a payment context."
… we don't want to create a super identifier
Nick_S: I think that the challenge here is that other use cases will come up outside of payments
… there are fraud prevention use cases outside of payments
… so that's a challenge
… also, on iOS we don't allow persistent hardware IDs across apps
… so there is not an analogous system in iOS and modern Android versions
… I want to dig into the central assumption that the issuer is the central point
… we strive beyond regulatory requirements for privacy
… I wonder if our ways of coming to the platform is that the browser/platform is performing this for you.
… where the credential is device-bound, you have your identifier
… this need is only for cases where instruments are not device-bound
… there's more dive into but I think it may be difficult to do a "payment specific play" here.
Sameer: We are focused on payments context and don't want to make problem harder by addressing even more use cases.
… there was a question of cross-app recognition. In 3DS on native, there is an embedded SDK in apps; that SDK cannot reach beyond the parent app
Jonathan: Regarding Apple and device token, since it is tied to the device if you send "123455" to the issuer, how different is that from what you are trying to achieve?
Nick: I imagine for payment methods like Apple Pay this is not required.
Jonathan: It is still something that is being shared
AdrianHB: I think that the solution is not a device id, but rather a device-specific version of the instrument
Jonathan: It's a binding to a specific device.
AdrianHB: Rather than the browser sharing a device ID, it shares a binding that is unique to the instrument.
… the user would have to explicitly select the instrument before the ID is shared with the browser
… that's the case in the Apple Pay flow
<Zakim> ChrisD_, you wanted to ask whether a unique browser ID is necessary? As you're using this in a risk-based assessment wouldn't a generic ID work - say all browsers mapped to one of 1000 IDs.
ChrisD: I wanted to quickly challenge the requirement for a unique browser ID
… given that we're in the business of doing risk-based authentication, wouldn't it be acceptable for a browser to have a "family ID"
<nick_s> (have to step AFK for a minute, will be back)
ChrisD: many people could have a browser with a family ID
… e.g., 1000s
… and that family ID could be provided to risk engine
Sameer: We still need to know "this browser has used THIS DEVICE" before
...This may not help the issuer sufficiently.
ChrisD: Just to clarify I mean there's a GUID for, say, 1000 instances of the browser
… yes, a fraudster could get lucky and use your instrument on a browser with that GUID, but the odds go down (e.g., 1/10,000 families)
Sameer: It would say "Same instance of a browser" so that would be useful
wseltzer: I think that you're hearing from several people the concern with the browser or device identifier
… I'd encourage thinking in the direction of abstracting the use case one level
… to describe the derisking were done if a device identifier is not available
… we are seeing greater privacy concerns across W3C with persistent identifiers and sharing them across contexts
Sameer: I think that we want to align with that privacy roadmap
… we don't want to create a tracking identifier
… at the same time we don't want a lot of user friction
… e.g., user involved every few transactions
… or every several days
smcgruer_[EST]: Going back to the native app use case. You mentioned that there an app embeds a 3DS SDK.
… is the identifier that you get specific to the app?
Sameer: there are both platform specific identifiers and the 3DS SDk app id
smcgruer_[EST]: 3DS risk assessment is tied to a merchant in iOS, then now
AdrianHB: I think that as a WG we really need to take a step back and try to find a solution. I appreciate that payments folks are coming to the table with requirements and problem statements
… so thank you
… let's focus on problem solving for the web here
<Zakim> rouslan, you wanted to ask whether we have any estimates of drop off rates and volumes without browser identity to understand the impact of this issue.
rouslan: A couple of questions:
1) If we share "true" or "false" like "Has this card been used on this device previously?"
Sameer: That assumes selection of storage in the browser.
<weiler> [ could trust tokens provide that answer? ]
2) Do we have an estimate of drop off rates or volumes of transactions or anything
… when you don't know browser identity?
… I'd like to understand the scope of the problem.
Sameer: EMVCo doesn't have those numbers. A lot of risk assessments are based on proprietary models
Gerhard: We could look at challenges not being completed.
… I have some data...
… there are billions of dollars in transactions that fail because browser is unknown, or user doesn't have phone, etc.
… it's a serious issue
PROPOSED: Prioritize the user recognition use cases in the WG's agenda
<smcgruer_[EST]> +1
<Anne> +1
<jonathan> +1
<Gerhard> +1 for more around 'reducing friction', and framing the problem.
<Manish> +1
<ChrisD_> +1
<AdrianHB_> +1 -(think we should phrase as user and device recognition)