Web Payments IG: Payment Architecture (Friday) Teleconference -- 08 May 2015

<trackbot> Date: 08 May 2015

<manu> trackbot, make logs public

<trackbot> Sorry, manu, I don't understand 'trackbot, make logs public'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Priorities

<manu> scribe: AdrianHB

pat: focus today is establishing work priority
... what iteration length is appropriate?
... 1 week or 2

Organize Document Sprint

<manu> https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Priorities

pat: let's establish if there are any gaps in Manu's list
... then use the document to draft capabilities into the architecture doc

<manu> Link to Google doc: https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit

pat: pg 8 - there is some content Manu has added
... actually pg 9, talks about requirements of arch
... we want to break out the capabilities by functional area
... this helps allocate work to other w3c groups

manu: we do need to still discuss manifesto doc
... the arch doc is most imprtant but manifesto can be done in parallel

<padler> +1

manu: let's time box the agenda
... leave last 15 mins for other topics

pat: we need to consider credential
... doesn't have to be part of v1

<Zakim> manu, you wanted to mention an approach to credentials

pat: we are not talking about credentials yet, do we need to?

manu: we absolutely need credentials
... but looking at v1 there is a way to do this without credentials
... all the payee needs in the most simple use case is proof that money is on the way
... identity is at the KYC layer
... the v1 arch is not too compelling without credentials but we still need to decide if it's sprint 1 or 2
... credentials cg has been going for over a year
... it is trying to solve the real problem
... credentials came from web payments as an effort to split the two
... we need to understand how to decouple them so they can mature in parallel
... the payments work must assume the credentials work does what is required

jheuer: I took opportunity over the last while to talk with dave
... A thing that appears to be misunderstood is the symmetry that seems to be implicated by the payments agent structure
... i.e. agents talk to agents using same protocol
... we should try to do a doc that doesn't include credentials
... in reality there are always credentials involved
... we shouldn't try to do a doc that doesn't include credentials

<Zakim> padler, you wanted to decouple identity priority from credentials and to talk to symetry

jheuer: strong +1 for intro credentials

pat: +1 for decoupling payment and credentials
... the credential stuff is imprtant, we are not suggesting it's not part of first arch just won't be focus for first 2 weeks

<jheuer> credentials de-couple identity and payment, which is a good thing

pat: yesterday we decided to define scope of work (not doc) so we could get focus

<jheuer> we can work without identity, but not without credentials

pat: re your comment re symmetry. ur right every payment agent won't be the same
... but we do need certain things to be the same so the agents can use a common messaging standards
... other layers on top like loyalty may not be implemented in all agents

<manu> +1, agree with most of that

<Zakim> AdrianHB, you wanted to get back to sprint planning

<Zakim> Adrian, you wanted to mention why he wanted Credentials cleaved from Web Payments CG

manu: I put adrian on the queue to explain his views

<manu> Adrian: When I first joined the Web Payments CG - I was coming at it from an angle of exchanging payee information - not worrying about authenticating anyone.

<jheuer> +1 to the credential rationale

<manu> Adrian: It was from a background of knowing payment information - bank-to-bank payments... but when you go into a shop, teller swipes card, he doesn't have to know who I am... could be an anonymous gift card. No need for identity/credential exchange - they don't need to trust each other, they need to trust the system that they're using.

<manu> Adrian: As soon as you get in more complex scenarios, like age verification or interoperability across value networks, then you need credentials.

<Zakim> AdrianHB, you wanted to get back to sprint planning

<manu> AdrianHB: We've spent first half of the meeting talking about credentials - they're important, we need to put them in there, let's get back to focusing on the sprint.

<padler> +1 for keeping us on track... :)

<manu> AdrianHB: Let's talk about what we're doing for the next two weeks.

<manu> jheuer: I'd like to keep identity out of the discussion, that's not necessary for the elementary use cases.

jheuer: I agree with what has been said. I would like to keep identity out but I think credentials are required

<manu> manu: +1 to keeping identity out of this.

pat: to clarify what I mean by identity, it's loaded

<Zakim> padler, you wanted to talk about identity of system actors and not just payees/payers

pat: we think of users and privacy but what i was meaning is a way to identity the actors
... unless we have a good idea of where we need credentials then we don't know how to build the rest of the scaffolding

