Agenda · 26 May minutes · 28 May minutes
Everyone should look at the subject for the chat rooms of individual conversations
====
Authentic
Minimal UI
Mobile MOney
Faster Checkout
QR Code
Card on File
Erhard: Nothing specifically on
the mechanism itself, however, Danyao has given us some ideas
about prototyping consent model
... we're going to add consent inside the payment handler to
demo how that would typically work
IJ: Where would consent go?
Arno: We would render consent
prior to payment handler installation.
... this could similarly be shown in the QR payment,
specifically for JIT installation
Arno: We had a chat with a
merchant introduced to us by Ian
... it was a short meeting but we are understanding how we
could collaborate.
IJ: Any obstacles? Key learnings?
Erhard: Anything that impacts the browser code would not be do-able in a day or two, so we'll have to mock it up in HTML. The consent screen would thus not be a real one from the browser.
Danyao: In previous conversations we've chatted about friction of an installation ceremony. So I'm happy to have this mockup and see from people whether it would be a good UX that the browser can then implement.
IJ: Next step would be "validate this mock UX as part of input to PH installation ceremony discussion"
Danyao: I'll want to hear from other folks about this.
Arno: the "starter kit" was really an excellent resource
maxlg++
Arno: The time zone challenge is
an issue for this sort of event, but that's to be
expected
... Tomorrow we'll have the consent part of the demo
integrated
... we'll have a conversation about "how this would impact
either PR API or registration ceremony in the real world"
<erhard> Confirmation mockup built using html: https://www.icloud.com/iclouddrive/008J36MBIkcNVLBBYtDFudKZw#confirm
IJ: Any updates?
Anne: We are adapting our
existing demo
... our use case is similar to the one presented by Entersekt
(the faster payment demo)
... the user connects to the user's bank.
... the bank proposes to install a payment app to use a card
for shopping
... In the existing demo: when checking out, the user can use
the payment app and is redirected to the bank site to select a
card for payment
... but the redirect creates friction (since the user has to
log into the bank site, choose a card, etc.)
... what we wanted to do was try the same use case with the
"minimal UI" functionality
... we have implemented some parts of the code provided by
Rouslan
... we have identified some SW issues and should have it solved
by tomorrow
... the other important thing is that we have to rely on Strong
Authentication to use the card
... and the minimal UI user experience does not involve a
remote relying party
Danyao: I was wondering if we could take a similar approach as Entersekt is taking: let's mock up the user journey, and that will help us prioritize making it available in the browser
Anne: +1
Danyao: I have some slides on how to connect minimal UI to WebAuthn
agenda Minimal UI and the option to leave it for a full payment app experience.
<arnovandermerwe> +queue
<arnovandermerwe> I will let danyao finish the FIDO explanation. No hurry
credential management API used to store user identity (draft idea)
Danyao: another option would be "resident keys"
(IJ notes that some authenticators do not support resident keys"
arno: Would call to CM API happen in the SW or in the Web view?
Danyao: Great question. Some
changes would be needed
... we are proposing a modification where the SW tells the
browser "I want to use WebAuthn" and the SW passes data to the
browser. The Browser calls WebAuthn on behalf of the RP.
... the browser "guarantees" that the user is seeing the
experience of the minimal UI
... the browser would hand the auth results to the SW (via an
event that would need to be added to PH)
<Zakim> Ian, you wanted to ask whether this should be used outside of Payment Apps
IJ: Should this experience be available from JS in the merchant page (instead of merchant app)?
Danyao: We want the use to know
who the RP is.
... today browsers only allow WebAuthn in the top-level browser
context
... (but in WebAuthn Level 2 it will be possible from cross
origin iframe)
... in minimal UI flow, the browser overlay make clear that the
user is interacting with a payment handler (not the merchant
site).
... in the case you describe where there is webauthn in a
merchant site, if the merchant is the RP, there's no
problem.
... but if there's an invisible iframe in the merchant page,
and calls webauthn with minimal there might be confusion
... the only other use case I think could work is federated
log-in
... it's a similar issue as payments - the ID provider is not
the same party that the user is currently interacting with
(e.g., the merchant)
... so in that case it could also make sense to allow a
webauthn call to the ID provider
... we are interested in hearing more cases
... for now we know about payments and so makes sense to extend
PH API
IJ: Could minimal UI be a
framework to allow other auth types?
... e.g., QR code
... How could communications end in case where browser renders
QR code?
Erhard: Phone sends data to server; payment app talks to server and decides when satisfied.
IJ: Where does QR code get rendered?
Erhard: Data goes to browser, which renders the QR code
IJ: Would that be better than image from PH?
Danyao: Why is it critical to render the QR code natively?
Erhard: Good question.
IJ: less work in UX by the PH
<clinton> +q
IJ: Another piece of rationale might be dynamic linking
clinton: QR code useful in
decoupled systems
... from a flow perspective it would look the same
... it's not about security as much as having a comms
channel
Danyao: I will send link to slides
Rouslan: I looked into seeing how
easy it would be to integrate biometric into chrome.
... There are several services on an Android phone to display
the biometric interface
... there's an Android level API that people should be
using
... using that API requires some library updates and other API
calls to invoke it
Erhard: What API do you call to use Android scanner if not WebAuthn?
Rouslan: Still working on
that
... discussion is on whether to enable WebAuthn from a SW
... maybe only in known limited contexts
Danyao: It is not clear to me we
will make Android biometric API available to Web
developers
... so instead people might end up using WebAuthn and it gets
translated to platform-specific authenticators
https://codelabs.developers.google.com/codelabs/webauthn-reauth/
AdrianHB: Viji and I chatted
about the GSMA APIs and how they work.
... we have a couple of use cases we'd like to look at (and who
would fulfill different roles)
... my plan is to write up some documentation, then update the
draft spec started long ago
https://raw.githack.com/ianbjacobs/webpayments/mobilemoney/proposals/mobilemoney.html
scribe: and use GSMA simulators
IJ: What are the 2 use cases?
AdrianHB: First one is someone
with a mobile money account. They are on their phone. They will
likely have an app from the mobile money provider, and that
would be the payment handler.
... eg., Android phone, native android app registered as a
payment app
... we think PMIs would be mobile platform specific
... as a reflection of current mobile money ecosystem.
... so merchant would specify a payment method and which
operator they support. And if user chooses that the native app
is invoked.
... the app submits the transaction and returns a proof of
payment.
Use case two: Similar flow, but instead of submitting a proof of payment, the app would return info about the user to the merchant who would initiate payment.
scribe: and then in a side channel the user would authorize the payment
IJ: What about third use case where user authenticates to app and that's returned to merchant?
AdrianHB: The GSMA Api doesn't support that today
Viji: A merchant can pass an authentication code to a user, and that would allow the payment app to preauthorize the transaction.
AdrianHB: Ok, so the payment app
does pre-auth and hands to the merchant.
... I like that flow the most.
Viji: There's no universal mobile
money registration
... the only thing that the payment handler would need to do is
merchant validation
AdrianHB: Another way to manage that is to have one PMI per operator.
Viji: The merchant needs to be onboarded with a mobile money operator
IJ: Is the validation event useful here?
AdrianHB: I'll look at that but
it may not be necessary
... i think it's sufficient for now for the merchant to assert
what platforms its onboarded to
Next step: Documentation from AHB and possibly some mock-ups or something
AdrianHB: We can try to wire together a working demo
[Adjourned for today!]