dirk: This presentation is a sort of joint
proposal by Google from both auth and payments people
... my background is not payments, so apologies for any
terminology gaffes
... in the world of payments there are many trust
relationships
... our use case here is where you have an app, and when you
say you want to complete the purchase, you are handed off to
the PISP (in PSD2 terms)
... the PISP has your account information.
... Your account belongs to a bank; the PISP interacts with the
bank
... the bank wants to authenticate the user
... FIDO is a great way to do that authentication
... however, even if the PISP has a FIDO credential, it can
only be used with the PISP's origin.
... so the bank's origin doesn't know about the credential and
can't do the authentication directly.
... here are some requirements for this use case:
a) No assumption of pre-existing trust relationship between the PISP and the bank.
scribe: otherwise the PISP could
just tell the bank "I did the FIDO auth myself; trust
me."
... but here we are assuming no such trust relationship.
... the bank wants to authenticate the user
b) We don't want any additional network connections coming out of the user's device
c) The bank wants to directly authenticate the endpoint
PROPOSAL: We let the bank
directly create a FIDO credential (when the user interacts
directly on the bank origin), scoped to the PISP.
... for example, this enrollment could happen when the user is
setting up their app with the PISP
... the payment app hands the user off to the bank (origin)
during this setup phase
... the bank does KYC at this point
... satisfied, the bank creates a FIDO credential FOR the PISP
(pisp.com)
... at the same time, the bank knows the public key for the
user it just authenticated.
... part of the redirect back to the PISP involves handing the
new credential to the PISP.
... so the overall flow would look like this:
* User pushes the buy button
* There will be some understanding between PISP and Bank about the nature of the challenge from the bank
* The PISP can authenticate the user and send the result back to the bank
* The bank verifies that credential against the one it originally created
Dirk: This involves a change to
WebAuthn: that Relying Party A can create a FIDO credential for
Relying Party B
... but people ask: what about tracking / correlation?
... we don't want to create a supercookie.
... but this proposal does not do that because:
1) The credential is scoped to one relying party. (It was just created for that RP by another.)
2) The credential must not be resident-key.
scribe: the concept of
"resident-key" in FIDO: the RP can ask the underlying platform
"who is the user"
... if the underlying platform has a "resident-key" it can
answer who the user is
... if it's not a resident key, the RP has to already know who
the user is.
... so in this use case, the credential cannot be a
resident-key...this ensures that there is no NEW channel
created for communications between RP A and RP B about this
user.
Dirk: Benefits of the proposal
a) Meets requirements enumerated above.
b) No change to CTAP/authenticators
c) "No resident-key" requirement has side effect of precluding DoS attacks
Dirk: I Presented at FIDO a week ago, but this proposal would be part of WebAuthn
Tony: There are some platforms that require resident credentails.
John: I think that the right terminology is "preclude discoverable credentials" (rather than resident)
Tony: At the FIDO meeting we were
also talking about being able to include some history
information
... in the client data
... we should be able to have some "previous history" about who
asked whom
... we should be able to include the PISP origin in the
data
Dirk: Ok, I am hearing both origins should be put into client data (who asked, who created)
John: that already happens for native apps on Android and some other platforms
Tony: But not yet on WebAuthn
John: We need to improve the documentation
Jonathan: Here the proposal is to
have the issuer create credentials that are tied to a specific
merchant, versus the case where the merchant creates the
credentials.
... there's another user case where the merchant creates
credentials and shares with the issuing bank
Dirk: My understanding is that this proposal fits the use case where it's not the merchant but rather the PISP
(IJ notes that this aligns well with the payment handler model)
Dirk: So this is the app that has
the credential
... the other point I would make is that, when the merchant
creates the credential itself and gives it to the issuer -- how
does the issuer know that the merchant really asked the client
device for the credential (instead, of, say the merchant using
its own phone to get the credential)
... so this approach assumes less trust between merchant and
issuer.
Jonathan: It seems that there is
a sharing of the FIDO assertion(s) with the issuer
... I thought the big advantage here was that the issuing bank
could, on the fly, give access to its existing
credentials.
... so where the issuer doesn't trust the merchant, it could
share the credential with the merchant's FIDO server.
... in the current proposal, how does the merchant authenticate
the user? How do they know the authentication is "good" or "not
good" when they go to the issuer.
Dirk: The merchant could, of
course, have its own credential to authenticate the user.
... my understanding is that the issuer's authentication may
not happen every time (may depend on risk profile)
... part of the design space here was to say "what if the
issuer just made a credential and then somehow let all the
merchants or PISPs use it?" ...that would have been (1) a much
bigger change to the spec and
(2) would lead likely to supercookie
Jonathan: My interest is the merchant being able to immediately leverage previous authentications by the bank.
Tony: What about consent?
... otherwise the user doesn't know when credential is being
used because the user consents to the usage
Jonathan: I think it would be still beneficial to support the other model.
Benjamin: Doesn't the consent
come from it being non-discoverable?
... the merchant says "I want to authenticate with this
identity" ... so that implies they know who the user is.
Jonathan: Another topic -- how does issuer or merchant know a credential is available?
4 March