<Zakim> manu, you wanted to shift discussion to sprint and to shift discussion to sprint planning

pat: we can limt the scope to identifying actors not "human identities"

manu: let's hope we can get through each version in a week
... esp becasue we are not planning to have more than a few paragraphs on each
... let's start there and then flesh it out based on input
... my biggest question is around pg 10 and 11
... I went through v1 and v2 and tried to translate to capabilities
... is this what everyone was expecting?

pat: +1 to the messaging
... some feel like they are too specific to use cases
... we do need to tie them to use cases eventually but this is just the architecture
... we need to avoid context specific terms

manu: whats the right level of abstraction?
... are you saying merchant publication of offer of sale is too specific?

pat: let's not say "merchant"
... in the context of offer of sale, where do we need that to be realised?

<jheuer> +1 to offer of sale is outside of payment process

pat: are we saying that we need the agent to be capable of publishing an invoice that feels like outside the payment process

manu: yes, offer of sale is different to invoice
... it's like a beacon sending an offer message, or something in a web page that puts out an offer of sale

<jheuer> +1 to invoice being first step in payment process

manu: I'm struggling with the level of abstraction and where to put them in catagories
... is security a good category, it seems broadly applicable

<Zakim> manu, you wanted to ask about "security"

manu: there things in here (categories) that feel too broad to be categories

pat: I agree, how do we stick to DRY principles
... q for the group. how do we structure the capabilites? by capabilites or by interface where they are required
... eg- we deal with the collection of capabilites required by a specific payment agent interface
... a 4th section could be things that are required that are common (core capabilities)

+1 to group by interface to start with

<manu> AdrianHB: Grouping by interface is a good idea, it'll help us understand what those interfaces are going to do.

<manu> AdrianHB: We don't have enough content down to start playing with this stuff. Let's start w/ what Manu said - put a paragraph down about each item.

<manu> AdrianHB: Let's start w/ a paragraph or two and let that fill out.

<manu> AdrianHB: Let's do that ASAP, then we can iterate - let's start putting down content. Let's have a look at capabilities are covered by level 1 and 2... go away and come back w/ 1-2 paragraphs that describe that capability.

<padler> +1

<jheuer> +1 to put some flesh to the sections first

manu: I made a pass at this already but prob missed some
... let's all just start adding capabilites

<padler> +1

<manu> AdrianHB: I agree - should we partition the list? Categorize by payment agent interface.

jheuer: I am willing to help and write but want to see what is there because I have some issues with the existign design of the agent
... I need to find my place to put my ideas in there

manu: there is a lot of overlap in discovery of credentials and agents

jheuer: i have an issue with agents accessing accounts vs credentials

manu: I think jheuer you have an issue with credentials being missing
... maybe jheuer should focus on credentials and we will work on capabailities

jheuer: +1

<jheuer> +1 to jheuer trying to fit credentials in - also to create a consistent picture for myself...

<padler> +1 to categorization by interface + core section

manu: +1 to categorise by interface

<jheuer> +1

<padler> +1

manu: let's just start, no need to seperate work yet

<Zakim> padler, you wanted to think out loud about Jörg's question..

pat: i don't want anyoen to feel like we are driving a payment agent design that is different to what they believe is req
... is there a need for an identity agent (payments and identity are closely tied)
... they can be used independantly
... thinking out loud but feels like this is badly needed

<Zakim> manu, you wanted to say IT IS 15 MINUTES UNTIL THE END OF THE CALL!

work process

<padler> +1

manu: let's leave what we want to discuss at F2F until early June

<jheuer> I believe that credentials are there to de-couple identity and payment - and that's very useful to do

manu: wrt the manifesto I have been thinking on it
... I'd like to have something done or almost done by F2F
... let's talk manifest then tooling

pat: agree. let's get the vision statement in good shape
... q+
... the whole IG will be there and others so we need to be able to show our vision and goals to them
... we need to prep as there is some educating to do
... ito the document flow I agree with manu. we need to do what is going to make it most productive
... google docs works for the core editors so we should just copy to the wiki every week or two

jheuer: need to have vision asap

<manu> Adrian: There is a vision document now - it's had input from Manu, Ian, and a number of other folks.

