<nicktr> scribenick: nicktr
ian: Past, Present and Future
structure
... start with Payment Request and moving through Rec
Track
... (and we will talk about that today)
... Secure Payment confirmation update (a little today, more
detail at TPAC)
... then on Day 2 we propose stepping back and looking back at
the overall architecture
... we hope to have a presentation at the TPAC
... and then how does that impact on Secure Remote
Commerce?
<Ian> Proposed SRC through PR API
ian: Day 3 branches out into non-card payment flows, QR codes and Web Authentication
<Ian> https://empsa.org/
ian: EMPSA is trying to create
interoperability in QR. We have also reached out to China Union
Pay.
... we are trying to bring together lots of use cases
... the last day is more open and ecosystem focused. We are
talking to STET/Open Banking/Berlin Group
... we are also talking to The Clearing House about Request to
Pay
... and Coil would like to talk about Web Monetization
... obviously this is still a draft and we welcome further
contributions and suggestions
<Ian> scribenick: Ian
NickTR: Demos really really valuable
<nicktr> registration linkhttps://www.w3.org/2002/09/wbs/35125/TPAC2020/
NickTR: Any demo volunteers?
NickTR: Thanks to everyone who has volunteered to contribute to the FTF meeting so far!
Danyao: Quick update is that we
have shipped the experimental API behind an "origin
trial"
... you can try it out yourself
<danyao> https://groups.google.com/a/chromium.org/g/paymentrequest/c/qDZ6hHtsBPk
Danyao: Experiment should start in October; we'll report back when we have data from the wild
<danyao> https://rsolomakhin.github.io/pr/spc/
[We do the demo]
Danyao: The data signature is for
transaction confirmation
... Sorry that the pilot only working today on one platform
(MacOS) today.
... Rough timeline is after 86 rolls out to stable
(mid-October)
... we should be able to get data before the end of the
year
... we should ask Benjamin for a demo of the flow during
TPAC
nicktr: Are you looking for others partners for experimentation?
Danyao: Thanks for that question. The experimental API is in "origin trial" so partners can reach out to us to partner
NickTR: I am aware of some orgs interested in this
Chris: I want to ask about the
signed data (for transaction confirmation)
... does that string (resulting from user authentication) come
from the issuer?
Danyao: The string that is signed
over contains data that originates from the issuer, but also
the total/currency from the merchant
... the browser adds the origin of the payment request
caller
... and the signed data is the combo of all three data
points
Chris: The amount of the
transaction is a crucial piece of data. They don't want to
authenticate a $5 transaction and then have the cryptogram used
against a $100 authorization
... I think there needs to be in the 3DS flow the data that the
issuer can validate
Danyao: Agreed. The merchant
still needs to submit the total amount to the issuer through
3DS. This signature (of SPC) validates that the USER has seen
this total.
... the issuer therefore has both (1) info from merchant
through 3DS) and (2) signature over what user has seen
IJ: When does the issuer get the SPC signature?
Danyao: Benjamin is still working
that out, but I think it's in the CReq
... but I don't think that's set in stone
AdrianHB: I think that the current proposal is that credential IDs are sent FROM 3DS in ARES and signature is sent TO 3DS in CREQ
Chris: So the issuer kind of trusts the merchant and the browser to display the correct amount
Danyao: Yes, the issuer has to trust the browser
Chris: In the current 3DS flow,
if I were a malicious merchant, I would have to tell the issuer
in the authentication message I were making a transaction for
$100.
... the issuer would be responsible for rendering the page
saying "$100"
... and then the authorization would be $100
... but what if the merchant tells the merchant they are paying
$10, but then sends an auth message to the issuer that it's for
$100. ...
Danyao: On the issuer side, they
would have seen an SPC signature that has $10 in it
... and then see an authorization request for $100.
IJ: Should you sign over both origins? (Top and caller)?
Danyao: Right now we are signing
over top origin
... A topic to discuss during TPAC (possibly in WPSIG) is: what
is the format of the cryptogram
NickTR: And includes Payment
Method Identifiers
... We may need to make some changes to specs to align with
implementations
<nicktr> scribenick: nicktr
ian: PR has been deployed for a
couple of years now
... interoperability between Chromium and Safari is nearly
there
... about a year ago, we said we would wait for some time
before pushing on
... but now attention has moved on to SPC, but we are beginning
to get some new feature requests
... Marcos has done some work to figure out what needs to be
done (thanks, BTW, to Marcos for his work)
... Four items: 1) dropping 'allowpayment' request attribute in
favor of allow which is a more generally available
attribute
... 2) Merchant Validation Event (which ApplePay uses, but
there are no other implementations); then two issues requiring
more discussion
... 3) what to do about hasEnrolledInstrument (hEI)? There is a
proposal to remove from v1.0 and add back in v1.1 (and
therefore essentially considered a "next version
feature")
... 4) Dealing with the privacy issue that Sam Weiler raised
about address information
... we could return redacted address, we could allow the
merchant to provide input to change the redact list, or we
could make it "chatty" and incremental going back and
forth
... A year ago, the browser vendors said that they wanted
customer demand, but we've not seen that demand (for the
incremental feature)
... so we are a bit stuck - the feature hasn't been
implemented, but the privacy issue hasn't been resolved
... it's worth remembering that this issue was a formal
objection in the last CfC
... so we do need to think about this ahead of a new CfC
... so we really want to hear from group members
... how should we move forward?
<Ian> NickTR: Thanks, Ian. Really good work done in trying to move PR API to Recommendation. really grateful to Marcos and editors
<Ian> ...particularly on this question of incremental request for addresses, we need input from the group
<Ian> 1 October
<benoit> thanks!