See also: IRC log
<scribe> Scribe: Ian Jacobs
dezell: Any agenda changes?
dezell: Ready to send publication request today for Thursday publication
manu: no blockers currently known
IJ: I am doing media outreach, also FSTC; welcome other suggestions for getting the story out
<dezell> DE: do we still need to write a publication announcement?
IJ: We might want a group blog post on the FPWD; not aware of other formal announcements required
wseltzer: No aware of other formal requirements; +1 to disseminating
IJ: Manu, want to do a blog post (in the IG blog)?
Manu: +1
https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0049.html
dezell: I'm planning to put an
article in NACS daily
... do you want to collect pointers to these things?
IJ: +1 to sending results of various efforts to public-webpayments-ig
Please register: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0037.html
IJ: Roundtable planned for 18 June
https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015
IJ: Please send agenda ideas to David; he will have a draft agenda (first draft) on 27 April
Dezell: we will have breakout spaces
<manu> dezell: You're adding this to the registration?
<manu> Ian: People can send to the list - prompt via the form helps as well.
<manu> dezell: If we've already answered, we just click and re-submit?
<manu> Ian: Yes
<manu> Ian: We're also looking into getting a hotel block.
<manu> dezell: Any other questions on face-to-face?
dezell: Good meeting last Friday...starting to work with material from Erik Anderson
padler: we want to move away from
the term payment agent
... and talk about a "unified architecture for payments the
web"
... we are moving in that direction because there are topics
like identity that are used more broadly than just for
payments
... so we want to tease apart what is payment from other topics
like identity and credentials
... this will also be important to getting us clarity on
charter direction and what standards we will need
Erik: There may need to be
different views of the architecture...higher level, but also
one in terms of existing international standards
... for easier communication with banks, and other industry
players
Padler: we will focus on functionality and do gap analysis
IJ: +1 to focusing on
functionality
... and doing gap analysis!
<Zakim> manu, you wanted to suggest avoiding frankenstein architectures.
manu: +1 to breaking out into
roles (elements of a unified payments architecture)
... we need to mention that financial standards exist.
... we need to be careful about saying that we can take those
standards and simply plug them in
... this speaks more to Eric's blog post .. in general I am
completely supportive of us saying that standards exist and we
need to align with them
... I think it may not be free to integrate existing standards
into this architecture
... there are also issues about how other standards mesh with
web architecture
<Ryladog> +1 to manu's comment
manu: so let's not suggest we are
90% of the way there until we know in more detail
... so +1 to seeking alignment and mentioning relevant
standards, but it's not clear to me that they solve the problem
space we are addressing
padler: I think you make a great
point, Manu
... I expect we will see standards that we need to recognize,
but also acknowledge to what extent they can be used in our
ecosystem.
... the TF therefore has a deliberate goal of using standards
where we can, and identifying incompatibilities and also areas
that need glue
<Zakim> padler, you wanted to talk about how we are addressing frankenstein
<manu> +1 to what Pat is saying.
padler: A key principle is to identify existing standards, identity why may not work, reach out to them, etc.
dezell: Two reasons to observe
external standards - uptake, and also credibility in the
industry
... we need to come up with a short list of standards where we
think we need to connect
<Zakim> dezell, you wanted to talk about "working code"
ach erik
ach erik
Erik: +1 to working code, but be
careful about status clarity
... also, let's not shoot down existing standards before we
understand them fully
... there is also some subjectivity to some of the standards
and some flexibility in how interop is achieved
... +1 to describing how we can use standards in the web
model
<manu> Ian: Thanks to the Payment Agent Task Force - hope to get into that soon.
"Web Payments Payment Agent" => "Web Payments Architecture"
<manu> Ian: The title is currently Web Payments Payment Agent - if that'll change - we may want to change it?
<manu> Pat: Yes, I think the title will change
<manu> Ian: It's not clear to me if you're getting rid of a Payment Agent yet, or if it's subsumed by a larger framework.
<manu> Ian: I'd like to speak a bit to "working code" - I want to understand what that means - we need to not produce code in this group, that's not our purpose. We're supposed to create requirements to shape future WGs, those groups don't produce code... they create standards seeking implementations.
<manu> Ian: Beyond very toy proof of concept sorts of things, I don't think we should use "working code" - in IETF sense, that's directly attached to the concept of the type of standards development that we're not doing.
<manu> Ian: We should be focusing on requirements - and that includes how we related to other standards groups - get through that as quickly as possible so we can get to the working code bit.
<manu> +1 to Ian
<Zakim> padler, you wanted to talk about importance of working code
padler: The reason for the shift
from agent to architecture is to make it easier for people to
contribute expertise to different functional areas
... some prototypes we've seen have been focused on specific
domains of payment
... that leads to focusing (too much) on one topic rather than
parallel effort
... if we are too focused on one thing, we may miss important
discussion of identity, security, etc.
... the goal is now for the architecture to describe "what we
need"
... and let other groups imagine and describe how other parties
(including with existing work) can see their work in this
architecture
... we think this architecture will be more inclusive
IJ: +1 to architecture, btw
padler: So "working code" means for us "How the work of other people fits into the architecture"
<Zakim> dezell, you wanted to answer Ian
[Agreement work on payment agent to date has been valuable]
<Zakim> manu, you wanted to working code
padler: Goal is to expand scope to more functional areas
manu: We also have working code,
btw.
... +1 to focusing on architecture and not working code
... we should come up with framework and architecture
... we should not be focused on linked data v. RDFA, etc. and
other subtleties that WGs will have
<padler> +1
manu: our primary goals are use cases, architecture, requirements
<dezell> I don't think we have any disagreement
<Erik> Working code at this stage turns into Demo Driven Development. It causes problems this early in the process.
Manu: WebAppSec WG is publishing
a FPWD of a credentials API
... that API does not take into account a number of use cases
of this IG (nor of the credentials CG)
... this IG should be drawing up recommendations for new
WGs
... my concern is that the FPWD will create confusion
... what that WG is doing has more to do with "log in"
credentials rather than the credentials work we have in mind
here (e.g., for education, etc.)
... I would like more engagement on that draft / have
coordination among various groups before they go to FPWD
wseltzer: Looking at the work of
WebAppSec and the credentials CG and references to KYC
... to me the conflict looks like one solely of
terminology
... I believe that they are talking about different
things.
... the webappsec work is not meant to preclude a rich
credential ecosystem
... if there are greater conflicts, webappsec would like to
hear what those are
<Zakim> manu, you wanted to state that it is absolutely not a conflict of terminology
Manu: It is not a conflict of terminology...we've looked at the spec for several months...there is a slight conflict of terminology
<wseltzer> [how does it prevent you from solving your problem?]
Manu: but more importantly, it's
that the technology approach is not solving the problem....it
will create issues down the road.
... between same origin policy credentials...v. different
origin credentials with digital signatures
... this stuff should be unified
wseltzer: not necessarily
... that's where there is a strong difference of opinion
... and that's there the debate should happen....
manu: +1 to having that discussion BEFORE having an FPWD that assumes there will be two
Erik: I would personally rather
see a unified credential interface
... you will want to push credential info with value transfer
information
<Zakim> wseltzer, you wanted to ask, please give technical critique in WebAppSec, then and to say webappsec is trying to supplant the password, that's all
wseltzer: How to move
forward:
... give technical critique and points of conflict to the
webappsec group...especially if there are things that would
break by having two implementations
... if there are multiple ways of doing things, then I think
it's early in the standardization phase to stay that one that
is not yet specified is superior to one that is being
spec'd
... the webappsec goal is limited - replace passwords
... they are deliberately not saying who the user is behind
that
... or how the app might want to bind the user to that
identity
dezell: What is the preferred next tactic?
<Zakim> dezell, you wanted to ask how we can proceed...
<Zakim> manu, you wanted to say that the Credentials CG is trying to supplant the password too and to disagree w/ the pick up the pieces later approach.
manu: The credentials CG is also
trying to supplant the password, but in a broader way
... it overlaps so much that i feel like the webappsec group
needs to coordinate the with the other groups that care about
this.
... I am fine with the group going forward, as long as there's
an extensibility story
... it's not that the API is terrible, it's that it is not
aware of the ecosystem that could make use of the API
... could we hold off on the FPWD for 3 weeks or so so that
when it goes out
... there is more unification
... also, I have not seen a lot of discussion on the mailing
list about the spec
<Zakim> wseltzer, you wanted to say it's really early for an objection or w3m
http://www.w3.org/2015/03/webappsec-charter-2015.html
wseltzer: Let's figure out what
we need to hear before we discuss tactics
... premature to talk to w3m or file formal objections
... webappsec is willing to listen to technical
commentary
... so here are specific issues that would preclude us from
doing work elsewhere
Manu: Could you hold up publication 3 weeks?
Wseltzer: That's a long
time
... I will ask the WebAppSec chairs if that is acceptable
Manu: Please note that I've also sought out Mike last October to coordinate, so we have tried
wseltzer: I am happy to facilitate further conversation
<dezell> Ian: concrete suggestion - Wendy/Mike/Ian/Manu chat.
<wseltzer> ACTION: wseltzer to consider call among Manu, Mike, chairs, team contacts [recorded in http://www.w3.org/2015/04/13-wpay-minutes.html#action01]
<trackbot> Created ACTION-89 - Consider call among manu, mike, chairs, team contacts [on Wendy Seltzer - due 2015-04-20].
Dezell: Please include me and Erik in that call
<Zakim> dezell, you wanted to ask if we're in their charter
<manu> Manu: Thanks Wendy and Ian, thanks chairs for coordinating.
20 April
Pat: Please send outcomes of credentials discussion to the list