IJ: let's go through the questions
What are the requirements on the nonce (random, secret, etc.)?
scribe: see also https://github.com/rsolomakhin/secure-payment-confirmation/issues/26
Danyao: Right now we require a
round-trip to get nonce from ACS
... can the browser generate a nonce instead? This could
support asynchronous authorization of payment
... e.g., person wants to make a payment in a mobile
environment when there is no internet connectivity
... another benefit even in connected environment is to avoid
latency
Jonathan: The need is for randomness from the verifier. But the randomness does not need to come from the verifier (if the verifier trusts another party)
Danyao: In terms of stakeholders, we need both WebAuthn folks and ACS's to be on the same page
Jonathan: I think in the SPC proposal, the bank is the relying party and the verifier
Danyao: So maybe we need to write up a proposal for an ACS to consider.
Gerhard: Just to clarify - the original suggestion was that the cryptogram would come from the CReq. Is that still the case? or will it come via the AReq in a delegated auth style?
Danyao: Benjamin and I are trying to figure this out with the 3DS folks...current proposal is that the cryptogram goes in the AReq.
Gerhard: If that's the case, then
3DS has already been kicked off, and the nonce could come from
either the directory server or the bank.
... has the DS already allocated a unique identifier at this
phase?
... I recognize that the issuing bank is the verifier and
relying party here...but the DS could be generating a unique
number.
Danyao: "Not being able to guess" is the important property to prevent a replay attack. Malicious party should not be able to guess the number.
Gerhard: There are cases where an extra flow might not be needed. E.g., OAuth does not always require a nonce in use cases where there's acceptable risk.
Danyao: What is advantage of DS generating the nonce?
Gerhard: The PREQ goes to the DS before the AReq.
Danyao: Ah, so piggybacking on existing message.
Gerhard: Would like to either leverage an existing field or adding a field to an existing message, rather than creating a new message.
btidor: Can merchant generate the
nonce by extension?
... even if they are not the relying party?
Danyao: Please refresh our memories on the problem we need to solve. We had been talking about a new message to get both credentials and nonce.
btidor: One scenario is "combined flow" with instrument selection. But also similar to some autofill scenarios.
Danyao: In theory, the instrument ID could still be known at the time of generating the cryptogram. Are you thinking that the missing piece is that the merchant is out of the loop?
btidor: And what is required by WebAuthn.
btidor, Browser can create nonce using merchant data or entirely by itself.
scribe: seems easier for browser
to do it entirely by itself.
... by cutting out a step or a round-trip
Danyao: Can the merchant front end generate the info?
btidor: That's the heart of my question - what are the required properties.
Gerhard_: I am aware of two
fields: (1) FIDO alliances set of fields that they'd like to
have signed (FIDO->EMVCo data)
... (2) Signing of the transaction
... and then there's also (3) PSD2 dynamic linking
... so are we talking about using the SPC-specific payload? Or
can we leverage FIDO/EMVCo data?
btidor: Good question. I think we are not using FIDO/EMVCO fields because they don't allow verification of the transactino
jonathan: Two models: (1) The merchant has FIDO credentials already versus (2) the bank has FIDO credentials
IJ: There's no assertion data sent in the FIDO/EMVCO payload; there's no evidence of authentication having taken place. It's fingerprinting data that is generic but consistent over time.
Gerhard: Can we make the merchant instruction to the issuer be the same?
btidor: If we move cryptogram generation from merchant to browser, is the security argument the same?
Gerhard: My understanding is that
in 3DS 2 you have a signing algorithm (asymmetric)
... in that case, you are signing with private key of
authenticator, but in the other case you are signing with the
ACS's private key. Could be interesting to see if there is
overlap in the fields.
btidor: I think that would be
interesting; I didn't know that that's how it worked on the 3DS
site.
... Can WebAuthn folks verify in the traditional FIDO flow,
what attack is being prevented and how can we manage this in
the SPC flow? Why does the nonce need to be generated by the
issuer?
JeffH: Standard
challenge/response protocol design. You always include a nonce
from verifier in their initial request, sign over it, and
return it
... so there's freshness.
btidor: Do you think that by including the transaction data we are moving from "chall/resp protocol" to something else?
JeffH: My gut is that there needs to be randomness from backend all the way through the flow to the authenticator and back. In this case we are embellishing it with other actors. It also depends on your threat model, and risk tolerance. Perhaps the protocol doesn't have to be "air tight" but that, given a particular deployment, it would be reasonable to accept the risk.
Danyao: JeffH just answered my question about what we need to evaluate if we are diverging from standard protocols.
Jeffh: Has anyone done an analysis of 3DS using formal modeling tools?
Gerhard: We can ask the 3DS EMVCo folks for information about their threat modeling.
<Gerhard_> Closed network: Allocated Merchant ID + Transaction details (Amount, Currency, LocalDate&Time) + Random Merchant ID
Gerhard: We are dealing here with a closed network.
<btidor> Just wanted to ask if there are any FIDO threat models we can reference
JeffH: Yes. There's a security reference in the FIDO Alliance that has a fleshed out threat model
<scribe> ACTION: JeffH to see if security reference has been published by FIDO
btidor: +1. I want to be sure we don't stray from FIDO assumptions
IJ: Should we use SPC slot next week on this?
btidor: Maybe not.
27 October