VincentK: perhaps we should wait to make this proposal until FTF
... and we can make adjustments more efficiently at F2F

AdrianHB: anyone opposed to making a resolution on this?

<ShaneM> PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate

<Ian> https://github.com/w3c/webpayments/issues/62#issuecomment-173561385

MattS: the proposal is more detailed than what is being put forth.

manu: It's not clear to me what we're doing.

<Ian> Proposal from MattS -> https://github.com/w3c/webpayments/issues/62#issuecomment-173561385

VincentK: I agree.

<Ian> Manu: -1 to MattS's proposal

AdrianHB: I'm willing to push this out as unresolved.

shepazu: We just need general consensus.

AdrianHB: Do we have clarity on the proposal?
... it will not change the work if we delay this
... MattS and VincentK, please put forth a clear proposal.

Ian: People who feel the proposal is not clear should make comments about the proposal.

<manu> I don't think the proposal is clear - are we doing what MattS is saying in the spec text, or in the WPIG Glossary, which is pulled into the specs.

<shepazu> Ian++

<Ian> https://github.com/w3c/webpayments/issues/62#issuecomment-173561385

Ian: This is a proposal that MattS is putting forth.

<dlongley> What terms are being adopted where? (I've read MattS's comment, but I'm still not clear). I heard people saying we use Payee and Payer and add those terms to ISO20022 as synonyms. But I'm not sure if this is what is being proposed.

Ian: please provide comments/questions to this proposal.

<manu> Ian++

<manu> Agreed w/ this being the way we resolve clarity around this proposal.

<Laurent_> agreed with Ian

<Ian> So the group action is "Review MattS's proposal this week and send questions for clarification"

<dlongley> -1 from me because it's unclera.

<Ian> ...then we'll put the proposal to the group at next week's meeting

<manu> -1 it's unclear how editor's should implement this.

AdrianHB: Please provide +1 / -1 on the proposal that has been linked to by Ian.

<rbarnes> -1 to Ian trying to rush this ;)

Ian: we should come back next week and deal with this proposal.

<manu> (or rather, one of the editor's is concerned with exactly how we implement this in the specs)

<manu> (and it hurting understandability in the specs.)

<rbarnes> -10 to rbarnes for being tuned out for a couple months :P

AdrianHB: this proposal is by Manu

manu: very quick, I think the payment request API is trying to improve the checkout process.
... one thing we could automate is shipping address collection. But collecting this information is very specific.
... and there are discussions underway in various groups about how to best collect shipping address information.
... the proposal is to NOT deal with shipping address in the payment API right now.

<Zakim> manu, you wanted to not delay the decision, but get data for a better decision for later. and to note that is not the proposal.

manu: let's delay that decision right now.

zkoch: I disagree with manu. I think that there is no chartered working group to tackle shipping addresses.

<rbarnes> as a webappsec person, agreed that there's no action on addresses there

zkoch: secondly, I know we talk about shipping being ultraspecific use case
... but there is nothing more common in e-commerce.
... I think this should be implemented now.
... I think it is early in the process to say that we should NOT be working on this.

<Zakim> ShaneM, you wanted to say that there is also nothing more common than billing address. Why aren't we special casing that too?

ShaneM: why are we not special casing billing address which is equally ubiquitous.

<Zakim> manu, you wanted to note that Credentials CG engaged heavily w/ Mike West to generalize the API to support things like Addresses in the future.

<rbarnes> billing address is not merchant-facing

manu: we have engaged (digital bazaar and the credentials CG) with Mike West.
... we have had discussion about using Verifiable claims API for this purpose.
... I'm confused because the conversations that we've had were targetted at shipping/billing address and proof of age.
... we are actively having discussions about charting work around claims.

rbarnes: It seems early to be making this decision.
... this would need to be something that involves a new working group which seem pretty far down the road.

<dlongley> quick comment: how this information is collected could change the shape of the API and there are potentially many other pieces of information to collect, +1 punt now deal with later (don't want to mess this up).

AdrianHB: I echo some concerns about depending on things that don't exist yet, but only likely.
... we can't depend on that happening.
... there is a lot of user experience issues that we should be considering.
... if you use apple pay or android pay, collecting address information is performed along with payment.

<rbarnes> it's also not the end of the world if we end up with two places to transmit addresses

<dlongley> some of my other complaints are with *how* it has been proposed to be collected: https://github.com/WICG/paymentrequest/issues/42#issuecomment-173628517

<rbarnes> how many web storage thingies do we have?

AdrianHB: I'm OK with punting until we have more specific information.

<manu> Yes, but no one agrees that was a good outcome :)

<rbarnes> and yet, the web has not collapsed

<manu> having cruft in the Web Platform is not a good thing.

<Zakim> Ian, you wanted to make a concrete proposal

AdrianHB: can we still have a fluid user experience if we separate the concerns?

<manu> The Web won't collapse, it's just we're unnecessarily adding cruft into the Web Platform.

<dlongley> merchants can collect address information today -- let them keep doing it until we have a good way to help them do it.

<manu> and it's not like merchants can't collect shipping address information today.

<manu> let's do this right, not rush into it. :)

Ian: I would like to propose that we continue to develop the spec as the authors write them.
... if we see credentials work that is chartered and clearly relevant, that the payments API could evolve.

<zkoch> it’s also not like merchant’s can’t collect payment credentials today :)

