nicktr: Welcome all, and thanks
for making time in logistically challenging time zones
... (Suggested by Lawrence) let's look at priorities as we
start the year
<AdrianHB> Huge thanks to Marcos (in his absence). He is carrying us over the line on his shoulders
NickTR: we had a good 2018. Lots
of new participation, great TPAC 2018 meeting, and in particular I
was excited to see momentum around payment handlers,
... in 2019:
* Need to get PR API to Recommendation
... Ian will review this
shortly
... will go back to CR, then I hope quickly to PR
... as a Working Group, thank you for weighing in on calls for
consensus
... it's important for us as a group that people be actively
engaged in review of the spec and active signaling of
approval
... any help in terms of testing or specification review is
also important and will improve the reuslts
... The next priority will be
around Secure Remote Commerce and the relationship to PR
API
... I'm getting a lot of questions from people about SRC and
its relationship
... I published a blog in December about this and have also
seen reports from others I respect who imagine implementations
completely different
... I'm grateful to the task force that is working on
this
... also, the relationship between EMVCo, W3C, FIDO is
important; more on the proposed IG shortly
... Next priority would be payment handler support
... Chrome is doing a stellar job
... I was doing a demo yesterday using the Worldpay
prototype
... it demonstrates using a payment handler to do open
banking.
... it also includes Web Authentication. Yesterday I
demonstrated it on my phone
... when I did the demo I was asked to use my phone tap AND IT
JUST WORKED
... I had never tested it but because it was coded against the
standards it just worked
... handlers are really important as an extension point
IJ: I would add "credit transfer" as a priority, e.g., in Europe
NickTR: Any questions?
<AdrianHB> +1
<vkuntz> +1 for credit transfer
<Ian> Ian's notes on PR API update
Ian: I have checked in with Marcos on the state of Payment Request
...In April last year, we identified a list of issues we wanted to resolve for V1
...since then there has been a lot of specification, implementation, and alignment between the browsers
...one particular feature we realised we did not have any implementations for was RegionCode
...we will circulate the decision for that Call For Consensus shortly after this call
Ian: secondly we have clarified the semantics of canMakePayments
Rouslan: we have started working on this. It's more complicated than we expected
...our primary concern around feature detection
...at the same time we are changing the query quota mechanism
...and we are having to solve with many orchestrated payment handlers in Chrome
Ian: our expectation was that we would have canMakePayment in V1 with browsers having already starting experimentation with hasEnrolledInstrument
Ian: do you know if implementations have already implemented the agreed-to semantics for canMakePayment?
Rouslan: Apple already had the two methods. I am not sure about Mozilla.
Ian: we will take it to email
Ian Here is the CR issues list
...there is a PR for each issue
...most of the PRs have had review
...we are awaiting final review from Domenic
Ian: so in a couple of weeks, we should have an updated spec reflecting all the change since Singapore
...we have already talked about RegionCode
...the rest are API management
Ian: next steps
...we are currently at Candidate Recommendation
...we need to go back through Candidate recommendation due to substantive changes to the specification (this is a Process requirement).
...but we need to get wide review from privacy and security before we ask the Director to return us to Candidate Recommendation.
...I hope that would take 4-6 weeks
<Ian> https://w3c.github.io/test-results/payment-request/all.html
Ian: to get out of CR, we need to have 2 implementations of each feature
...the test suite is how we demonstrate this
...we use an implementation report to show that we are satisfying that process requirement
<Ian> https://w3c.github.io/test-results/payment-request/less-than-2.html
Ian: we need to address the requirement for at least 2 implementations
...we need to fix bad tests
...and get the page to green
Ian: once we have done that, we can go to "proposed recommendation" which is the last step before Recommendation during which we finalize support and do communications planning.
<Ian> Timeline tool
Ian: we have automated tooling for generating a "best case" time line
...I have plugged in 19th February as a CR date for payment request
...this gives us a happy path date of May 7th
Ian: that's where we are at
<Ian> NickTR: Thanks Ian, and for showing us the tools. I thanked Marcos this week for his work.
<Ian> Ian's presentation to Open Banking UK workshop yesterday
Ian: I spoke at a workshop with the Open Banking initiative in London yesterday which was a follow up action to TPAC in Lyon
...permission to invite the working group only arrived a week before the meeting; sorry about that.
...The slides re-use slides from Herve Robache's presentation last TPAC that I worked with him on.
...I think it's important to make payment methods available
nicktr: The workshop was really
positive...props to Ian on that presentation (remote)
... it worked out despite Ian being remote.
... I'd say there was interest
... I had an animated conversation afterwards with
PSPs-as-PISPs.
... there were really good engaged questions about the role of
the PISP in authentication
... and how that fit into this PR API ecosystem
... I think we communicated to the group that this is not a
competing scheme...but rather a mechanism that should make it
easier to implement payment methods on the web
... and allow people to use their (open banking) APIs
... so I thought it was a successful meeting...they meet every
2 weeks
... I hope that we get some prototypes and then go back to them
in a couple of month's time
IJ: Two questions I heard:
* If the PISP has distributed the payment handler, but the ASPSP is authenticating the user, how would delegation work from the payment handler to the ASPSP? Would that be permitted?
* Some “classical” PISPs don’t have a concept of a user account. How would that work with Payment Request?
NickTR: For the first point, we will see innovation
IJ: Next steps?
... prototyping ideally
Observations about SRC and Payment Request API
Ian: here is an update
...this task force has been building a shared understanding of SRC fitting with Payment Request
...we are getting closer to a consensus understanding
...payment request is one solution to do SRC
...we have generated some diagrams which I would encourage you to review
Ian: they cover registration
...metadata
...payment
Ian: there will be numerous ways to enrol
...SRC would like to be a cloud repository of the cards that you have
...so you (as a cardholder) would have access to that information from multiple locations
...and the card data should be (but is not required to be) tokenised
Ian: enrolment is "here is a card I would like to use"
...in SRC
...could be typed in via (for example) a handler
...or pre-provisioned by your issuer
Lawrence:: is SRC a third party sitting in between? Does the consumer then go to SRC subsequently?
Ian: I am getting to that when we talk about the transaction; for the moment this is just about enrolment
...payment handler is one example of how cards get entered into an SRC system
Ian: the second diagram is metadata registration
...metadata like card art and last four digits
Ian: the third line is the handler in the browser
...so the browser might be able to get metadata via the SRC customer profile request
...actually any payment handler could work that way
Ian: to summarise, once the card is registered, you have to tell the browser
Ian: third diagram shows one possible transaction flow
Ian: I added a note to browser vendors about showing instrument level data in the sheet (not just handler-level information)
...I believe the spec supports that but implementations don't currently do that
Lawrence:: do we have a view of the benefits of implementing this?
Ian: this isn't yet a judgement call on the merits of SRC _or_ Payment request. Right now, it's analysis to say "it's feasible, here's a possible implementation"
<Zakim> nicktr, you wanted to say payment handler is not (IMO) necessarily playing the role of DCF
...the SRC folk can articulate the benefits
NickTR: These diagrams show PH as DCF; that's one approach
..but another approach might be that the payment handler is the SRC-I
...in that scenario the flows change a bit
...but either way I think you can implement SRC with PR API
Lawrence:: I recognize this is about "how"
...but there are other questions about "why"
...from our perspective, to invest our time in "how" we need to understand the pros and cons
...to Ian's point, it would be good to get the audience on the call to get answers to that
NickTR: We've definitely focused so far on feasibility
...I think it's up to Members to make the business case for themselves
..we might have a breakout session on that at our FTF meeting, for example
..but I don't think this WG will produce an economic critique
Ian: Let's note LC's question for future discussion
NickTR +1
https://www.w3.org/SecurePay/charter
Ian: you may already reviewed the charter
...we have extended the deadline
...because we hadn't had enough support
...does anyone understand why we haven't had more review giving that WPWG is the biggest working group in w3c?
<Ian> AdrianHB: I submitted review today; some internal discussion whether to abstain or be expressive
<Ian> ...we think this could be done in the WG
<AdrianHB> Emphasis that this is Coil's view not Adrian as Chair of WG
<Ian> Ian: Now hotel info available!
<Ian> 2-3 April 2019
<Ian> Placeholder agenda
<Ian> 7 February