<manu> Adrian: There has been a bit of discussion around it on the mailing list - ported it to ReSpec format. I wanted to get it into a finished format as soon as possible, get people's input.

<manu> Adrian: There are not going to be major changes to it - didn't think there were going to be major changes to it.

http://w3c.github.io/webpayments-ig/latest/manifesto/index.html

<manu> Adrian: Vision document ^^

<manu> Adrian: Why I think I'd like something published before face-to-face - I feel like the vision is valuable internally, but it's also extremely valuable to tell the rest of the world what we're doing what we're doing - get them to recognize or join the work. It feels like the face-to-face in June, Wall Street there - great opportunity to do event/publicity around the event.

<jheuer> I read this doc - but it's about the value web... aren't we talking about a payment vision?

<manu> Adrian: "This is our vision" is powerful - we want to realize this.

<Zakim> manu, you wanted to talk about changes to Vision document.

manu: broadly agree with what you're saying
... don't think we'll get it published in time though
... let's put it out there as an editors draft and publicise it
... i think the document is valuable but pubishing to attract new people to the F2F is not possible as we're at capacity already
... also this is a long game so let's not worry about time sensitivity
... the thing that bothers me is the "value web" moniker
... the other word "manifesto" comes across as being too radical
... when people hear manifesto they think about some fringe radical movement
... this is not a fringe opinion, this is the standard position of the future of the Web
... i'd prefer something like Web Payments Vision but even payments is loaded
... the other thing that bothers me is the order of the principles
... lets put people first (W3C always does that)
... let's re-order them to talk about people impacting principles first

<jheuer> I understood 'value web' is the overall vision, payment, identity, credentials, etc. are special cases, right?

manu: finally, it needs a summary in the first page that encompasses all of the priciples

@jheur: yes

manu: moving to respec was premature
... let's do g doc for now

<Zakim> AdrianHB, you wanted to clarift publishing process

<manu> AdrianHB: Thanks for the input - useful feedback. Publishing process - I'm happy to not have it officially published.

<manu> AdrianHB: Still new to publication - frustrating to hear "won't have time before the face to face" - let's do it at the face-to-face. Don't want the excuse to be "it's too much work".

<manu> Manu: The issue was getting people to understand it before the face to face.

<manu> Adrian: That's fine - I'm happy w/ throwing some publicity at it, even if it's an Editor's Draft - I can get folks to put budget behind it. We can invite people to drinks, for example - this is the vision, this is the activity - invest in a little marketing on the thing.

<manu> AdrianHB: I do want to get feedback on the vision document - will raise it again on Monday's call.

<manu> AdrianHB: Happy to proceed like this.

pat: i like the idea of an ED that we can point to that is tangible
... q is (maybe needs to go to broader group) it feels like we're hitting at a number of core things for the web/internet
... so it's not just an internet for exchanging content, it's for exchanging value and identity
... if we just talk about it as "the Web" vs "the Value Web" then it sounds like a manifesto for the next version of the Web
... we shouldn't have a simialr vision from the credentials group
... if this is the next Web manifesto maybe we need to raise it at TPAC?

<padler> :)

pat: let's raise with Ian and others

jheuer: what I understood from the manifesto was an abstract ideal

<padler> Maybe it's just "W3"

jheuer: I would have worked in credentials and identity
... I feel the work we are doing are foundations for this vision
... but I don't think the pattern can be played down to payment or identity work

manu: if you drop the "value" then you have a description of the Web
... but payments don't have those properties today
... we are trying to make payments work like the Web

<jheuer> Trust, Identity and Payments are asymmetric and directional

manu: we are restating the things that makes the Web a success and say we want to apply these to payments
... this is very powerful

<jheuer> ...and it's good that way, because it reflects reality and helps keep things separate (privacy, etc.)

pat: when you deal with payments and identity they absolutely have to be idempotent
... if we think of next v of the Web and payments and identity are critical things
... these are core pillars of the Web of the future
... this feels like a TPAC thing

manu: +1

<jheuer> I'd rather think that credentials could be the means to achieve these goals...

- DRAFT -

Web Payments IG: Payment Architecture (Friday) Teleconference

08 May 2015

Attendees

Contents

Organize Document Sprint

work process

Summary of Action Items

Scribe.perl diagnostic output