W3C

Joint Task Force WebAuth/Payments

13 Nov 2019

Agenda

Attendees

Present
Ian Jacobs (W3C), Gildas Le Louarn (Linxo), Benjamin Tidor (Stripe), Tomasz Blachowitz (Mastercard), Gerhard Oosthuizen (Entersekt), Tony Nadalin (Microsoft), Ken Buchanan (Google)
Chair
Ian
Scribe
Ian

Contents


<scribe> scribe: Ian

Status update from WebAuthn WG on "TLD+1"

IJ: What is the status of embedded Authentication in WebAuthn WG?

Tony: See this issue:

https://github.com/w3c/webauthn/issues/1336

scribe: we are still looking at how to get around top-level domain issue
... still in discussion, but another issue came up a few weeks ago around hidden iframe
... and not allowing parties to call webauthn from a hidden iframe.

IJ: How does payments industry use those?

Gerhard: 3DS2 has got something called a 3DS method URL that is run at the beginning by the issuer
... and that is supposed to be run in a hidden iframe
... to determine whether the browser is known to the issuer
... we would want at that URL to identify whether WebAuthn WOULD BE possible
... then, we would let the browser know we'd like a visible window to engage with the user for an authentication flow
... so I think the USE of webauthn would be in a visible window (on merchant side or payment handler side)

IJ: what sort of query mechanism is available?

Tony: There is no query mechanism to know whether WebAuthn is supported.

IJ: what about feature detection in JS?

https://developers.google.com/web/updates/2018/03/webauthn-credential-management

Gehard: So I guess we'll have to try to use the window and see what happens (get failure or not)

btidor: What the question about calling WebAuthn in hidden iframe, or creating credential cross-origin?

Tony: It will either be on create credential or get assertion

btidor: It looks like in the ticket, there is a proposal to ban "create credential" only...because you can get an attestation back?

Tony: You can get the same type of info back on get assertion as well
... Mozilla is the one raising the issue
... but the end result is that you won't be able to do anything with either call from hidden iframes

btidor: that makes a lot of sense.
... I think one of the issues we'll run into is, when you click "pay" on the checkout page you're not in the right place to get a signature. You typically want that signature from the issuer, so typically you open a window on the issuer and do web authen.
... I think something we'll run into is a desire to get rid of the click and the second window
... so it would be great to be able to delegate
... but otherwise you can imagine people would do hidden iframe to avoid second click.
... I would call this use case the federated auth use case.

IJ: Please re-explain why is there a second click?

btidor: First click is "pay"; second click is "Auth". We should be looking at ways to combine those
... e.g., how Apple Pay does things today
... a bundled blob is sent back to the merchant that represents the relationship between two parties and the action that has taken place.

Tony: There are two different situations we found:
... or what Mozilla seeks to prevent
... they want to explicitly prohibit webauthn from non-visible cross-origin iframes
... and also create credential from non-visible cross-origin iframes

<kenrb> Sorry to interrupt but can anyone provide a direct link to the WebEx? I am blocked from downloading the calendar entry on my client

<kenrb> This is Ken from Google

Tony: There might be a workaround for btidor's use case.

IJ: What is the tie-in to open id use case?

btidor: I think close to that, but doesn't address enrollment.

Tony: But the enrollment of an authenticator without user knowledge would be dangerous.

btidor: Agreed. Having visible third party enrollment would be useful for payments use cases. Hidden enrollment of authenticators would be dangerous (for any use case)
... but visible third party use case would be good to enable; issuing banks don't have a lot of other Web properties to do enrollment.

IJ: would it be useful for btidor to register use cases on the issue?

Tony: Yes, a brief description would be helpful.

<scribe> ACTION: btidor to add the visible third party enrollment use case to issue 1336.

kenrb: I posted on that issue last week:

https://github.com/w3c/webauthn/issues/1336#issuecomment-551880608

kenrb: There was also a request that a user not be able to make a call to webauthn prior to user gesture on the page

Tony: Went back and forth with Apple on that one
... but we agreed to not do so yet and revisit the issue later ("in due time")

Upcoming face-to-face meetings

Likely WPWG meeting 30-31 March in Dublin

scribe: and WPSIG maybe on 1 April

Upcoming meetings (end of year schedule)

- 27 Nov

- 11 Dec

Summary of Action Items

[NEW] ACTION: btidor to add the visible third party enrollment use case to issue 1336.
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/11/13 18:24:50 $