<scribe> Scribe: Ian
https://github.com/w3c/webpayments/wiki/2020-TPAC-WPWG-agenda
IJ: Authenticating via second device something that merits special attention in the WPWG discussion?
Gerhard: I think they are working on that already via BLE. I think live on Android.
John: From a high-level, you should be able to use a second device in order to authenticate to an app you are using on your desktop.
JeffH: The way to think about it
is that your phone is a remote security key; that is live today
with Android for Google accounts.
... from your laptop's perspective your phone is a remote
key
Ken: Think of it as special transport
<clintona> I will be present on IRC only today
Ken: We are doing this in Android
proprietary way but are looking to make this more
standardized.
... but you can imagine a different user flow that does not
rely on client-side support
... the merchant could put a QR code on the screen, the user
could scan phone. That would be more work to deploy but would
work for more users.
IJ: What makes it more difficult with QR codes?
Ken: The phone-as-authenticator
would be easy via bluetooth..but you need an app on your phone
to act as an authenticator. (once deployed)
... but in the QR code use case, you are opening a browser and
then authenticating that way...can be done via server
side...would not require much additional support.
John: This is: Client-initiated
back-channel auth in PSD2 terms
... that has nothing to do with WebAuthn.
... QR codes raise MITM attack risks
... one is an out-of-band auth method with FIDO as a component.
Whereas "WebAuthn" prevents phishing and MITM attacks
JeffH: QR codes need to be used carefully. It may be that one uses a QR code to solve the "introduction problem" between one's laptop browser and laptop phone.....but would need to be done very carefully. But the QR code on its own does not provide magic or phishing protection.
John: There are examples of good uses
JeffH: But one flow is vulnerable in a particular way and one is not.
iJ: Can we direct people to good practice?
JeffH: WebAuthn does not create
the capability of using phone as authenticator. But there is
some magic under the hood that may involve various
transports.
... so not just WebAuthn...it's a mashup (complex) of
protocols
... and communications channels to get a desired result.
John: Mostly happens at the CTAP level
JeffH: Because we have the
current deployment (google-specific) we can wave hands and talk
about how that might in the future might work in a multi-vendor
heterogeneous environment...which we're working on
... but these various tools such as bluetooth are
unreliable.
John: Client-initiated stuff is an OpenID standard...that gets conflated because Auth on backchannel is often FIDO
<jeffh> note: "client-initiated backchannel flows" is a term-of-art in the PSD2 world.
benjamin: I think there is
definitely value to sticking to FIDO in the beginning. I think
Ian had an original question a while back on CTAP..that one of
the issues here is that we'd like the browser be able to query
the authenticator and ask "Do you have this credential
iD?"
... I don't see a why of doing that in CTAP
... can we use getAssertion for this or will that be a
problematic API?
John: You can use getAssertion
with an allow list
... are you trying to authenticate or trying to determine
whether you want to create a new credential?
Benjamin: The goal is to do user auth with platform authenticator if credential id matches, otherwise silently fail
John: At the CTAP layer there is potentially a way of doing it. But at the WebAuthn level, WebAuthn specifically produces RPs from doing that.
JeffH: It is something that would
get done at the client platform layer between WebAuthn and
CTAP
... that's why the SPC approach is interesting -it would
specify behavior between the layers
... if the client platform is creative in its approach, it can
do what you're asking
Benjamin: So a cable authenticator could be transferred like any other?
John: It would be a roaming
authenticator at that point.
... all roaming authenticators have the ability (depending on
privacy criteria) to say whether credential is present...but
you don't do that via WebAuthn.
... you would do it via SPC.
Benjamin: Does Windows hello always display UX to the user? Is that part of the protocol?
John: It is a practical
implementation issue
... some authenticators cannot interrogate their credential
stores without a user interaction
... some authenticators need to get a token to decrypt
credentials to find out if they exist...
... if this (SPC) were to become common, it might be possible
to cache credential ids outside of some bounds
... because of how Windows hello is built on TPM, and how
Android is built on their secure storage, and I am pretty sure
with Apple you will see the same issue
... it's not inherent in the spec, it's more of how people have
chosen to implement
... and thus, in the future those implementations might change
in the future
Benjamin: Where do people stand
on the SPC cryptogram, where we use/abuse the challenge as a
signature over transaction data.
... are there positions on whether this is a reasonable and
secure thing to do.
JeffH: You need randomness from
the verifier injected into the challenge that is sent to the
authenticator.
... you can add more stuff to the bundle that gets signed
over
John: If the requestor and the verifier aren't the same party, you need to secure submit the random information securely to the verifier.
JeffH: Something needs to come from the entity and flow all the way back to it to be verified, and it needs to be random-per-flow.
Benjamin: Does the randomness need to be kept secret?
JeffH: Not really.
Benjamin: What about "Unique" v.
"Random"?
... if the verifier uses a monotonic counter, is that
sufficient?
Jeffh: No. If predictable, a MITM
attacker can be an imposter of the requestor/verifier.
... TCP had that problem in the 1990s.
Benjamin: What if we have multiple verifiers?
(Various info needs to be known to all parties)
Benjamin: Can one generate the challenge?
John: If the others trust the randomness of the info created by the party
Ken: You need to prevent against replay attacks.
<jeffh> https://github.com/rsolomakhin/secure-payment-confirmation/blob/master/README.md
https://github.com/rsolomakhin/secure-payment-confirmation/issues
John: Once we have SPC, the payments data can go in client data and not the challenge
<jeffh> https://github.com/rsolomakhin/secure-payment-confirmation/issues?q=is%3Aissue+is%3Aopen+challenge
13 October