Meeting minutes
Nearby: 24 September WPWG minutes
Housekeeping
NickTR: Welcome to Anaheim, land of the mouse
Fraud Trends
Gerhard Oosthuizen slides on fraud trends
gerhard: We'll start with discussion of fraud trends and what we might do to enhance the web to help
Gerhard: One observation from UK fraud stats that's of note is growth of fraud from authorized push payments.
… 48B USD in fraud worldwide in 2023
… up from 41B USD
Gerhard: Americans lost 5.6B USD to crypto-related fraud in 2023 (according to FBI)
… the phenomenon is global.
Gerhard: Can we detect links coming from SMS's? Phone numbers?
Maxime: Do you observe a correlation, in practice, between Large-scale data breaches and Identity theft fraud?
Gerhard: Credential stuffing is a large attack.
… if there's a breach, the info is often used for social engineering
… there's a lot of work being done in that space
Tony: Is there any data on authenticated fraud v. non-authenticated fraud, and any data on wallet fraud?
Gerhard: There's obviously lots of data on authorized push-payment fraud. We are starting to gather data on phishing fraud
… where I'm e.g., getting you to provide an OTP to me
<Sid> Wallet fraud would be a sub-set of Account take over fraud?
Gerhard: e.g., 'attackers are coming from your account, hope we can catch it in time...send me OTP"
… the specific fraud between authenticated/unauthenticated, there are studies out there. Another issue in the other direction is false positives, and so there are places where they authenticate all the time (and there is more abandonment, which makes merchants unhappy)
Gerhard: I think with *Pay there is often fraud at enrollment time.
[Slide on the Fraud Classifier from the US Federal Reserve]
<Sid> Example would be some one taking over a SDW (staged digital wallet) and using instant payments (Visa OCT, MA Send) to move money from the wallet to a newly added instrument (authentication during Add Card would assist in reducing such frauds)
[Gerhard talks about discussion of phishing proof authentication and WebAuthn]
Gerhard: For vishing, FIDO can help on the primary channel
Gerhard: Today we are in the realm of authorized push payment fraud.
… question is how to detect that someone is being manipulated, or that a link is suspicious, or that a site is risky
[Gerhard lists a set of fraud scenarios where the browser could help]
Gerhard: Apple made some changes to prevent some types of attacks from happening.
[Summary: Areas to possibly explore]
Gerhard: Integrity checks would be interesting (as is available in native libraries)
… information about when user created account would be useful
… information about whether security settings have been changed
Gerhard: Geolocation helpful as well
… regional information valuable.
<Zakim> rouslan, you wanted to ask about possible privacy explaining UX for these signals.
rouslan: Interesting signals. Users will likely want to have a good understanding and control information that's shared.
… any ideas about UX for consent or informing the user?
Gerhard: We are learning about UX from native apps.
… if we use mobile apps as a precedent, you don't need to check whether OS integrity is there.
… if the bad guy can say no to the signal, then you are still stuck.
… I would try to get to a state where personally identifying information (PII) is not leaked. Signals valuable nonetheless "I can tell you this OS has been around for more than 3 months"
… that sort of thing
<Zakim> rbyers, you wanted to ask about usefulness of an aggregate risk score from the browser
rbyers: We can divide this into some buckets. E.g., case where someone stole a device. We tried Web Environment integrity but there was backlash.
… is there enough interest in cases where we can trust the device? Then there are two choices: (1) a whole bunch of signals, e.g., SPC might send back more signals, or (2) if you trust the device, maybe the browser can come up with the risk score.
Gerhard: Risk scores could be interesting "Does this look like regular behavior?"
… there have been studies showing user will choose convenience as long as they are not getting themselves into trouble.
rbyers: If most of our progress was where attacker doesn't control device, would that be progress?
Gerhard: I don't have exact stats. We are starting some work to collect relevant info. We are definitely seeing a trend to more manipulation (where someone is duped).
… but the largest set is still pretty old school like reusing stolen card details and stealing OTPs
nick_S: I would not want to see users who require accommodations to be subject to additional gatekeeping.
… e.g., many users modify DOMs/JS for accessibility reasons. I would not want to put them through higher levels of fraud checks.
… as OS vendors, we make different choices about what to reveal to apps. We don't want users to be targeted because they have made certain choices (e.g., simple passcodes)
nick_S: I think you're right that OTP is a major fraud vector. That's a deficiency of the payment method.
… I don't want to lose site of the fact that there are other payment methods that don't require OTP that are inherently more secure.
… the payment methods need to seek improvements.
Gerhard: We don't want to know what setting was used e.g., related to accessibility, but simply that a setting may have changed.
… user liability is an issue.
benoit: Can you comment on how to verify that information is coming from a trusted source?
Gerhard: I have seen two things of interest (1) backend service call (2) browser signed challenge (e.g., DBSC) sent back to server
Regulatory trends
Jean-Luc: Working with Grégoire Leleux (Worldline) to survey regulations related to payments and to have a global overview
… this presentation is an extract of a more detailed study we are doing.
… topic 1: Dynamic linking
Jean-Luc: topic 2: Verifier reliability
rouslan: From a regulatory perspective, when we talk about 2FA and one factor is possession, does possession of private key count when the key has been synced?
… topic 3: Authentication factor information
Jean-Luc: Having private key no longer remaining on the device is no longer a possession factor according to NIST
… so synched passkeys don't satisfy the regulatory requirement.
… there are strong desires to use a different possession factor
… there are emerging trends to replace the private key with something else.
… it's also valuable to know whether it was the same user
<rouslan> Referred in slides: https://
Jean-Luc: topic 4: Device binding
Jean-Luc: In many regulations device binding is either required or strongly recommended. It provides a possession factor.
… the second reason why strongly recommended is for fraud mitigation.
… this can improve frictionless in 3DS flows, for example.
… in US, Japan, UK, really valuable for risk mitigation
… and relates to liability in case of fraud
steele: Cf. DBSC
Tony: is it really binding to the identity or to the authentication that happened?
Jean-Luc: What we observe so far is that there's a difference between dynamic linking (transaction info) and the device binding (device - user binding)
… depending on regulation, the way to deal with the privacy may be different
… topic 5: Data privacy
Jean-Luc: There is a notion of "consent" across the global regulations
Jean-Luc: We cannot user personal data without user consent. Those data also need to be secured all along the connection
Gerhard: one thing we've talked about is "secure display"
… is there anything about "secure display" in regulations?
Jean-Luc: I think it's part of dynamic linking
… some regulations are more specific than others about this topic...e.g., requiring user is able to understand what data is shared and with what party
nicktr: We heard from Gerhard about APP fraud
… we now have "confirmation of payee" in UK and it's being discussed in PSD3 context
… is there more we can do as web community to bake confirmation of payee into dynamic linking?
Jean-Luc: Definitely.
… we observe many emerging regulation (whether PSD3 or other)
… in our study we provide also some mitigation strategies for these risks
… we can look more about web protocols to help
… I look forward to sharing more about this on Thursday
Visa SPC experience
Doug Fisher slides on SPC pilot
Doug: We see SPC as providing enhanced FIDO user experience compared to standard WebAuthn.
… benefits for merchants, consumers, and issuers
Doug: We implemented 2 pilots into production since last TPAC meeting.
… good news: SPC works!
… and it works with 3DS.
Doug: This is not the only use case for SPC, but our focus is payment use case with 3DS.
… we are looking for any barriers to the scalability of SPC. We did one pilot based on 3DS 2.3.1.1
… and a second pilot using an extension with 3DS 2.2
… we wanted to check whether we could use SPC sooner in 3DS 2.2.
(Nakjo gives a quick introduction of how this works)
(We see a video showing SPC enrollment after ID&V)
<Zakim> rouslan, you wanted to ask about the passkey creation UI
<maximeg> can we get access to the minutes if we're not wpwg members? currently getting a 403
Tony: Do you care about synched passkeys or do you create a new one each time?
Ian: We want to use passkeys; need more info
Gerhard: We also don't know whether passkeys have been synched. The challenge is "trying and failing"
… if we had more info about whether there's a key, that would help
Tony: You can tell whether a passkey is synched or not (see Credential Backup State).
Tim Cappalli: You are told that its syncable upon creation.
… whether it is synched or not in the future is not important from a security perspective.
<Zakim> smcgruer_[EST], you wanted to note that whether its synced or not re SPC depends on the platform
smcgruer_[EST]: Even for SPC it's very platform dependent where the credential ends up, whether it's synched or not, etc.
… I would not advocate for people to depend on current Chrome behavior on Mac.
Nakjo: We look at new device use case...user knows there is a passkey related to the number. We don't store cookie, so we get the fallback UX
Nakjo: We also cover the case where user cancels during SPC authentication, and since we don't know that passkey is available we prompt user to re-register.
Doug: Here's some feedback from the pilot:
a) 2.2 with extension is feasible, and the implementation effort is relatively straightforward.
… starting with 2.2 and migrating to 2.3.1.1 is also smooth.
Doug: We are planning to provide the extension to EMVCo; and if 3DS WG agrees, it would be generally available
b) Feedback from issuers and pilot participants is that we need more OS and browser support for SPC in order to get the consistency of experience users expect. That's critical for us for getting scale.
Doug: When a cardholder has a problem, we have no information what happened and how to debug it.
… our logs from the pilots don't tell us why. So that's challenging.
smcgruer_[EST]: Android fix has landed and will be available to everyone mid-October.
… I'll also ack the concern about how to debug this.
… did general WebAuthen debugging land?
Adam: The things in question wouldn't be useful here.
Doug: 3p payment bit is still fixed in the browser. Suggest developing consensus on how it should be stored.
Tim: You want to store it with the passkey right?
Adam: Even if synchedD?
Doug: yes with the authenticator. If the passkey is synched, it would be interesting to sync the 3p payment bit as well.
Tony: Do you care about conformance or certification of passkeys?
Doug: We hope we will discuss attestion this week.
Tony: What are your requirements regarding libraries?
… do they need to be conformance tested or certified?
Nakjo: For this pilot we are relying on platform authenticators and they are "good enough" at this point.
Tim: Do you want 3p bit to be synched via WebAuthn?
Tim: SPC 3p bit part of PKCS for tomorrow discussion.
Doug: We got favorable feedback from users on the UX
… we have some feedback on dialog options
… the Chrome team has provided a prototype ability to let us do A/B testing
Doug: We ran three UX's (A, B, C).
… B was preferred by people with experience.
… and those familiar with 3DS UX
Doug: Some feedback was on how SPC and 3DS work together, not just on SPC itself.
Tony: What's your timeline?
Doug: We're not done with testing. One thing we are very interested in about invoking SPC without a WebAuthn credential.
… and SPC could be used as a transaction confirmation dialog
… and we could see that helping a transition from people without credentials to people with credentials.
KennethDiaz: Our experience is that we had to do a bit of communicating on the server side to get support SPC. We had to make some validation changes to support SPC.
… for issuer adoption, it would be nice if any issuers would not have to do those things.
Mastercard experience with SPC
Jonathan: There are two elements we are thinking about to increase security of online compared to in-person: tokenization and authentication
… biometric has been a focus to give security plus a seamless experience.
<nicktr> Here is the link to the latest policy
Jonathan: Passkeys are created after some ID&V
… how can passkeys be used for payments? For SPC there are two main use cases that we've mostly discussed: integration into 3DS and other protocols
Tony: Is device binding concern at creation time or use?
Jonathan: At creation time. You could create the binding at creation time or later.
… it might happen at the same time as creation or it might happen later.
Tim: I am concerned about giving this thing a new name for passkeys. (This is a branding concern.)
Jonathan: Unfortunately until we solve passkeys for payments we need a differentiator
[Jonathan shows demo where passkey is used during checkout]
Adam: What domain is the cookie?
Jonathan: Mastercard. We need to be in a 1p context.
Gerhard: This is using SRC?
Jonathan: This is not using 3DS.
<rouslan> me thx @ian
rouslan: Is cookie clearing after 7 days problematic?
<Zakim> rouslan, you wanted to ask whether cookie clearing after 7 days by some user agents will be problematic
Jonathan: This is clearly not the preferred way for device binding. But in this case it's 1p cookie. Clearly we'd like other solutions for device binding
nick_S: is your intention that this be used with card on file, or is it just an example?
Jonathan: Just an example.
… the passkey RP is with the bank, or the network.
nick_s: Isn't the attraction of card-on-file that you don't have to go through this process?
Jonathan: Merchants don't generate their tokens, they get tokens.
… it's easier to get credential when stored on file compared to typing in card details.
Manjush: In the verification payload I saw a new domain open
Jonathan: We need a 1p context to read a cookie.
Jonathan: Observations from this experience (1) complexity with pop-up blockers (2) focus continuity
… regarding UX, there are different experiences in settings that might happen
… so UX regarding passkey lifecycle management issues (when user deletes passkey)
Maxime: How does this compare to PR API?
Jonathan: How SPC can help...
… some benefits:
* Cross-origin authentication is very helpful, and not just in 3DS context
* Dynamic linking
… SPC makes that easier.
* Consistency of the UX
Jonathan: We did some usability testing with prototype from Chrome team
… trust is very important to people who are authenticating. The logos (that 3DS requires) has been perceived as very important for trust and security.
… other elements like store name, card name, number, total amount also very important.
… there were some questions about the "Verify" label on the button
… some participants were expecting the prompt for WebAuthn without having to click again.
… we did some prototyping
[Jonathan shows some live demos of registration]
Jonathan: We got feedback from our SPC prototype
… what's next?
… device binding, key attestation, info about authentication factors are all important for compliance with regulations
… that will be important to our SPC pilot
Adam: What does key attestation mean?
Adam: Which passkey provider. If you have device binding, why do you care?
Jonathan: Some uX topics - interop across browsers, no similar experience in native apps, some confusing UX on OS screens due to general focus on login, no understanding of device binding.
<rbyers> w3c/
(That's after lunch!)
Tim: WebAuth says explicitly there's no guarantee it's the same individual.
… knowing "same user" is out of scope for WebAuthn
Theodore: In a slide you mentioned IP address for additional signals for fraud mitigation.
… can you speak to the relative importance of webauthn as a signal v. other signals
Jonathan: There was no real relationship between the passkey and additional data. Feedback from banks is that they want to use additional signals.
… if you use already 2FA, but there is typically multi-layer security.
… banks would love to be able to trust data they are getting.
nick_S: Regarding data about things like configuration changes...it would be helpful to me if we could have more information about what data is going to be used for and why it's needed.
… I need to know why that's needed and also discussion of where users are disadvantaged.
<Gerhard> Happy to provide more context on the value of some of those signals.
nick_S: I am sympathetic for the need for device binding. But there's an assumption that users operate on discrete devices. But users moving forward will be interacting with multiple devices (e.g., interacting with your iPhone on your mac is a new feature)
… there may be other options than device binding for addressing needs.
Jonathan: I agree with your first point that we need more info about what banks are doing. One use case (in Italy) the regulator requires the banks to indicate what auth factor was used.
… for the second topic, the requirement has been going on for years and is well-understood by banks. It doesn't mean that you can't use multiple devices, only that you know whether you've seen a given device.
Jonathan: Dropping the passkey to someone else is out of scope from a payment perspective. You don't give your card to someone else for forever.
Jonathan: The UX for "login" is different than for payment, and that's a source of confusion.
Jonathan: There are also issues with 2 authentications back to back because you don't know whether there's a credential on the device.
Nick_Steele: We're looking into providing additional trust signals in FIDO alongside a passkey response.
… some information outside of device binding but rather around the "synchedness" of credentials.
Nick_Steele: We want to provide the data you need so that you don't need more factors, and the security posture of parties using info
… if you have a new device, one could have multiple devices you'd be able to get a signal about whether, if a user were to use a key on a new device you'd know it was synched.
Tim: These are discussions, no commitments yet.
Chrome updates around SPC
Rouslan: We are planning to update some of the UX based on industry feedback
1) Issuing bank icon
2) Payment network icon
3) Improved formatting for merchant name and origin
4) Choose between different names for payment instrument types
5) More fields and better formatting for the payment instrument field
6) Make user choice explicit
Fahad: origin may not be useful.
Rouslan: the extra information can be useful for backup
Rouslan: We are also updating the fallback UX
… we have to show some UX to hide from the site that the user does not have a credential.
… the UX prevents a timing attack
… the new dialog is a confirmation dialog.
Ian: Could signing data with browser-specific key be useful?
Rouslan: I think the guarantees would be weak
Gerhard: I think the approach would be that we would still use the key, and still challenge the user through some form of challenge.
(There's a MITM issue that would need to be addressed.)
Jonathan: It could be interesting to have "Confirm" with web authn signature without user verification
… that could be an alternative market.
Gus: Is there are a high risk path for credential not found?
… suppose I'm a merchant that only accepts verified payments, can I send someone back to payment selection instead of cancel?
Rouslan: In this UX we have "verify another way"
… any outcome from this UX means "there is no web authn result" and the merchant could then offer a different card. But I don't know what impact that would have on conversion.
<Zakim> smcgruer_[EST], you wanted to discuss some quick clarifications
smcgruer_[EST]: We won't give a signal "there is no credential".
<smcgruer_[EST]> smcgruer_[EST]: we will give signal of "either there was no credential OR the user didn't want to use them"
<smcgruer_[EST]> smcgruer_[EST]: I think you can use that signal for what you want?
Ian: whether the merchant can learn about authentication credentials associated with instruments depends on the payment method (or SPC / FIDO integration) for that method.
Question: in fallback UX, should "Confirm" return an error saying "user cannot user credential" or some sort of signature over the data?
<smcgruer_[EST]> See SPC error codes in proposal
Gus: If "confirm" gives merchant a signal "user wants to continue" that could be helpful.
… maybe "Confirm" is confusing
Rouslan: Perhaps "Continue"?
Gus: Maybe
Nsiskov: Any way to have no fallback UI?
Nsiskov: Instead of fallback, could browser wait for a random period of time and not show UX?
Rouslan: We'd have to block interactions with the web site during that time.
… from a user perspective it would look like the site is not being responsive.
nick_s: What's the interplay between SPC and Secure Payment Authentication (from Google Pay)?
Ian: We almost had a presentation on that topic at this meeting but it didn't come together. However you can what with Heng Liu in the hallways. I hope to secure a presentation at a future meeting.
Nick_S: Consistency of experience was also cited as a value. But they may not get a consistent experience.
Doug: I just wanted to thank you for the updated UI!
… I think this will be adopted more readily.
… I will be interested to see what SPC API changes are, and impact on 3DS
Doug: I think there's value to the fallback UX. "Try another way" needs to be potentially on both happy path and fallback UX
smcgruer_[EST]: Checking what Doug said: "Confirm" gives site a signal to continue to 3ds flow.
… are you saying you want two paths?
Doug: Good point. Maybe we'll mull that over.
Rouslan: The API will return 3 results codes instead of 2 in the new UX
[Device binding proposal]
Rouslan: We have some questions - are we re-inventing the wheel for DPK and SPK? Could that work be reused? Are we missing some edge cases already covered by WebAuthn?
Jonathan: WebAuthn no longer has DPK/SPK extensions. Where will key be stored?
Rouslan: In user profile.
Adam: It would probably still be hardware bound.
… the key is 'hardware' bound but stored in the profile.
Adam: If you are talking TPM, there's no external signal.
… that's distinct from secure element, which could have policies attached to credentials.
… you can credential that allows silent signing.
Gerhard: For me, being able to sign on this specific device and being able to know that this is a device I've seen the user use before is valuable.
… not being able to sync it, or preventing social engineering sounds like it will improve security.
nick_s: We would have concerns about allowing sites to do device bound signatures without interaction.
<Gerhard> I would be very supportive of an 'always confirm' with a button.
<Gerhard> Showing transaction information while doing this.
Ian: Would doing SPC constitute a user interaction?
Nick_S: Maybe, if the user is educated about what's happening, and sufficiently good language, etc.
smcgruer_[EST]: Yes, I was just going to say I agree with Nick_S in general. I think we can make SPC meet that UX requirement.
smcgruer_[EST]: As a 1p I can drop a cookie that's a device identifier. And DBSC is coming. I think there is a big space and where we will draw the line about a persistent identifier.
Adam: 50% of windows machines don't have a TPM. Would you be ok with not hardware-bound (and we'll tell you which one you got). Would you prefer "nothing" in this case?
Eric(Visa): You need a certificate. If you are signing something, the attacker can do as well. But the attacker may not have the ability to sign with a certificate.
Nick_s: If you clear your device, you're not going to get the (same) attestation.
Gus: The history of trusted use of the key is what's valuable.
(Discussion about using SPC as confirmation UX with less-than-WebAuthn security)
Gerhard: We are just trying to get incremental improvements.
Eric: Attacker doesn't have to be present all the time....
Gerhard: Trust is built up over time.
nick_s: It might be helpful to look at native apps.
… we have this problem today, where apps want certain guarantees to prevent fraud and abuse.
… what we allow in iOS is to attest and sign data. The attestation is only that the device has not been jailbroken.
… we allow apps to ONLY store 2 bits
… the use case we wanted to solve for was fraud. that's the min we could do without privacy risk.
IJ: What should SPC do?
Nick_S: The Web is a less restrained world. In addition to the attestation, we can indicate how many times the attestation has been reset.
Jonathan: The big difference is with apps you can get device bound keys.
Nick_S: There's a difference between "bound to a device" and "not-synched". So a key might change devices, but is not synched at any given time.
Ian: Design idea here is "more power due to dedicated UX"
Rouslan: Last topic here is shopOptOut, which we propose to remove from the API.
<smcgruer_[EST]> w3c/
Rouslan: We've not seen much usage. We'd like to remove it. If you still think it's important, let us know.
Rouslan: We'd like to continue to hear from you about these feature proposals.
Trust signal statements (by Nick Steele)
Nick Steele slides on Trust Signals
(Apologies to people who may have joined to be in the auto-fill session exactly at 3:30pm…we will start that session in just a few minutes.)
Nick: Scenario - platform provider statements
… we could generate a trust signal with a base statement, provider metadata, and platform metadata.
… new trust statement would be generated when passkey shared
… the statement would change when passkey changes hands.
… we could leverage FIDO MDS or have some authority
… we could have an authority model where the platform provides the key and signs with us, but when the platform is not available, the provider provides the key.
… there might be a use case that doesn't allow for non-native flow .
Nick_Steele: I hope we know more about future of this by end of year.
… we need to refine signals for high security RPs.
Improving address autofill
(Chris Indra from Shopify)
Chris: We updated the Autofill improvements proposal based on earlier conversations today. :)
… question is how to enhance autofill for the web
… autofill is an important part of UX on the Web, but there are challenges.
… for example, dynamic nature of address formats and forms makes it easy to break autofill
… we see some privacy risks as well
Chris: Depending on your country, the other form fields that are necessary may change.
Chris: Another situation we have is separate iframes with all fields. We use post messages to sync values across all frames.
Chris: Trigger is still a user interaction.
… this allows autofilling as conditional forms.
Vkuntz: Regulators seeking more and more structured addresses. In the future, unstructured may not be acceptable (for credit transfers)
Chris: I agree it should be structured.
Yoav: The full address is important for the user consent part. Under the hood, the data will still be structured.
… the user is consenting to have their whole address filled regardless of the state of the current form.
smcgruer_[EST]: As you know, Chrome is interested in this proposal.
… it would be more predictable for the web, a good thing.
… have you thought about the UX to make clear to the user that they are sharing the full address? Today we show a "preview" but hidden frames are a problem.
… have you thought about the UX for all data about to be shared?
Chris: In this version of the proposal we would still use the web form to show the data.
Chris: Users are not surprised when all the components of an address are shared. Users expect that.
… what should not happen is to try to fill other fields unrelated to address (e.g., address)
… the user should see explicitly that their email or phone are being shared.
smcgruer_[EST]: It's not clear to me that we should maintain the state of the web where hidden data is shared .
… we should fix that.
nick_s: I agree with Stephen. I don't think it's an improvement if it looks only like city is shared but a whole address is shared.
… other ideas: if would be nice if we could get a 2-way dialog going. Example - iOS doesn't have a concept of "states" in some places but Shopify does.
… if we are going to define a data structure, it should be done in alignment with the Contact Picker API.
Chris: So, for example, Shopify could tell browser "this address is not valid" and the browser could improve?
Nick_S: Yes. Browsers today say "You want to save this new info?"
<smcgruer_[EST]> +1 in general, we often end up with duplicate profiles or ping-ponging profiles because of how different sites represent the data on form submit
Yoav: It feels risky to have the site impact the autofill presentation.
Chris: You don't want a malicious site saying an address was invalid, and the browser changes what's stored and then it's a pain for the user.
Ilya: We need to figure out to not harvest data through hidden input fields.
… it would be great to be super surgical about what data to share, but the expectation of the user is that their (whole) address will be sent back.
… address should be treated as an atomic unit.
<Zakim> rouslan, you wanted to ask about best ways to experiment with potential user experience (UX) for this.
Rouslan: Thanks for bringing up these topics here. One topic of discussion is "how much of an address to share". Some people may recall that when PR API exposed shipping address, we received pushback from PING about oversharing..
… our compromise was that we redacted the address for shipping price computation.
… there are use cases where full address is not needed.
… the PING suggested a dialog between site and browser to start with country, for example, then the user could agree and then more could be shared after more dialog
… the user experience is really important, however.
… recall also that developing browser UX is slower than iterations in web pages to find good patterns.
… can we figure out how to experiment to arrive at a good UX.
(Some chatting about UX)
benoit_: +1 to a web standard for address filling
battre: I have an I18N comment. Perhaps the agreement we need to get is on address structure.
NickTR: my suspicion is that this is a hard problem, and that's why it's a mess
vkuntz: With regulators stepping in, it's important. We spent a year on this in ISO. We came up with a a structure that works for 99% or people; see PostalAddress27.
<smcgruer_[EST]> smcgruer_[EST]: 99% of beneficiaries != people
<benoit_> +1 smcgruer
<nicktr> There's WICG session on autofill improvements on Friday.
Digital Credentials and Payments
Tim: This is a session idea from a variety of conversations around payments
… including with other organizations.
… goal for today is to level-set
… we'll talk about use cases, existing technnologies
… ideas for architecture
Tim: Here "credentials" mostly means Verifiable Credentials (VC).
Lee Campbell: I look after identity and more for Android.
… first a bit of background on Digital Credentials APIs.
… foundational use case is to return a credential from a wallet.
… e.g., on a mobile device
… there is a "return" API being experimented with, and soon a "create" API
… the main credentials people are looking at right now are MDOCs (documents on a mobile device).
… interesting use cases: presentation
… out of EIDAS are question about how to use digital wallets and credentials for payments.
… one proposal coming out of the EU is that we could present digital credentials at SCA moments
… imagine a flow where user enters card number and there's a request for a digital credential version of the card.
some use cases: dynamic linking, checkout flows, account-to-account payments, multi doc presentation, native and interoperable payments on the web, phishing resistant cross-device presentation,
Lee: We do imagine having a native API for these credentials as well.
… support for transaction history
nicktr: Regarding single tap for payments and identity in physical world. That's in scope for this work?
Lee: To get multiple document use cases, goal is to have single authentication.
Lee: Once there is support in stores, we see there is a long-term opportunity for multiple doc presentation.
… once a reader can accept an identity doc, no reason to not be able to also accept payment credentials.
John_Bradley: From the EU commission's POV, they are more interested in PSD2 debit transactions in combination with other identity things, but in theory credit card could also be used.
Lee: We envision standards-based ability to use a variety of payment credentials
NickTR: A whole new set of terminals in stores would take time.
Lee: Right, if you are doing this for the web, a lot of the work can be used for other use cases.
NickTR: This would be aligned with "Wero" tap-to-pay account-to-account
Tim: What's become clear is that the terms used in ISO are over constraining
… one can do a remote presentation protocol in an in-person payment.
Lee: If you've gone to the effort to put a payment credential in a wallet, there should be an opportunity to use it in person.
… another benefit is the ability to see transaction history in a wallet
[Examples of SCA]
Lee: I think this would address some of the issues raised earlier today such as confusing language about "login"
… the mockup shows non-payment credentials alongside payment credentials, with clear messaging to the user.
[Regarding Issuance]
Lee: There might be multiple ways to get a credential into a wallet.
… e.g., banking apps could support creation and then they could act as wallets.
… you could a imagine a "save my boarding pass" at the end of a flight reservation flow and create a credential into the wallet
Gerhard: Regarding the mockup. In this case, as a site I am saying "You need to share your information with me." How do we know that there's integrity in the sharing and not just social engineering?
… are there ways to limit reuse?
… or provide proof about how a credential is used?
JohnBradley: We are coming at this from the perspective of European EID wallets.
… they have strong views about what information is released and to whom.
… in principle whoever issued the payment instrument would provide rules for the wallet to follow.
… so it's not entirely different from the sorts of rules for situations where you present passport information.
… this work isn't entirely contained in the credentials API; a lot is happening in OpenID for VP.
… some people think that any credential should be used to sign arbitrary information (though some might think that's a bad thing).
… should signing be attached to some credential types, so the wallet can have specific UX for what gets presented and transaction binding information
Gerhard: I'm hearing that the verifier and issuer would be synched up before a credential can be requested.
JohnB: I imagine it be much like existing acquirer certifications
… I think that's an advantage of moving to verifiable credentials model. There are enforcement points that don't exist in the case of WebAuthn
Lee: You can issue credentials with "create"; these credential formats will mostly provide for device binding.
… another feature: there can be lifecycle management for credentials, with some wallet/issuer dialogs
… they can be updated, for example or revoked.
… e.g., "over 18" changes on your birthday.
… you could do the same thing with payment credentials like updating the name on the card.
NickTR: Could a balance be a credential?
Lee: Yes.
… the issuer could update the balance in your wallet.
NickTR: The use case I have in mind is offline.
Gus: EMVCo has a full spec for offline chip and pin; quite used in Brazil.
… you could replicate the constraints in this world. EMVCo has covered the edge cases.
Nick_s: Practically speaking it doesn't always work like that.
JohnBradley: One thing you could do...if the wallet is sophisticated it could participate in tokenization.
… e.g., bank app acting as a wallet, tokenizes card and provides pseudonymous information to the merchant
Lee: Seamless inline issuance is an interesting use case.
… e.g., in the EU the user's PID (national ID) could be presented and exchanged for a digital payment credential during the SCA flow.
… we think this is seamless enough to do inline in the SCA moment,.
… imagine a flow where your card is not provisioned in the wallet. The wallet does have your national ID.
… you could present the national ID to the bank, and ask that it be exchanged for a payment credential at that moment.
… we believe that could be done inline with a transaction.
… the user could easily get a payment credential and be able to use it henceforth.
nick_s: A theme from this morning related to data for fraud mitigation. Are there mitigations for digital credentials to prevent asking for as much data as possible?
Lee: The EU is working on a trust framework. A web site will have to get permission in order to request credentials.
… a goal is to prevent arbitrary sites from asking for data. So safeguards are on the issuance side.
… US might be different.
… so it will come down to UX friction
rbyers: We don't know for sure yet. We expect we'll have a risk engine and potentially alter our UI.
… where we have signals that something is abusive or riskier, those are transactions where there would be more incentives to release less information.
Nick_S: So are you saying that the responsibility lies with the issuers?
rbyers: I think it's primarily a problem for the issuers and wallets, with the browser as a backstop
John: You'll have a lot more flexibility in trust signals with digital credentials than webauthn
benoit: Customers also provide information they shouldn't out of convenience.
… the same type of information sharing will happen. Who decides who I should open my wallet to?
John: That exists with form fillers today. The question is whether we can do something better.
Kristina_Yasuda: We seek to have guardrails in place to prevent race to the bottom.
… could you summarize for payments use case, what's the biggest delta from current APIs? Is it presentation of 2 credentials?
Lee: We need multi-doc presentation and transaction confirmation. That's what OIDP would need to land.
… I don't think the browser API needs to fundamentally change, it's just what goes in the request.
JohnB: We need to think about what the wallet selector presents.
… e.g., some standardized way to present a series of things to the user to avoid confusion
Lee: Another idea - receipts could be issued to the wallet after a transaction.
… also, we'd get cross-device issuance using FIDO CTAP
Mike Jonese: If you have a flow where you use multiple credentials at once (e.g., payment + age). Can you talk about the UX challenges and solutions?
Lee: If you are requesting 2 things and both are in the same wallet, it's pretty easy.
… there could be one consent moment and one fingerprint tap.
… what's tricky is when credentials are in different wallets.
… we have to do a mediation thing where we get consent from different wallets.
… we are still thinking how best we could do this at the platform level.
… we could start with a MVP of expectation of "same wallet"
… from an online POV, another approach is to serialize the requests. But in an in-person flow, that's not as acceptable.
… we have some ideas including a single biometric fired off to 2 wallets.
… if you have custom consent language from two wallets we are still working on how to do that.
JohnBradley: the EU Commission has a notion of "related keys."
… the notion that the age comes from a credential derived from the personal identity doc, and the KYC was from the same document, that might be important in some use cases.
… so "coming from the same document" may be valuable
Nick_S: I'm not sure it's that easy to do with 2 credentials from same wallet.
… I think the UX is going to be challenging.
Eric(Visa): Is there an assumption that user validation will be done through the wallet?
John: If so that means that wallet needs to be trusted by the issuer
Eric: You can spoof the credentials to a fake wallet.
John: One hopes that the credit card issuers won't issue credit cards to insecure wallets.
Eric: Attackers will try to issue credentials to fake wallets.
John: We are assuming wallets are certified.
Lee: There is transitive trust.
… as an RP I get some trust at the issuance level
John: If the RP has to know about the trust posture of the wallet, you get a fragile ecosystem.
(Architecture ideas)
Tim: One question is relationship to Payment Request API?
… there are some overlaps between PR API and other specs. Is there an appetite for convergence?
… especially where there is a transition period where multiple APIs are in use.
<Zakim> rouslan, you wanted to discuss the transaction payload
Rouslan: Thank you for the connection to PR API. When we designed PR API, I leaned more towards trying to standardize parameters common among multiple payment methods.
… there are arguments for and against.
… when more information is available to the browser, the browser can do a better job mediating / creating UX
… when more information is part of the payment method, it makes payment method innovation easier.
… so I advise surfacing a bit information to enable the browser to understand the payload.
<Zakim> rbyers, you wanted to contrast DC and SPC tradeoffs
rbyers: Right now the digital credentials spec has a registry of supported protocols. OpenID for VP is looking at PR API.
… at a high level we agree, but it's also a question of what layer of abstraction we are talking about
rbyers: Agree with tradeoff between innovation and other considerations like consistency, or help from the browser.
rbyers: Another big topic is we don't have a plan yet for digital credentials on desktop.
John: I have a solution, but it doesn't yet connect to the digital credentials API
rbyers: There are some open questions around desktop.
… this relies on getting a wallet installed and provisioning a credential. I see SPC as offering some help here.
Nick_S: +1 to rouslan's point. Browser needs information to protect the user.
… the browser should protect the user from input that is not trusted.
… we should be sure that if we way that the browser should pass data to an environment with elevated privilege, we should be cautious
Lee: I don't have the same level of concern.
IJ: PR API has on the fly installation.
Nick_S: Are we suggesting two independent APIs related to payments?
John: Right now the EU commission is doing a large scale pilot to do payments as part of the European digital credential.
… they are standardizing it and various people are looking at a way to do this.
rbyers: And one reason is that payment handler does not have broad support across platforms.
Kristina: It would be helpful if we could have one profile for payments.
… it's working well for mobile driving licenses.
… I'm happy to help. For content of transaction data I'd need to work with people.
… another use cases is qualified electronic signatures
… having clarity on the profiles and clarity on whom to collaborate with would be helpful.
Tim: Right, we'd need to break apart what the profile would be.
… there's a query component, a credential structure, how you request it.
… and what you're requesting.
NickTR: When we designed payment request we broadly punted on the payment method specific data.
… payment method owners define their own data models.
… Payment Request is limited to thinks like amount, currency, and a few other things.
Kristina: Starting point could be https://
(Discussion of rendering and selection challenges like de-dedupig)
Nick_S: We spent a lot of time talking about deduping; it would be bad if you clicked a button and got 8 wallets with the same card.
IJ: Display order and selection is very complex. Lots of opposition to handing the UX over to the browser.
IJ: The more you stuff in a wallet, the higher the stakes will be
(Next steps)
Tim: Where do we discuss query syntax? Types? Specificity?
… where do we go post TPAC?
Sue: Where's the discussion happening today in W3C?
Tim: In the WICG at W3C, DCP at OpenID
Tim: I think it's the DCP work at OpenID
Nick_S: If the w3c is going to standardize anything on payments, I would recommend the WPWG.
… I think this group would be a good forum discuss the payment elements.
… there are also questions about getting something out fast
JohnB: EU is not thinking about W3C at all.
Lee: All the current proposals are using custom URL schemes.
… it's clunkier
<nicktr> EWC = EUDI Wallet Consortium
Nick_S: Would hate to rush a standard for a single juristdiction
ACTION: Ian to work with TimC, LeeC, NickTR, and Kristina Yasuda on next steps regarding conversations about digital credentials and payments.