W3C

- DRAFT -

SV_MEETING_TITLE

21 Jun 2018

Attendees

Present
DannyRussell, Liam, Olivier, JonathanG, JohnFontana, Denis, Tony, adrianhb
Regrets
DaveTonge, zkoch
Chair
SV_MEETING_CHAIR
Scribe
Ian

Contents


hi there

<gildas> can't connect audio at that time

introductions

Worldpay Demo

<scribe> ACTION: Ian to find out what feature detection to do for payment_handler

<gildas> ont sure I will be able to join

<gildas> not

ok

<gildas> very very sorry

no worries. Any chance you can do a screencast yourself and share?

Tony: I would agree Hello looks the best...would be great if the polyfill could work
... we can use different auth technologies under the covers

danny_russell: I like hello since does facial recognition but falls back to pin
... I've kept 2-factor for USB key

John: Should you get updated keys?
... support for CTAP?

danny_russell: The key works out of the box wonderfully, we debated whether PWD necessary

IJ: Will there be PIN?

John: Yes

IJ: Which polyfill, Tony, would you be interested in?

danny_russell: digital bazaar's

IJ: Would this work in the ecosystem in practice (e.g., given regulation around storage of credentials)?

Tony: I was wondering the same questions as Ian
... Have you implemented other flows besides redirect?
... embedded flow?

Danny: OpenBanking is all about the redirect
... I've also looked at the berlin group api
... starling has a long-running auth
... because I'm a trusted beneficiary simpler

OlivierM: You need to be able to fall back to PIN if biometric doesn't work

danny_russell: If we get an error, we fall back to SMS

OlivierM: Regarding Yubico, how do you imagine bringing 2FA in solutions.
... will keys support biometrics?

John: We have not discounted biometric.

Tony: You can also do PIN with Yubico devices

Worldline

Olivier: We added a message to let people know they have registered a payment handler. We found it disturbing to have no feedback.
... in our demo we use a hardware token
... so we have a process of enrollment shown in the demo
... step one (enrollment) took place on the banking web site
... step two is the transaction
... the demo shows password then hardware token
... we combine PR API, PH API, and WebAuthN

IJ: any hurdles you encountered?

Olivier: No, not really

TonY: Which browsers?

Olivier: Just chrome

danny_russell: Like the demo!
... I found the web authn standard difficult to follow
... I needed MS's samples
... and FF's samples
... and google's samples
... I had to reverse engineer from the sample code

Tony: Good feedback. We are getting ready to go to PR.

danny_russell: A sequence diagram would have helped me
... those samples were really helpful to debug
... webauthn is about splitting bit arrays, some are base64 encoded, etc.
... so I needed to use debugging side-by-side etc

Olivier: I chatted with Liam who is muted due to World Cup ;)
... Liam agrees that without sample code would have been difficult

Tony: Good feedback for me and John

IJ: what other payment methods are you looking to experiment with?

Olivier: implementing wallets (paylib)
... also wallets for belgium banks
... tokenization and encryption
... in this demo we wanted to illustrated how it would work for the bank to create a payment handler
... how you enroll the customer as well
... the first time this window pops up for users it can surprise users
... want to avoid scaring pop-ups and surprising redirects

danny_russell: I think the firefox messaging around web auth in the message bar was effective

IJ: Chrome 68 will have payment handler and webauthn

danny_russell: We have invoked basic card on Edge as well.

adrianhb: Does chrome payment handler support include basic-card?

Ian: I think so (based on Rouslan comment at some point)

adrianhb: handlers can do webauthn and return a virtual card

tony: In your webauthn demos you were pre-registered.

adrianhb: The use case I'm interested in is the bank does auth and the bank is also issuer of a payment handler

tony: +1

Next steps

Tony: I would like to understand some of the comments in more detail on spec usability
... all other comments on the APIs welcome (as we are in CR)
... e.g., error conditions, etc.
... also want to look more into Edge demo to be able to do the web authn demo
... possibly using polyfill

danny_russell: I can force it with "If Edge"

Tony: +1

IJ: I will look into feature detection for payment handler
... I will also work on getting the video together

AdrianHB: It would be great (with chair hat on) for people to publicize what can be done with these APIs

Summary of Action Items

[NEW] ACTION: Ian to find out what feature detection to do for payment_handler
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/21 15:56:17 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/the director/the redirect/
Present: DannyRussell Liam Olivier JonathanG JohnFontana Denis Tony adrianhb
Regrets: DaveTonge zkoch
No ScribeNick specified.  Guessing ScribeNick: Ian
Inferring Scribes: Ian

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: ian

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]