Meeting minutes
See also 11 September minutes.
EMVCo Update
SPC in 3DS
Blockers for SPC Adoption
SPC in EDS (ideal future state)
Mockups for suggested UX changes
Three types of SPC supported
- Merchant only
- Issuer only
- Merchant using Issuer token
sameerT: (shows current state slide)
… Merchant initiated SPC - Issuer is RP, SPC invoked by Merchant
… Issuer initiated SPC - Issuer is RP, SPC is invoked by Issuer
… Delegated authentication: Merchant or PSP is RP, SPC is invoked by Merchant or PSP
SameerT: Supported in Edge and Chrome for all cases
SameerT: Issuer initiated needs 3DS 2.2+
SameerT: As noted yesterday, delegated authentication means the cardholder doesn't see Issuer branding
SameerT: Currently unsupported use cases or gaps: Recurring/Subscriptions; Non-payment (ID); UX
SameerT: blockers to adoption:
… 1) support for recurring payments
… regulated markets require users to be informed of complete transaction details
… 2) lack of more channels (missing browsers other than chrome/edge)
… lack of implementation in Safari is hindering investment
… native app support via android may help
… 3) feature awareness
… EMVCo is educating industry through spec literature and white papers
nick_s: I am concerned about adding transaction details in SPC - in particular it being seen as an open-ended commitment to meet every regulatory requirement that might come along
… might not it be better to add support in payment request?
smcgruer_[EST]: SPC uses Payment Request - perhaps that whoopsie will end up a positive
SameerT: we have defined a data dictionary in 3DS 2.3.1
rbyers: are there other browsers that you'd like support from?
SameerT: Firefox
SameerT: We do not hear Samsung browser currently
… Edge is supported via the chromium render engine (on Android/Windows)
… and in the Apple ecosystem
smcgruer_[EST]: Ian and I have been working on documenting browser compatibility
Gerhard: we need to define the boundaries of SPC
… it is not a solution for all payments
… it's web retail on C2B
… when will app support appear for SPC in the 3ds spec
SameerT: we don't want to disrupt the app flow
… and we may wait until android support
… and a major version release of 3DS
Gerhard: that is a bit of a chicken and egg situation
Gerhard: can we use a custom tab rather than native apps?
… is that a quicker route, and could we do it in 2.3.2?
SameerT: possibly
rbyers: on native support on android app, we are reluctant to invest until we saw more usage
… in the narrow use case/channels it is currently available
… it's like a flywheel
… it's all about the usage to give us momentum
SameerT: issuers tend to adopt new technology/specs rather slowly
… we have ACS providers in the room that are showing this to issuers
<Zakim> smcgruer_[EST], you wanted to ask if its 'Android or iOS' or 'Android AND iOS'
SameerT: AND
nick_s: we are not chartered APP apis
… I would prefer that we focus on the web experience
doug_F: SPC isn't standalone. For cards it needs to be coupled with 3DS
… that's why we are experimenting with 3ds 2.2 and and extension to try to decouple adoption from the release cycle of 2.3.x
<Lee__> +
rbyers: to be clear, lots of experimental deployments would also be a positive sign
smcgruer_[EST]: SPC doesn't need 3DS. It needs a communication protocol
dougF: it's needed for cards
nick_s: we are well represented for card and underrepresented for other payment systems/schemes
… we need to be cognizant of those other methods
Lee__: we are regulated globally - we need to keep the specifications flexible enough to meet those demands
… it's not just PSD2
… we need to track the high watermark
SameerT: we try to design specification against the anticipated high watermark rather than the individual regulatory environments
Gerhard: the use cases (e.g. repeat billing) are across many payment ecosystems
SameerT: card users are educated to look for issuer and scheme marks on authentication UX - feedback is welcome on how to achieve
SameerT: ideal future state: support for recurring payments; non-payment use cases, all browsers and channels, broad awareness
SameerT: (shows potential SPC UI enhancements)
SameerT: shows suggested data dictionary
nick_s: we need to revisit basic card
… perhaps we should put these into basic card
smcgruer_[EST]: we would need to resurrect basic card too
nick_s: I am wary of making SPC a generic checkout
SameerT: SPC brings us sign what you see. We need to maintain that
smcgruer_[EST]: I agree that we need to put as much of this into payment request as possible
smcgruer_[EST]: is the EMV proposed dictionary appropriate across all payment methods?
Gerhard: broadly
smcgruer_[EST]: how many combinations are possible?
SameerT: you could technically have arbitrary combinations
Gerhard: I talked to a huge payment provider recently - they are adding subscription and variable subscription (standing mandate) as their priority in their APIs
gkok: users can get confused they are signing up to (variable, sub, usages)
<Zakim> rouslan, you wanted to respond to basic-card suggestion
rouslan: I would only use SPC in the Uber use case when the ride is complete
SameerT: that would be a lot of friction
<Lee__> +1 on the friction
rouslan: I agree that it would be cool to bring as much of the data up to a common level as possible
<imran> On the previous topic about compatability with Samsung Internet. We tested that and SPC is not supported - user is unable to register.
benoit: +1 for defining these things at the payment request level, not the payment method
nicktr: recounts history of PR/payment method. Note broad consensus to have common data items defined in the payment request
break for coffee - back at 11:36
Entersekt SPC Demos
Gerhard Oosthuizen SPC demo slides
Gerhard: I am going to show several demos to show some of the challenges
Gerhard invokes a silent prayer to the demo gods
Gerhard: introduces Entersekt - we're all about transaction authentication
Gerhard: we have two main product lines - customer authentication app sdk and ACS
… we like to say we killed OTP for our customers
… there are lots of authentication use case in financial user journeys
Gerhard: the challenge is not just getting users to click "yes", but also to converge online fraud detection
… there are lots of signals that we also need to account for
gerhard: you cannot trust OTP. We check explicitly for SIM swap
(shows 3DS screens)
Gerhard: it's worth bearing in mind that smart phones are not available everywhere
… or to all consumers
… notes three benefits of SPC:
… 1) trusted display
… 2) signing what was shown
… 3) cross-domain control (merchant/PSP initiated SPC)
Gerhard: today I am focussing on display and proof
… for the demos, I have three authenticators (windows 10, android, ios 16), five environemnt (windows 10 with chrome, samsung with chrome, iphone 12 with chrome, iphone 12 with safari, windows 10 with edge) and to transactions (login and payment)
Gerhard: note that I am using QR just for demo purposes.
… it is not used in production
(shows API)
(shows login demo)
Gerhard: The URL shown in the pop up isn't very helpful - would be great to have a better RP name label
(shows content of token)
(shows payment demo)
Gerhard: URL for card art is a separate field
Gerhard: I have to verify before the biometric gesture (on windows 10/hello)
Gerhard: on windows, we do not get the AAGUID (attestation). We do on Android
(now shows payment on android)
Gerhard: we see an additional dialogue because the token was created on a different browser
… windows does a good job of sharing FIDO tokens across the platform, but the browser (chrome) doesn't know about the SPC context (?)
fahad: Why didn't it work on Edge?
Gerhard: Works on Edge and Chrome. It's all about where the token is created - the browsers don't share memory space. So they fall back to vanilla webauthn
smcgruer_[EST]: We can make that work in the same domain on Windows, but not across cross-domain
gkok: what's the x-domain use case?
smcgruer_[EST]: it's to stop the reputational risk. There's a bit you can set to allow cross-domain which is specified in CTAP but no platform authenticators currently support the bit
smcgruer_[EST]: so the cross domain model doesn't work on a different browser on the same windows platform
… MACOS is a different beast
smcgruer_[EST]: I think this would only be fixable in windows 11, btw
(iOS demo)
Gerhard: domain, not name shown, and dialogue is "sign in" not payment because SPC is not supported
(shows android galaxy login demo)
Gerhard: says "verify"
smcgruer_[EST]: what device?
Gerhard: samsung galaxy
(shows android payment demo)
Gerhard: currency shown differently (USD, commas)
… "verify" again
Gerhard: do we know why it's different?
smcgruer_[EST]: we need to investigate - Samsung appears to behave differently to other phone vendors
Gerhard: the experience is being driven by platform
tomasz: it would be great merging the two dialogues (SPC, then platform authentication prompt)
tomasz: can we use cookies to help here?
Gerhard: yes, but if you use cookies and the user clears cookies, the experience breaks
<Zakim> rouslan, you wanted to make a suggestion to maybe not use webauthn as a fallback to "NotAllowedError"?
rouslan: nice demo. looks good
… not allowed error is returned in other use cases (like cancel). Might not be the way to proceed
Gerhard: agreed.
nick_s: we are not requiring browsers to require user interaction. The spec language is "may".
… we also have privacy challenges here around device fingerprinting
… (aka device signature)
… and for the record, applepay and google pay deliver the "unique benefits" at the beginning of your slides.
Gerhard: yes - and I should have written "over webauthn"
Gerhard: to conclude: predictability is key. We need to know whether something is going to work or not.
… there is also this question around PSD2 and passkeys because of the lack of device binding
… uncertainty about availability of FIDO and inconsistency of fallback is the major challenge
Gerhard: three suggestions:
… 1) browser only journey - browser controls complete journey outside "regulated" jurisdictions
… 2) industry wants low fricion, and anything is better than SMS OTP. Can we find a balance between friction and privacy? In the US, friction is just such a barrier
… 3) SPC for passkey will be great (no browser caching) and attestation
nick_s: can you expand on the browser only journey?
gerhard: outside the highly regulated market (e.g. EU), the browser signing the challenge would be enough for many issuers without the OS
nick_s: the browser isn't trusted - we're always going to need platform
gerhard: sms otp is so bad. browser signing is better (esp with web crypto)
<nick_s> (FWIW I suspect the question the 'browser only' approach raises is 'aren't we just re-inventing cookies')
gkok: so you wouldn't be able to say the device is trusted?
Gerhard: if the customer says "I don't mind skipping friction" and consents, then in some markets, it would be enough
… "trust this site/merchant"
… this is a familiar pattern
Payment Link Type in HTML
rouslan: this is a proposal to add a feature to Chrome and we are seeking feedback. The issue is around push payments where QR code is displayed
… example 1: PIX in Brazil
… multiple manual steps and QR code scanning issues
… example 2: MAYA in Philippines
… example 3: QR Ph on desktop
… Can the browser assist?
… Android intents? Only works on Android
… Payment request? Requires active integration by the merchant
… Alternative: payment link
Example: <link rel="payment" href="content of the QR/code-to-copy">
… It's declarative, easy to add, optional
(shows flow)
rouslan: shows illustrative examples of payment links for UPI, Bitcoin, PayPal, Brazil PIX
… this is all still in exploratory mode
smcgruer_[EST]: this is not strongly tied to webauthn.
Gerhard: I like it
… how is this different to a redirect?
… you might want to have several links (e.g. Singapore many banks)
rouslan: user must show strong preference for a certain payment application (so no multiple payment methods)
rouslan: it's different from redirect because redirect is all about showing different web pages whereas this is about showing browser UI when there is a payment app available
<Zakim> benoit_, you wanted to ask about who is allowed to add that to the DOM
benoit_: I like the idea but I wonder about security
… many payment methods rely on a phone as a second factor
… and who can add this to the DOM? Only the parent frame?
rouslan: if phone is assumed second factor, this is probably not a good choice
… wrt to DOM, probably only available to parent/main frame. Permission policy would have to be used for iframes but that would add complexity
SameerT: is the issuer sending something back to the browser
smcgruer_[EST]: the browser has handed off to the payment app
gkok: can a user set which app should interact with a payment method?
rouslan: you could ask the user to preselect the payment app - we were just investigating if this could be done really simply
gkok: I think there's a lot that the browser doesn't want to manage around regulatory
smcgruer_[EST]: you could do this today with payment request. We hear from the market that implementation hurdle is high.
… and payment request assumes merchant site communicates directly with user. But reality is lots of back channel comms
<Lee_> https://
doug_F: did you look at payment pointers?
rouslan: we think it's a different use case
… we're just trying to make QR codes less painful
alakatos: we have something in interledger (incoming payments)
JeanLuc: I was looking at payment pointer drafts - I think we could find some synergies here (and also with payment handlers)
break for lunch
Joint meeting with webauthn, webauthn adoption CG
steele: WebAuthn Adoption CG tends to operate in forums populated by developers like Stack Overflow - a more general audience, without IP restrictions
… over the last week we have been developing passkeys.dev
… we are all about understanding and adoption of the standard
… we were one of the first groups to exist specifically around adoption
matthewmiller: (shows passkeys.dev)
… you can see feature availability here
… we have had about 16k visits over the last month
… we are "non-partisan"
… we would welcome contributions or pull requests
matthewmiller: adoption CG is a great place for third-party RP to be heard (rather than platforms)
tony: we are currently on level 3 of webauthn
… we are chartered until june 2024
… we would like to be at candidate recommendation by the end of the year
… germane to WPWG, PR 1801 is complete - cross-domain usage for both creating and getting credential
smcgruer_[EST]: support for cross-origin creation is not yet availabile in Chrome
… we do need two implementations
<smcgruer_[EST]> https://
smcgruer_[EST]: we think that completes one of your wishes
… we have also done the work to complete passkey
TimCappalli: passkey is just a name for a kind of webauthn credential. it's not a new spec
tony: there is a method available to find out if passkeys are available
… we have also added compound attestations
TimCappalli: compound attestations are needed for software authenticators - e.g. credential is in hardware and software is from Google play
gerhard: it would be nice to set restrictions up front
TimCappalli: we expect compound attestations to be used on managed devices
tony: there is also firmware attestation
TimCappalli: that is for enterprise attestation
tony: PRF (?) attestation is back in L3. Allows a symmetric key to be associated with a credential
gerhard: what is PRF?
TimCappalli: pseudo-random function
… there is interest to store non-webauthn keys for logging into non webauthn applications
gerhard: can i update the symmetric key associated with a webauthn credential
tony: I think those are the main things
gerhard: do you track which levels are being supported by operating systems
matthewmiller: we're working on it.
<steele> Matt Miller's PRF example: https://
gerhard: there is a lot of interest in adoption in webauthn in banking
… in the last two days, we've seen demos from Visa, Modirum, Netcetera, Entersekt
… SPC is a separate verification click, then webauthn pops up
… it would be great to alighn on that
… would be great to do non-payment use cases, recurring payments, reduced friction
… in the US in particular, friction is a swearword
… we have been looking at unpredictable fallback journeys
… which is making it difficult to get ACS vendors involved
… EMVCo has included SPC in its specifications
… but adoption is low at this point and so adoption is a core concern
gerhard: being able to detect that SPC is available is a core concern
tony: I heard autofill?
smcgruer_[EST]: we are happy to chat but it's not specific to webauthn
helen: I think those are orthogonal discussions
gerhard: we also heard today about an early proposal from Chrome about payment links where QR codes are displayed
smcgruer_[EST]: like PIX in Brazil
gerhard: passkey has caused concerns about whether webauthn remains a possession factor when the credential is shared across devices
nick_s: we have some complementary concerns
… balancing privacy v friction
… and we would like to see attention on non-card
tony: we have added Cable or hybrid transport (but it's down in CTAP, rather than Webauthn)
gerhard: would x-domain work?
TimCappalli: it should
jonathan: is x-origin support planned for webauthn?
smcgruer_[EST]: for payments only?
jonathan: yes
steele: we are looking at multiple RPs being associated to a single credential
TimCappalli: but that still assumes the same origin
smcgruer_[EST]: what would we gain by having it in webauthn?
jonathan: better wider adoption
smcgruer_[EST]: it's the SPC UX that reduces the risk with x-origin credentials
… we could put it into the webauthn spec but I don't think it changes a lot
gkok: would the type of authentication be available?
TimCappalli: it's in the spec as an extension but no one has implemented it
gkok: what would it take?
TimCappalli: I'm not sure
Gerhard: the friendly name is used inconsistently
TimCappalli: display name v user (?) name
steele: I don't think there's a pull request for that yet
gerhard: web domains aren't always very friendly
… could friendly names of the RP be available?
TimCappalli: we are only looking at that where there is no domain (e.g. web developers using firebase)
… it's coming up a lot and we are working on it
tony: we could look at look at display name for L3
????: are there SPC demo sites available?
<rouslan> https://
smcgruer_[EST]: yes for SPC. The use of straight webauthn in payments is more difficult. I don't think there are demo sites for that
<smcgruer_[EST]> https://
????: is SPC the right API to look at
<smcgruer_[EST]> https://
gerhard: SPC is very closely bound to webauthn
… payment request is more generic
nick_s: SPC is an API for confirming payment. It's not a payment API
smcgruer_[EST]: at a technical level, SPC builds on payment request
… it could exist as an extension to webauthn
??????: I have an open question about what we are showing users
Entersekt SPC issuing tokens demo
Gerhard Oosthuizen Slides on SPC and Provisioning
Gerhard: this is about card tokens - bound to a specific domain like a device or a merchant or a processor
… VISA have announced that they are issued 5B tokens as of Feb 23
… it's actually a high risk activity
… the two dominant forms are third-party physical wallets and ecommerce wallets
… shows two examples of banks using OTPs
… it's all about what the issuers offer
… shows example from developer.visa.com
Gerhard: can SPC be used for this?
… SPC can be used for transaction already. Could it be used for provisioning and enrolment?
Gerhard: Visa and Mastercard have both introduced tokenisation programmes to reduce friction by shifting the burden of authentication from issuers to merchants
… (shows standard SPC)
… proposal: enable provision during provision (check box in SPC dialogue)
… proposal: enable provision without shopping
… store -> requestor, payment -> token, remove payment amount, merchant to (something else).
gkok: does the consumer care about token requestor?
tony: there are so many token requestors
Gerhard: perhaps type of token is more useful
tony: but it's very hard for consumers to understand
gkok: I think it's more important to know that it's being stored in hardware, but for ecommerce, they don't want to know
… just make it non-payment - just user verification
… isn't this just "adding card on file"
SameerT: consumers don't know about tokens
… we should avoid language about that
nick_s: I don't know if we need to solve this
… if we can solve this generically in SPC then that's ok
… but we shouldn't have to build specific technology to solve for this broken legacy use case
Gerhard: we need to strike that balance
… this pattern of creating a lower friction journey after signing up to it is shared across payment methods
… I accept that this is currently framed as a card problem
JeanLuc: do we really need SPC for this? Can't we use WebAuthn for ID&V?
<smcgruer_[EST]> +1
Gerhard: webauthn doesn't give us the cross-domain or payment instrument specific
JeanLuc: but we can use the ACS for specific attributes
SameerT: I support the idea of using SPC for ID&V
… the power of SPC is the secure modal
smcgruer_[EST]: I don't think SPC adds much here over an iframe from the issuer. We should avoid putting things in browser UI when it could be web content
gkok: I am skeptical that SRC can be used for this use case. We know as a device that we need to the FPAN as well as the TPAN to get the best performance. I don't understand how this is just web content
rouslan: the web content can provide the context, and then webauthn can be invoked
nicktr: I would urge us to keep things small!
nick_s: our charter explicitly rules out how schemes register and communicate with payment instruments
nick_s: PING are meeting directly after us in this room and will be discussing FEDCM that we saw the other day
benoit_: the payment method owners may well have UX requirements
Lee_: the regulatory authorities also have requirements
benoit_: there may be mandatory information in one regulatory domain that is prohibited in another
Bastien: we need to keep the specifications open and let the owners of the method provide specifics
… we should avoid adding another layer
Actions
Gerhard: explore payment links
SameerT: ask WPSIG to look at a review of EMV 3DS data dictionary as it pertains to SPC
Gerhard: explore 3DS SDK to figure out how SPC might be supported
… and help facilitate adoption
Gerhard: I want to explore a silent signal around trustworthiness of browser instance
SameerT: we have asked for this before
tomasz: combining the SPC and webauthn dialogues seems like something we should continue to investigate as a barrier to adoption
JeanLuc: what about GNAP protocol?
<JeanLuc> https://
benoit: it is also being used for interledger/Rafiki and payment pointers
dougF: it would be great if we could work with webauthn and FIDO to get better support for SPC and in particular getting biometric authentication over PIN or Password (and being ablt to state a preference)
session ends
Next meeting
nicktr: We next meet on 28th September
Close of meeting
nicktr: thanks to everyone for there efforts. Particular thanks to our presenters
… minutes will be available soon
… along with the presentations
ADJOURNED