See material from Jonathan Grossar with edits from Ian
tomasz: Goal is to limit the number of authentication events (friction) during the checkout flow
IJ: We will continue to evolve
these to look like use cases.
... Any questions or additions?
... Any obstacles to the last one in particular (in
practice)?
tomasz: The last flow (delegation
to issuer) might involve changes to the protocol.
... I understand that Google has put forward a proposal to do
this
... would this require any out-of-band agreement between
merchant and issuer?
Ken: I think it would require
that there be some communication between merchant and issuer,
that the issuer would expose an interface that the merchant
would access.
... the proposal that I saw involved the issuer providing an
endpoint (at a URL)...
... a description of the end point would go from merchant to
client and the client would use it to authenticate.
btidor: What would the endpoint do?
Ken: The client will access that and then there will be webauthn flow between issuer and client
btidor: I am interested in this
last case...I think it has the best enrollment
properties.
... enroll once, use anywhere.
... we are also interested in the use case where the issuer
does not have to expose a public endpoint.
... perhaps the forwarding can take place over a backend
protocol instead of a new public endpoint.
tomasz: When we looked into this use case, 3DS 2 seems to be a suitable protocol for passing this information to the issuer.
btidor: My hope would be to send
it in the AREQ (of 3DS2) and get frictionless flow.
... but I wonder if we can move away from method URL model
which has been problematic in the past.
Ken: One issue is that this goes
a bit against the webauthn security model.
... this introduces a risk of phishing
... something would have to be built in to allow delegation
explicitly, and that the merchant is authorized to ask the
client to authenticate against the issuer.
btidor: Definitely.
... could we expose this in the customer UI as well?
... problems we've had have involved explaining merchant-issuer
relationship to user
... if user agents could offer UX to help explain that (in an
unphishable way) that could help clear up what's going
on.
... getting user gestures have not seemed like the best user
experiences.
... Keeping (1) no redirect and (2) not requiring the customer
to click twice ... so keeping at a single user gesture is
desirable.
Ken: Does an iframe need to be
there, or can the merchant and issuer comms happen entirely out
of band?
... does the client need to be talking directly to the issuer
in any way?
btidor: I think we'd like to move away from iframes. Ideally the merchant site can just produce a payload describing what the interaction should look like and it should "just run from there."
tomasz: Yes and no
... we want to move away from iframes, but in Web Authn there
is also a change to enable webauthn from within an iframe.
Ken: Payments use cases are driving that feature request.
Editor's notes: Benjamin expects to provide some text for the wiki with further detail about the scenario involving backend communications rather than a public issuer endpoint. It was also observed that what is currently in the wiki does not constitute use cases, but rather some flow descriptions of current solutions. Ian expect to continue to work with participants to evolve the material into use cases.
8 January 2020