<scribe> Scribe: Ian
Next steps for transaction confirmation
AdrianHB: The proposal I wrote up
needs input from WebAuthn folks
... can you get more certainty about what the user was shown
because it was shown by the browser and not the web site?
... there's a concept of "software display"
John: Current state of
transaction confirmation: no implementations currently
... Browsers have indicated that they are leery of anything
that would allow the RP to display arbitrary text in browser
chrome
... there might be some support for limiting that to part of a
transaction (which might be good for payments but not
contracts)
... so the question for this forum is: what would be the
minimum amount that would need to be displayed? And how could
that data be collected via APIs?
... another topic is localization: how can the beneficiary and
total involve standard phrasing that could be localized?
AdrianHB: Transaction
confirmation is a FIDO concept that depends on an authenticator
having a display.
... my assumption up to now is that the browser itself doesn't
count.
... so we are looking for middle ground: browser displays and
browser can sign. Does that fit into a security framework
that's verifiable?
John: The authenticator can sign
over what the browser or platform says it displays
... e.g., on Windows, it's the OS operating ("ring 1") so it's
pretty secure and is not subject to attack by JS
AdrianHB: So, in this potential
future state, the relying party will have an assertion that was generated
by WebAuthn with some transaction text that they trust the
platform to have displayed to the user
... so authenticator and platform share trust
John: There was handwavy text in
the FIDO security reqs that you could have an external thing
display the transaction confirmation
... but there was no description about how to do that.
AdrianHB: My second question is: it seems like one reason that browsers were reluctant was "free text." But if we can get input from PR API, that seems like it would be an improvement.
JeffH: "Maybe"
... it would need a concrete proposal.
... and there are many facets to Chrome. This notion may or may
not make it through all the necessary reviews
John: Chrome on android and
desktop may have differing views, and same with other platforms
and browsers
... The first thing to do is to show demand.
... E.g., if google pay is interested
Ian: What is a regulatory requirement not sufficient?
John: government mandates do not always bear fruit
IJ: Has google pay expressed interest in this?
John: I think google pay is
interested in Dirk's shared credential proposal
... Transaction confirmation may not be a problem for PISPs; it
may be more of a merchant problem.
<Zakim> AdrianHB, you wanted to mention some interest I am aware of from Google Pay
AdrianHB: I wanted to mention
that Coil is doing some work around mobile money, largely
driven by Google pay. I confirm interest in Dirk's proposal. I
think that I have also observed interest in transaction
confirmation
... I think there may be some misconception about what webauthn
gives you...and that there's no guarantee that what you see is
what you sign.
John: That might be an angle for
education.
... If the PISP (e.g., Google pay) is trusted to not deceive
the user and bank, does transaction confirmation add
anything?
AdrianHB: I agree that's a good
question
... most of the parties collecting attestations are trusted
anyway
... so I think the value of the trusted confirmation is not
high
John: It's where you have the merchant doing it directly that your confidence goes away
<Zakim> Ian, you wanted to ask about Stripe
Ian: How does Stripe feel about this?
[Recap of proposal: authenticator signs something from the request data]
btidor: This is not about hardware trusted rootkit
John: Maybe in some cases you can
determine that (e.g., Windows)
... you won't get much deployment with secure hardware.
... unlikely that people will carry around reliable hardware
with them everywhere
... so might be the browser or some piece of the platform that
is displaying the information
... there will be different levels of security depending on
platform
... the payment code might interact with webauthn and some
signed part of the payment API could go into the ....
AdrianHB: I propose that the way
you invoke WebAuthn would be through PR API
... so there's interaction between PR API and WebAuthn
... but not through get()
... the user interaction with the browser would be to see
transaction details displayed by the browser, interact with
authenticator, and the response that comes back to PR API is
payment details AND an assertion
btidor: So the browser wraps WebAuthn in a payments experience
AdrianHB: The payments API
controls input to webauthn algorithms
... the webauthn output would contain an assertion that says
"Here's a signature, and the challenge contains these details
from PR API directly, so I can confirm that the display was
browser or platform chrome"
John: I would not put in the challenge, but some additional param somewhere
btidor: Sounds reasonable to have
a field that other parts of the browser can control but regular
JS cannot set.
... Right now there's a lot of trust in the merchant, even
small merchants
... having trust hardware based confirmation is not a silver
bullet, even if rooted in hardware (merchants could, e.g.,
never ship something to the user)
... I do think that there is value in having some assertion
about what was shown to the user would help with a number of
administrative issues
... today there's a lot of prescriptive things about the
merchant having the page a certain way
... i think the primary benefit would be in the UX linking the
authentication with the act of payment and putting them in the
same browser UX
... I would say that basing it on a hardware API isn't
necessary
... it would be neat to have an incremental path...e.g.,
browser UI for now and, if the user has an authenticator, fall
back to some system thing
... I also think the card networks would also be interested
AdrianHB: I will take my email and put in a doc and prepare for tomorrow's call of the WPSIG.
29 April