Meeting minutes
BPCE presentation
Anwar: My BPCE colleagues and I have been looking into FIDO as a means of SCA.
… thanks for the invitation to present today
Anwar: Theme today is how we can replace "CAP Readers" with some FIDO-based solution (e.g., roaming authenticators)
Anwar: Our interest in SCA is driven by PSD2 requirements.
… multifactor authentication
… there are three use cases of interest in particular:
1) Connection / sign-on to services
2) Validation of sensitive operations
3) Validation of 3DS online payment
Anwar: What is "Sensitive" is defined in article 4 of the regulation. Every bank assess it on their own, but at a high level, it's any operation that might compromise the account
… e.g., adding a new payee; initiating a transfer; even changing the phone number associated with the account
Anwar: I think (1) and (3) can be achieved with FIDO/SPC.
… so my focus in today's discussion is validation of sensitive operations
[BPCE context]
Anwar: We offer different authentication approaches to our customers
… password, OTP by SMS, App-based ("Secur'Pass"), CAP Reader and card, Password and OTP SMS
Anwar: We'd like to replace the CAP reader with some FIDO-based approach
Anwar: One interesting reason is shortage of plastic for cards.
Anwar: The CAP Reader generates a code (like an OTP) and that code is used to validate an operation
… CAP Readers can operate in "code mode" and "response mode"
[Slide on use cases that involve CAP Readers]
Anwar: Although there are use cases that involve smartphones, we also have some use cases where smartphone will not suffice.
… in some cases they cannot receive an OTP by SMS (e.g., while traveling)
… in other cases they don't have a smartphone or prefer wired devices
… in other cases may simply not be able to use their mobile device (e.g., an accountant who works for a customer)
… so there are use cases where mobile apps won't work but Web will
… in all use cases FIDO keys could be useful, even in the main solution might be something else. But in some cases FIDO would be the only likely available solution.
[Customer journey to add a new payee]
Anwar: Note that in the flow, even if the user is already logged into their mobile banking account, the user will be re-authenticated prior to the sensitive operation.
… this second authentication might take place through CAP Reader, or through SMS OTP
… the SMS OTP follows an enrollment and ID&V process where the user provides a phone number.
Anwar: PSD2 requirements involve both (1) What you See is What you Sign, and (2) Dynamic Linking (unique code)
… we are interested in SPC for the payment transactions
… the question is whether we can have something similar for sensitive operations (e.g., adding a payee name + IBAN)
Anwar: Our data needs vary for these use cases; we still want to sign over that data.
ChristiaanBrand: How is the dynamic linking done today with CAP Reader?
… does the Reader display the details today? or is it just a code that is entered?
Anwar: In "Response mode" the screen displays a code we provide.
… and the CAP Reader generates a number that is based on the user and the code we provide
ChristiaanBrand: But there is no WYSIWYS capability in the CAP Reader.
… FIDO2 does the same thing.
ChristiaanBrand: If the current practice with CAP Readers meets PSD2, then FIDO as it works today should work.
Ian: How do you get to the code?
ChristiaanBrand: The server generates a code (the FIDO2 challenge).
… the hash includes details about the transaction.
… once you have the string, you pass that in during get()
… the authenticator signs the hash
… CAP is likely symmetric/ FIDO is asymmetric but that should not affect PSD compliance
Ian: There are interesting trust questions; can info just be sent to the RP, or would the user need to be in a 1p context.
ChristiaanBrand: SPC is interesting due to mistrust, so WYSIWYS is especially useful. But in FIDO some of the trust is returned (e.g., you've plugged a key into your device).
ChristiaanBrand: SPC is an additional level of control; helps in the 3p case but also is an additional security measure to say "This is really what you are signing"
… we are interested in a general transaction signing mechanism in WebAuthn
smcgruer_[EST]: ChristiaanBrand covered much of what I wanted to say. I wonder whether the CAP Reader argument shows that the reader has read what they are going to sign.
Ian: What more use cases would a user form field get us in an SPC dialog?
smcgruer_[EST]: Maybe WebAuthn should handle this. I don't think we should have users type codes into browser UX
ChristiaanBrand: It's so generic.
… could be many thinks like signing lease agreements.
… so makes sense to push down to WebAuthn
Gerhard: If we are looking at open banking, the use case closest to this in SPC would be recurring payments, or future dates for payments
… we might be able to get these use cases met faster via SPC
… we find that users like physical tokens; they may distrust platform authenticators more
… we've noted that for SPC we'd like to include support for remote authenticators
Gerhard: We will discuss this week learning more about creds on remote authenticators
Anwar: Yes, some people will still prefer an external device to authenticate (e.g., dongle)
… and they can't save properties on their browser
bdewater: I have such a reader; familiar with them. :)
bdewater: You can use these readers with a numeric response, but also connect via USB...in this case you would see the transaction details on the reader (at least the one I had in the netherlands)
… but agree if hashes suffice, I agree FIDO meets the use case
bdewater: I'll share some research on vulnerabilities
<bdewater> USB connected EMV-CAP reader vulnerability: http://
<bdewater> there was also another group that researched UK bank CAP readers: https://
<bdewater> update for the above link for the UK, this is the actual paper: https://
John_Bradley: I largely agree with the points from ChristiaanBrand. The PSD2 protocols, also STET, Berlin Group, FAP, etc. all support redirect-based mechanisms for the PSP to deal with banks.
… those are all capable of 1p contexts. Like ChristiaanBrand I agree that having an id for the transaction is sufficient in the way that the challenge mode for the CAP reader works.
… the CAP reader itself is punishable
John_Bradley: Browsers have not previously supported generic signing capabilities; but I think that would be an interesting discussion. But we may need to constrain to canned information.
… we should be able to add PSD2 transaction confirmation types.
Gerhard: SPC has three superpowers: (1) secure display (2) signing over standard data set (3) decoupling ceremony from validation
… and allowing other parties to leverage a credential.
… my understanding is that a full redirect happens in open banking
… are you aware of an open banking scenario where a TPP can get consent on their own site (without redirect)
… are there iframe scenarios?
Anwar: From my POV, the most common use case is the user is redirected to the 1p domain
… but outside of PSD2 other use cases may be very relevant
… regarding TPPs and 3p, I don't have more details
Gerhard: I am thinking, e.g., of subscription use cases, for example.
John_Bradley: While there are redirect protocols in PSD2, the ECB and other regulatory bodies have said "You can't force a PISP or an aggregation provider to do a redirect."
… so all of the API providers have some direct backchannel flow, and are using CAP readers and OTP in those contexts.
… also in PSD2 there are account aggregators where you may have a third party who is managing multiple accounts
… and in the third party you can add payees, etc.
… I was thinking that a lot of the payments use cases are covered [by SPC] but probably not yet good solution for embedded flows
… where there are sensitive interaction use cases that we've not yet discussed
Gerhard: Are you talking about CIBA?
John_Bradley: CIBA is part of FAPI
Privacy and Payments Joint discussion
[Ian Jacobs slides on privacy issues]
SPC Issue 128
smcgruer_[EST]: There is an existing webauthn threat where someone enrolls a user somehow and then the user does get() and reveals identifying information.
… SPC makes enrollment a bit easier than WebAuthn. With WebAuthn you have to register in a 1p context, but with SPC registration can happen in a 3p context (with protections such as permission policy)
… Privacy folks at Chrome asked us to include user activation requirement (not part of WebAutn)
… so we propose to add this (and have pull request for it)
weiler: How does user know the RP?
smcgruer_[EST]: that happens in platform dialog
<npd> user activation doesn't seem burdensome because you'd be clicking 'buy' or 'pay now' or something anyway
<weiler> [How clear is it to the user that this is a 3p?]
<Gerhard> question: Is this a different iFrame 'permission' for create vs auth?
smcgruer_[EST]: The same concern happens (about user "clarity") on get() side
Gerhard: Is the the permission distinct between create() and get()?
… could one set independent permissions?
smcgruer_[EST]: Today what SPC does is to use the payment permission policy.
<npd> permission policy doesn't seem like much of a protection if the threat model is a colluding first party site that already explicitly chose to embed tracker.com iframe
smcgruer_[EST]: ..what I'd like to see long term is that in WebAuthn they have a get() policy and I think there should be a distinct create() policy.
John_Bradley: There are two. We stopped implementation due to mozilla objection. We can probably revisit that objection.
… so permissions are reserved in the specification (but not specified) but are unimplemented.
ChristiaanBrand: At the time, we were not aware of use cases; now that there are active use cases we can visit
John_Bradley: The credential itself is not cross-origin here; it's being created in the origin of the iframe
Gerhard: Based on that clarification from John_Bradley. If a merchant allows an iframe to be opened for an issuer and a credential can be created for the issuer, why would that at all be linked to SPC?
John_Bradley: SPC has a work-around because that create() is not allowed in WebAuthn
smcgruer_[EST]: Long-term solution is to revisit in WebAuthn
John_Bradley: +1.
smcgruer_[EST]: Plan, then, is to close loop in Chrome and deploy the change to the spec and implementation with user activation
SPC Issue 77
weiler: Please add that text to the GitHub issue
Ian: Agreed.
weiler: Rather than encouraging the issuer to have per-instrument credentials, what if we made it easier.
… e.g., create 5 credentials instead of one.
Ian: Or even more -- generate 100 that the RP can use randomly.
John_Bradley: Current limit is 25 on roaming authenticators. So 100 per account would make roaming authenticators unusable.
Ian: So how do we make work "N credential IDs generated"?
<ChristiaanBrand> but, i think we specifically don't want that, right?
<ChristiaanBrand> we want a single registration as far as possible
<ChristiaanBrand> since that's the user friction/risky action
(Idea is N credential IDs for a single registration)
John_Bradley: You can't get N > 1 today.
ChristiaanBrand: When you do a payment, you are already giving strongly identifying user information.
ChristiaanBrand: ...so the odds are significant the user has already been identified. And often times the data is validated (e.g., shipping info)
weiler: My recollection is that the concern is correlation earlier in the payment flows.
<ChristiaanBrand> at least in the 3ds flow, i don't think it can be used that way
<ChristiaanBrand> it's also not an SPC issue, but rather a 3ds issue
ChristiaanBrand: You aren't asking the authenticator for credentials; the backend is the place you get the credentails
<SameerT> +1 to Christiaan
<Gerhard> +1 Sounds more like ACS issue than SPC issue.
John_Bradley: So if card issuers create different credentials for each payment instrument and only return the credentials for each instrument, that works.
<ChristiaanBrand> ACS/3ds
<npd> > For many current online payment flows this may not be a significant concern, as the user already provides sufficient information to do this joining anyway (e.g. their address), however it could become a privacy attack if, e.g., payment tokenization becomes commonplace.
npd: Would RP implementations be willing to do this?
<Zakim> npd, you wanted to ask whether rp implementations would be willing or interested
NPD: The spec actually does have guidance to RP
… in the future we might have more tokenized payments
… the question I have is: are banks interested in doing separate registrations per instrument?
ChristiaanBrand: big goal is to reduce friction with few registrations
… we'll have problems with credit card numbers as keys
… there is a balancing act between ease of use and privacy
… we would prefer FIDO to OTP
Gerhard: To a number of the points raised, in SPC right now as it stands you don't know if the device has credentials. How the credentials are bound to strings on the server and how people get them is out of scope.
… I support adding guidance to external systems
Gerhard: It's an issue but not for the SPC itself, IMO
weiler: If we assume that there are people who want to do tokenized payments moving forward, how do we make it so that they can do that and expose less information.
<npd> are we saying "be mindful" or are we saying, the account will always be a stable cross-instrument identifier?
John_Bradley: You probably can't with WebAuthn as it is designed. You would need to build a backend with tokenized credentials.
smcgruer_[EST]: If an RP wants to do that, they should open a popup or redirect to their own domain.
Gerhard: SPC can be used in 1p context. if RP is concerned about sharing information, they can ask to redirect the user to the 1p context.
… the RP may well want to control the situation.
Ian: could authenticators do salting?
John_Bradley: You'd need to change CTAP and have special authenticators have by reference credential IDs that are capable of doing unsalting.
… would be major changes to CTAP
<npd> was the suggestion before that this embedded cross-origin iframe feature of SPC will simply be incomptaible with tokenized payments?
<ChristiaanBrand> i don't know that you need SPC when you have a tokenized payment
<ChristiaanBrand> the point is that you'll only get a token ONCE auth has completed
<ChristiaanBrand> so, you use SPC to MAKE a tokenized credential
<ChristiaanBrand> after that, you probably don't need 3ds/spc
npd: Call out in the spec perhaps the use case when SPC would not be useful from a privacy perspective.
John_Bradley: Yes, tokenization that is privacy preserving is probably incompatible with 3p context.
ACTION: Stephen to revisit the guidance text to make clearer potential of tokenization to be incompatible with cross-origin part of SPC.
<npd> I think that's the reason that the account connection is an important privacy risk, if it would undermine future tokenization privacy. but actually, if we just note that with tokenization of payments, that would replace this, then we might be less concerned about any future impact.
<ChristiaanBrand> i agree with stephen. i don't think a user can reason about this.
SPC Issue 154
smcgruer_[EST]: I don't see how this is different from WebAuthn in an iframe. I cannot today as a user opt-out of someone using WebAuthn in an iframe
… the only notification I get is domain in the platform dialog.
ChristiaanBrand: I don't think user has information to make this kind of decision; would be incredibly hard.
John_Bradley: Would only apply to 3p context for payments; not webauthn generally
smcgruer_[EST]: Someone could do the same thing with WebAuthn and there would not be an opportunity to opt-out
https://
[We review that proposal for WebAuthn /CTAP]
[Gerhard recaps our goal of asking WebAuthn to take this topic into account as they look into providing support for new CTAP bit]
weiler: What is special about SPC in terms of cross-origin?
John_Bradley: WebAuthn credentials must be used by origin that created them; SPC credentials can be used by other origins.
[There are 2 axes: Who is doing get()? Is it in 1p or 3p context?]
ChristiaanBrand: It has become apparent that some folks want the bit. I don't think at this point in time that we need to tell the user anything about this because iframes look similar. But we'll have the discussion in WebAuthn.
<npd> but I can see that the bank/issuer might not want their credential to be used without running inside their code (iframe or otherwise)
weiler: If you feel that way, why not make this part of all credentials?
ChristiaanBrand: That's a good question.
ChristiaanBrand: The RP needs to be able to say "ok to use in 3p context". RP may never be ok to use in a 3p context and not set the bit. So this is not really about the user. It's an RP thing.
… the RP can always check the signature so may not be important anyway, but WebAuthn recognizes the use case and desire
… there has not been an intent to make this a user visible thing but we can have the conversation
SameerT: Christian covered what I was going to say; this is an RP-oriented capability
… the user could be informed via terms and conditions.
… this is an RP policy decision
John_Bradley: When the bit is set and used in a payment context, there is additional data in the assertion ("on behalf of") information.
… the only people who need to validate that information are the RPs.
… so in the iframe POV RPs know what is going on; they are the ones displaying the iframe.
… they already know the context (e.g., I'm ok with this merchant doing this)
… the RPs acknowledging that they want a credential to be usable in a 3p context is important; don't want it to happy by surprise.
weiler: If, after thinking about this more, I still see merit in having user choice in here also. Is there anything in the design that would prevent the user from downgrading the creation.
ChristiaanBrand: I would want to understand better what we are solving for.
SPC Issue 142
Ian: The normative text is now very specific (see the slide)
weiler: I hope you will continue to document "how to do this"
smcgruer_[EST]: +1
… our goal is to exhaustively spec ways to not leak data
… WebAuthn does still have this section.
smcgruer_[EST]: Still important to have security and privacy sections that highlight the scary stuff.
<SameerT> just to add for record for future PING discussions, in 3ds implementation of SPC (merchant initiated) the following requirement is imposed on merchants "Note: The 3DS Requestor is not allowed to change or store any of the data received for the SPC authentication from the 3DS Server".
weiler: Please include index to mitigation and close 142
SPC Issue 143
Ian: We think this is same as 77 and propose to close it in favor of 77
SameerT: regarding 77 again....
… we have a requirement in 3DS spec that the merchants NOT STORE any data when using SPC in 3DS
weiler: Could say e.g., that in spec
ACTION: Ian to work with editor on text related to 77 on guidance to RPs.
<npd> but it sounds like the question is just about 77, but agreement that 143 is a duplicate
weiler: Ok to close 143 as a dup of 77
ChristiaanBrand: We should be sure to state what the actual issue is we want to address.