<scribe> Scribe: Ian
Ian: As of right now, seven organizations supported the charter and there were no objections.
<manu> Ian: In response to CfC, we have 7 orgs supporting draft charter, no objections.
<manu> Ian: We will announce decision shortly after call, we are requesting member review of charter.
<manu> Ian: I'll send a request to the management team, weekly review on Wednesday, expect them to discuss on that call. Any questions.
<manu> manu: I'm swamped, haven't been able to review to ensure it reflect discussion at W3C TPAC...
NickTR: Is "7" a good number or a weak signal?
<manu> NickTR: Is 7 out of 50+ orgs strong or weak signal?
<manu> Ian: Numerically, a weak signal... in terms of substantive support, we see lots of activity by participants. So number of people that came to WG face to face are good.
<manu> Ian: It's still worth asking people on why they didn't respond to the CfC. It might be worth hearing them...
<manu> NickTR: They might be a bit desensitized to CfCs.
NickTR: Web Auth Chairs asked us
for review of Web Authentication as they prepare for CR
... in their charter WPWG is called out as a liaison
<nicktr> https://www.w3.org/TR/webauthn/
<manu> Ian: We could provide various types of responses - no response (we probably don't want to do that, we could say we support strong auth for the web -- called out in regulations that it's required, happy for open standard, high level statement of support, not detailed review...
<manu> Ian: Then next level is detailed review of spec - anyone here, from WPWG, interested in detailed review and possibly sending comments?
manu: I am not sure anyone is using Web Authn in their implementations (e.g., payment apps)
<AdrianHB> I have reviewed in personal interest capacity. Have nothing to add specifically wrt to payments
<AdrianHB> +1 that it will be mostly relevant to payment handler implementations
manu: so I'm not sure that this group can form a strong position; I'm in support of Ian's "middle option"
Ken: I agree we should respond in
some capacity. I'm happy to see whether someone from Amex
wishes to do a review.
... If I find someone to do a review, then I would label it as
Amex support
... I think other orgs could also do similar evaluations
NickTR: I've asked some of my
Worldpay colleagues if they could have a look; not sure yet
whether we can do a detailed review but want to ensure more
than 1 person is familiar with it.
... also, for framing - this is FIDO-based auth and Worldpay
has some perspective on that.
... in a payment app...though not specifically Web Authn
Ken: EU regulatory environment and FIDO
NickTR: Consistency yes; though we are not a lobby group
Ken: Education useful
... especially in the formative phases
NickTR: Synthesizing what I"m hearing:
- some interest from some participants in more detailed review
- review would be more meaningful with implementation experience
- could formulate a response to the chairs that includes the "middle" response and that we have expressions of interest but not a lot of implementation experience yet
IJ: I think that Mastercard MAY have implementation experience.
<manu> Ian: Don't know how critical it is to review this from a Web Payments perspective, but you never know upon review, you might find something. Glad some people have asked whether their colleagues are willing to do that.
<manu> Ian: Before answering specifically, I think we should check with Mastercard.
<scribe> ACTION: NickTR to ask Mastercard if they have WebAuthN implementation experience in payment app
<trackbot> Created ACTION-72 - Ask mastercard if they have webauthn implementation experience in payment app [on Nick Telford-Reed - due 2017-12-21].
IJ: I like the framing of a reply: (1) support the effort and here's why (2) we don't have a lot of implementation experience yet (3) some people seeking volunteers to do reviews and we'll let you know.
+1 to nick drafting
<AdrianHB> +1
<scribe> ACTION: NickTR to draft response to Web Auth WG chairs and circulate among WPWG chairs before sending.
<trackbot> Created ACTION-73 - Draft response to web auth wg chairs and circulate among wpwg chairs before sending. [on Nick Telford-Reed - due 2017-12-21].
Encryption and Signature proposals
[IJ intros the proposal]
<Zakim> manu, you wanted to speak to signature mechanism and the obvious security vulnerabilities I see.
manu: +1 to the encryption
proposal.
... the approach looks sound.
... we don't want to mix signatures with encryption.
... the second proposal (signatures) has an anti-pattern in
it.
... if you are using JOSE JWS you double-encode data
... developers may not know that they need to decode data and
throw out clear text data
... developers end up doing the wrong thing, using the unsigned
bits
... we need to be much more careful with the signature
bits
... i'd prefer to split the two
IJ: What is the right way to do the signature stuff in your view?
Manu: We should get input on
that.
... there are other signature schemes.
... We could invent our own signature scheme.
... we could use JOSE and JWT and that affects how we express
data in the payment request message
... we probably can't put it in a dataSecurity field and have
other unsigned data
... we also have JSON-LD signatures..
... we should discuss all three options
... if you are using JWT you should have the browser "throw" if
there is unsigned data.
... since developers might use unsigned data.
====
unsignedData includes the request fields that are not signed. This list should be mutually exclusive of signedData.
====
IJ: Is that in the direction of what you had in mind...they are mutually exclusive.
Manu: signedData is a dangerous field...if developer puts information there in clear text it is an attack vector.
NickTR: It's great to get feedback. What I'm hearing is that there are two proposals and that the first one seems solid; and you have concerns about the second.
<Zakim> AdrianHB, you wanted to suggest "right way" to sign JSON is a contentious topic even among security experts
AdrianHB: I think I largely agree
with Manu. This is a contentious subject even among security
experts.
... there are groups within IETF who are trying to solve
similar problems as we are, and there are differing views
... I think there are standards we can lean on to not reinvent
the wheel
... my proposed next step is that we propose *something* and
keep it limited.
... and then we get a security review.
<Zakim> manu, you wanted to suggests RyanSleevi, that Chain dude whose name I can't remember, and the WebAuthN folks.
Manu: Ryan Sleevi, Tony Arcieri,
John Bradley, Mike Jones
... Jeff Hodges
<manu> Ian: We also have a Security IG - give them a heads-up on it.
Manu: I suggest any request come
from Ian and the chairs
... I can provide some emails
<scribe> ACTION: NickTR to work with AdrianHB and Ian on outreach to people regarding the encryption and signature proposal to get feedback, especially around signatures
<trackbot> Created ACTION-74 - Work with adrianhb and ian on outreach to people regarding the encryption and signature proposal to get feedback, especially around signatures [on Nick Telford-Reed - due 2017-12-21].
<AdrianHB> Note for the minutes: I suggest that our proposed signature mechanism has no allowance for clear text JSON. i.e. Only the base64 encoded payload is allowed (I think this is what Manu was also saying)
<manu> Ian: Background - two weeks ago we talked about an issue in payment handler land - where we were trying to figure out what to do with payment handler ordering -- the Editors brought forward proposal to delete the section 4.
<manu> Ian: The rationale for the deletion had to do with remenant text from the days where we were writing down thoughts on what we were thinking - we also, among the editors, looked at requirements and thought that we didn't need to say any of them... when we presented that, we got push back from Ken. CapOne and Amex requested additional review time. CapOne came back and said they were ok with the deletion.
https://github.com/w3c/payment-handler/pull/242
<manu> Ian: Manu took a suggestion to do a PR, he moved an entire block, I thought we were focusing on a few sentences. I did a counter proposal, which is where discussion continues.
<manu> Ian: We had three PRs - delete whole section, move whole section, summarize. Two of the three have been closed and we are focused on my pull request (242).
https://github.com/w3c/payment-handler/pull/242/files
<manu> Ian: We came to ground on two sentences that have support from Marcos, Ian, and Ken on two sentences proposed in a new section after security considerations.
<manu> Ian: We came to ground on two sentences... final sentence saying UX left to implementers...
https://github.com/w3c/payment-handler/pull/242#issuecomment-350477408
<manu> Ian: At that point, Manu came back semi objecting to moving forward w/ PR... I disagree with some of the text... that's where we are.
<manu> https://github.com/w3c/payment-handler/pull/242#issuecomment-351599849
Manu: I suggested some
alternative spec text
... at the bottom of that comment on GitHub
... the main differences have to do with payment instrument
ordering
Ian: I opened a new issue on that:
https://github.com/w3c/payment-handler/issues/243
Manu: I think that there is
consensus on what expectations are regarding ordering
... I believe the consensus in the group is that implementers
consider user prefs over user patterns over merchant
preferences over merchant defaults
... I haven't heard anybody propose anything else
... I would like also to give implementers a heads-up about
regulatory implications of ordering and that they need to be
aware of them
... I don't think the spec should be silent about them
... I think that there are two remaining sticking points
... I know that there are are some WG companies that are
checking with their legal counsel
... I'm asking for more time
... for them to be able to weigh in
... just because there is consensus on two sentences doesn't
mean that there aren't concerns about the other items
... Ian mentioned Basic Card as an example of something else we
have done before
<manu> Ian: Regarding the two points that were raised - one of them has to do with ordering - I pointed out on the thread, there is no longer a way for merchants to express preferences in Payment Request API, so we are not in a position to speak about them (form a protocol perspective) in Payment Handler. Note that we chose explicitly to be silent on merchant preferences in Payment Request API, and consequently I'm not certain we can say anything in PH API about merchant preferences. They're not a part of the eocsystem in the API sense.
<manu> ian: Regarding what should a browser do - manual, usage patterns, then defaults: I don't think it helps to put that in the spec, not materially useful since that's merely the definition of those things.
<manu> Ian: Regarding, regulatory heads up - looked at basic card - because people said we need to raise awareness - PCI DSS - we did say in that context, we seem to be okay w/ a Note - heads up on PCI DSS. That one I suspect is acceptable because it is so specific, I know people were focused on PCI DSS for that conversation.
<manu> Ian: The language proposed by Manu for PH, was not so specific - don't like menacing language that doesn't tell people what they should do... I'd consider text that was specific about rules/regs directly about this spec, rather than broad advice, that's not valuable.
<manu> Ian: Manu had mentioned that we were getting rid of a lot of text, some of the text is just issue markers, some of the text is in new proposals, some of the text is stray sentences. So, I don't have any qualms about removing remaining text because it doesn't affect how PH works.
<manu> Ian: We heard clearly that people wanted user preferences, manual config back in... not sure about other spec - want more concrete "heads up" text... but until such time that merchant preferences are expressed, don't want to mention them.
Ken: The spec needs to be
commercially appealing to everyone in the ecosystem to get
adoption
... my view, consistent with what we've said in the past is
that it's important and useful to include information that user
preferences trump others
... I maintain it's important information to have in the
spec
<manu> manu: AmEx is not the lone advocate, at least DB supports the changes we suggested.
<manu> Ian: I think we came to ground on two sentences, I think we should put those in the spec. If we choose to edit the spec again, we edit the spec again.
<manu> Ian: I don't think there is any need to hold off on the two sentences, the way that Payment Apps are ordered is a browser capability today - the way payment instruments are ordered may or may not be ordered, I don't think we've had that conversation yet. When we get around to it, we'll update the spec accordingly.
<Zakim> manu, you wanted to oppose removing too much and not replacing it w/ enough.
Manu: I don't see why we should
rush the PR
... let's hold off a bit
... I do see the harm of removing section 4 and replacing with
only 2 sentences
<AdrianHB> +1 to not rushing however as the chair I would like to limit the time being spent on this during calls going forward
https://github.com/w3c/payment-handler/pull/242#issuecomment-351708682
IJ: I am fine to hold off on the PR; please send concrete comments on which bits have been removed that are critical
<manu> We need input from other WG members.
NickTR: I would like to give this more time.
<manu> If it's just DB that's concerned, I'm fine standing down
<manu> but given other conversations, I don't think it's just us... so let others chime in.
<manu> let's not rush it.
Proposed: 17-18 April 2018 (Tuesday, Wednesday) in Asia.
We do not yet have a host. Would anyone like to volunteer to host the meeting?
NickTR: We have a proposal for
dates but have not yet landed on a host and location.
... we are asking for volunteers to host in the Asian
regino
... we will also ask via Email
Ken: what does hosting
involve?
... I can look into this if I have more information on what
Hosting entails
NickTR: I can look into getting you that with Ian
4 January 2018
Happy holidays all!