<dlongley> also note: collecting shipping address information *too late* in the payments process is seen as a major cause of cart abandonment, let's not prescribe that merchants do it that way.

<ShaneM> I wonder if we can't just mark this part of the spec as AT RISK because of pending work?

Ian: and it could be noted that there are hooks to other work that is taking place.

<manu> zkoch, yes - but we're focused on that in this group. We're not focused on gathering arbitrary credentials (shipping address being just one of them)

<dlongley> zkoch: yes, but we have some good direction and we're the group working on that.

Ian: this would allow drafts to include address information, but keep on eye on additional approaches.

<manu> zkoch, I'm not saying the decision is black or white - but I feel nervous saying "we're going to do this and then replace it with something better later on".

AdrianHB: I would like to allow the API to gather shipping information, but be aware of other work taking place.

Ian: if we can have a pipeline for getting information, I like that approach.

<zkoch> First bullet from charter on benefits: “A better checkout experience for users, particularly on mobile devices. The standards should facilitate automation, one approach to improving the user experience.”

<manu> I'd rather make the mechanism declarative instead of imperative - IF we decide to do something about it in this group, which I think is a bad idea.

<zkoch> I think it qualifies there, but agreed it’s a tricky question

<manu> Agreed it qualifies here

<dlongley> +1 to Ian, low-level APIs to get the info and a feature to pipeline them

<manu> don't agree that we have the right approach for shipping address. :)

AdrianHB: I suspect these heavy questions will not be easily resolved.

<manu> +1 to low-level APIs to get info and feature to pipeline them together.

AdrianHB: we will likely see proposals be kicked down the road, how do we prevent this from happening indefinitely.

<Zakim> zkoch, you wanted to talk billing addresses

<dlongley> this is great to get high bandwidth discussion on the tough issues on the call

zkoch: I think that billing is tricky. The billing address is more in the responsibility for the payment instrument.

<dezell> Other WGs I've been in adopted a "feature at risk" designation. This designation serves as 1) an indication that the feature might go away in a later draft and 2)a call for advocacy from those who think it's important. "Feature at Risk" would appear in red.

<Ian> (IJ agrees with Richard that more experience will inform the discussion.)

rbarnes: I'm not that worried about punting on hard questions, because we don't have a lot of concrete proposals and APIs to work with.
... once we have more concrete ideas to work with, these questions will be more easily resolved.

<rbarnes> overall, the process seems pretty OK, yeah

<manu> +1, happy with the process.

<zkoch> +1 to proposal methodology

<rbarnes> +1

<dlongley> +1 with the process

AdrianHB: Are we happy to continue working on proposals on the call?

<dezell> +1

<Ian> +1

<ShaneM> +1 to the process (and evolving it)

AdrianHB: Ian will be sending out updated meeting details.

<VincentK> +1 with the process

Next meeting

<Ian> 28 Jan at noon ET / 5pm UTC

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/??/rbarnes/
No ScribeNick specified.  Guessing ScribeNick: matt_
Inferring Scribes: matt_

WARNING: No "Present: ... " found!
Possibly Present: AdrianHB Ian Laurent_ MattS PROPOSAL ShaneM VincentK dezell dlongley https manu rbarnes shepazu zkoch
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 21 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/21-wpwg-minutes.html
People with action items: