WPWG Code-a-Thon

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

Faster Checkout

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

QR Code

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

https://docs.google.com/document/d/12dXArNEw5UTQvvhJmNl0zBIOt4E_YqHbXesaw4RIF1I/edit#heading=h.gjdgxs

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

MInimal UI

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.

https://webauthn.guide/

<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

Expanding minimal UI to include other forms of authentication

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

Other observations?

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

Mobile Money

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

Any other updates?

[Adjourned for today!]