Payment Use Cases for Web Authentication
[IJ intro on changes to the wiki]
Benjamin: I wanted to highlight
the "merchant as pass-through" use case and expand on it
... I thought this use case was interesting because it mostly
mirrors EMVCo chip card behavior
... I wanted to see how webauthn might be integrated in the way
EMVCo chip cards are today
... this raises a couple of use cases of interest.
(1) There is just one user action to pay
scribe: ordinarily we think about
two steps: user clicks "pay" then authenticates to the issuing
bank; but that's a pretty long user journey
... I think the way it should work is "just one click"...or
even simpler - the user is in an authentication experience and
all they do is tap their authenticator to check out
... so I wanted to highlight that simpler UX as a goal
... today's auth flows have high drop-off
(2) The other thing I wanted to talk about is how the issuer and origin communicate
scribe: model a) Merchant and
issuer embed in some way (e.g., via iframes)
... this is not the best option because it means that the
content security policy (CSP) doesn't work
... we've also heard from some merchants in our other work that
embedding content from lots of issuers in their page is not
something they want to do
... so an alternative might be for the browser to issue a call
to the issuer to validate a signature
... however, it would be good to avoid real-time network calls
for a variety of reasons
... sometimes there are also constrained network environments
and you might want to block payment until the user has gotten
to a different network scenario
... the EMVCo chip model lends itself to store-and-forward
model
... you basically save messaging and forward it later when
network connectivity is sound
(3) Another use case is separating keys and having additional origin constraints
scribe: e.g., origins might want
to have separate keys, such as banks wanting to receive one key
for banking, but another for payments
... issuers will not want 1p keys to be used for
payments...just banking
... and they will want 3p keys for payments scenarios and not
banking
jeffh: Benjamin implied "captive
portals" ... they are a rabbit-hole unto themselves
... there is work in the IETF to standardize captive portal
protocols
IJ: So you think there's a separation of concerns?
Jeffh: People might want to look at the internet drafts and see how things might layer in terms of the authentication mechanisms
benjamin: I can take a look
Jeffh: See WG "caport"
IJ: How does BT's comments map to current WebAuthn discussions?
jeffh: I am assuming that
Benjamin was referring to the user's key pair that is created
on the client side
... the key pairs are created on a per relying party
basis
... where the relying party is identified by their domain name
and/or registrable domain name (see WHATWG spec for exact
name)
... I think there needs to be a threat model looked at
carefully to see whether those concerns make sense
practically
benjamin: I don't want to be too prescriptive about "different keys"; prefer to stick to the risk where issuing bank can be tricked
jeffh: At an authentication event, an assertion is returned, and that contains a signature.
IJ: What does it mean for the bank to be tricked?
John: There are a couple of things that could work here:
a) Bank can issue a challenge that is specific to a transaction
scribe: I understand what you are
getting at, BT
... the easiest way to get that is to have a different host
name for the assertions generated
... to distinguish 3p from 1p
jeffh: +1 to JohnB
benjamin: Would there be a way to take the first RPID (the "online banking id") and say "This can't be used for payments use cases"?
JohnB: The bank should be able to do that by policy (since the assertion includes the RPID)
jeffh: The bank tells the
merchant how to integrate with the bank's payment flows. The
bank says "talk to this server with this host name"
... and tells the merchant "here's how it works"
... they figure it out so the right things happens...the call
from the JS into WebAuthentication has the right RPID
JohnB: The problem is almost
diametrically opposed to the problem BT stated. Right now there
is no way for the merchant to have the authenticator generate
an RPID for the bank. the merchant can generate a cryptogram
with the merchant as the RPID, which the bank should never
accept
... unless you convince the bank by policy
... so they are really highly differentiated at the
moment
... the merchant can't ask for a cryptogram from the bank's
RPID
Benjamin: I think that's the
discussion - can the merchant ask for an assertion from the
bank, or on behalf of the bank
... if we talked about that, then there would be a threat model
and an argument there
... but I'm convinced in the current world that having a
separate RPID is the right solution
... It's possible that what I was describing was not an issue,
and the solution is to create a separate domain for the two
uses; that's how you keep them separate.
JohnB: Right now there is no way
for the merchant to use the bank's domain as an RPID other than
redirecting the user to a bank
... we need to figure out whether we will allow a proxy
request. If so, we need to find a way to distinguish proxy
request from direct request
Benjamin: Bank also needs to be
careful to not let the user do the wrong thing in an iframe
(using an assertion used for the wrong thing)
... maybe even then they just want to be really careful about
whether, in a 3p context, the assertion can only be used for
payment (and not a banking transaction)
jeffh and JohnB: Seems no webauthn spec change is required
Benjamin: Is there a way to enroll both credentials in a same gesture
JohnB: No, you can't enroll credentials from separate domains at the same time
Benjamin: Can the user auth to the bank and register authenticator with the merchant at the same time. Might also be interesting to enroll two domains at the same gesture
5 February. Regrets: JohnB, JeffH