<scribe> scribe: Ian
NickTR: FIDO meeting happens in 1.5 hours
Tony: Have people read the FIDO
tx conf paper?
... in the EU Working Group
AdrianHB: I've revised and added
pictures and flow diagrams
... my constraint is not understanding the underlying stack
well enough
... I'd love some help
... in context of a payment request event, could we depend on
webauthn get() at that moment to use the payment request object
(which has structured total, etc.)
... so the input data is scoped (not free text)
... so the system has amount and requesting origin, which can
be displayed by the platform
... Some benefits include reliability of UX, merchant awareness
of the UX, low-friction UX
... and a bunch of motivating factors that were not there a few
years ago (e.g., webauthn ubiquity, mobile payments)
IJ: Any volunteers to read and give feedback by next call?
JeffH: I will take a look at this.
<AdrianHB> issue on the repo are great, thanks
IJ: Should FIDO EU look at this and provide feedback, eg on regulatory conformance?
AdrianHB: One thing I want to point out - when the browser is matching payment handlers given the merchant's request data...one thing that might further reduce friction...if you use WebAuthn to create a new credential, you could provide metadata at that time that says "These are the payment handlers that this can be used for." The browser could treat that credential as a source of information and go fetch payment handler code.
IJ: Next steps?
AdrianHB: I need someone who
knows the WebAuthn stack to tell me if we're barking up the
wrong tree. And we get some feedback from platforms.
... we could also look at what changes would be needed for
different APIs.
... so (1) viability then (2) platform interest and (3) changes
to specs
btidor: Are you saying that the web authentication transaction confirmation is "in scope"
AdrianHB: In the ideal world,
this is tx conf by the platform or authenticator.
... in the case where it's not possible, something "less good"
is that the browser displays the information, and passing the
two back such that the RP trust what the browser
displayed
... we could also explore that; I have not thought about it
deeply enough to know if there are security holes
... my goal is to make the payment experience better (e.g.,
using WebAuthn, Cred Management API, PR API, ...)
... it would be great if we didn't have to depend on the RP
showing UI
... if you can take that away you get consistency, merchants
could be happier, and the burden on the RP is lower
... If you can achieve these things via browser+platform UI...I
just don't know what's possible
btidor: The payments side of me is thinking that the tx conf in the response data would be interesting; so +1
<Zakim> nicktr, you wanted to say that transaction confirmation is explicitly in scope of UAF
NickTR: I'm reading FIDO specs.
Tx confirmation is one of the cornerstone operations in scope
for UAF.
... so my understanding of the proposal is to provide structure
so that tx conf in the payments use case can be accommodated by
auth providers (whether platform or hardware providers)
JeffH: UAF is not widely supported.
Tony: What we'd be looking for
here is 'basic info that needs to be displayed"
... this is something that would be agreed upon about what
would be displayed
AdrianHB: This proposal allows
browsers to overcome free text issue.
... the browser can construct the string themselves
(localizable)
... it would only be available in this special case.
IJ: Are you seeking confirmation of hypothesis about free text?
AdrianHB: I heard it was one
reason for not implementing extensions. Was the the only one?
What were the others?
... I'd like to hear what the other challenges were.
Tony: I think you are also saying that we need to have user verification methods on the authenticators.
AdrianHB: I had not thought about that, really
Tony: That's something to think about. Need to check in the proposal whether it relies on that
btidor: I think user verification would be jurisdiction-dependent.
Tony: My point is that this will have a bearing on which authenticators can be used.
AdrianHB: I think I agree with
Benjamin that there would be regulatory reasons
... in my example I've allowed the FIDO server to specify
that.
10 June