W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2011

Web Payments Telecon Minutes for 2011-12-16

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 17 Dec 2011 02:02:16 -0500
Message-ID: <4EEC3E78.6060305@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
The minutes for today's call are now available here, thanks to Mike and 
Dave Lehn for scribing:


Full text of the discussion follows:

Web Payments Community Group Telecon Minutes for 2011-12-16
    Manu Sporny
    Manu Sporny, David I. Lehn, Mike Johnson
    Manu Sporny, Pelle Braendgaard, David I. Lehn, Mike Johnson

Manu Sporny is scribing.

Topic: Issues with PaySwarm and Simplicity

Pelle Braendgaard:  I'd like to start out by discussing how this
    group has been operating. I'm going to send out an e-mail to the
    mailing list. I'm a bit unhappy about how this process has been
    progressing, it doesn't seem to be a W3C standard, it seems as if
    people think that PaySwarm is going to be the solution. I think
    that OpenTransact is just as good of a solution. I've been very
    open about how to integrate, but I don't think that there has
    been much in the way of feedback on that. I feel it's very
    important that we do things simply. For example, the Agenda today
    is quite irrelevant. We should only discuss this if we are going
    to follow PaySwarm. I completely disagree with that approach of
    having a full, all encompassing standard. I feel like I'm wasting
    my time.
Manu Sporny:  You raise a valid point, but I think that there
    have been no other strong proposals put forward.
Pelle Braendgaard:  I believe I have. Out of not wanting to make
    this a PaySwarm vs. OpenTransact debate, I haven't proposed that
    yet. But that is what I'm going to propose today via e-mail. I'm
    going to propose OpenTransact as a basis for the W3C Web Payments
Manu Sporny:  I think that would be good, please do that - we
    need to thoroughly vet these ideas.
Manu Sporny:  Perhaps your reading on it is that we're trying to
    "push PaySwarm as the solution" is... well, you could look at it
    in two different ways: The whole reason this group started was
    because our company decided to place all of this technology into
    an open protocol, into an open standard, we led by producing
    working code, specifications, Web vocabularies, and then
    publishing those to the Web. We are completely open to
    modifications on the proposals, we're completely open to
    different approaches to the problem as long as it addresses the
    use cases. If OpenTransact can do that, we should consider it
    strongly. We need to vet these ideas, so please send the proposal
    to the list. Does that alleviate some of your concerns?
Pelle Braendgaard:  Yes, I'll send a proposal to the list later
    on today. I haven't done that because I don't want to step on any
    toes... I wanted to guide PaySwarm into what I think is a
    realistic standard. Right now, it's too all-encompassing. I feel
    like input I've given is not reflected in the Web API.
David I. Lehn:  What parts of the PaySwarm spec do you have
    issues with? We do understand the need for low-level
    functionality, but we're trying to define the whole ecosystem. We
    don't want just the low-level stuff. Maybe that's the better
    approach, but...
Pelle Braendgaard:  Well, I think we need to keep things very low
    level. For example, Vendor Registration doesn't need
    standardization yet... I don't think. That's something that
    different service providers could have their own, from that you
    could work out a standard for it. A standard is needed for
    payments right now, standard response format, querying whether a
    payment went through - that has to be done in a simple, low-level
    generic way. People need to use that for a while before we go in
    and create the higher-level stuff.
Pelle Braendgaard:  For example, I see digital signatures as a
    great option for receipts, but for payment, I don't see that.
    It's very complex, the PaySwarm spec.
Manu Sporny:  The spec is as complex as it needs to be to address
    the use cases we've laid out. In principle, I don't disagree with
    you, Pelle. However, we need to address the use cases. I think
    the issue is that nothing has been proposed that addresses all of
    the use cases...
Pelle Braendgaard:  I think OpenTransact has been proposed, but
    not directly, to be the underlying low-level standard before. I
    think we put too much work into the use cases, we spent 2-3
    months going through use cases. It's classic waterfall, not a
    historically successful model for creating standards. We need to
    start with simpler things. We can support all of the use cases
    using a combination of HTTP and HTML.
Manu Sporny:  ... but that's exactly what we're trying to
    standardize here - how /do/ you support all of these use cases?
Pelle Braendgaard:  Exactly.
Manu Sporny:  We need to understand exactly how each one of those
    use cases are addressed, we can't just simply say they can be
    addressed and not show how they can be technically addressed.
    That's what I'm concerned about. When you get down to the
    technical details, some of those use cases cannot be addressed,
    for example - decentralization, receipts, cannot be addressed
    without getting a bit more complicated with the implementations.
    Again, I agree with you in principle... but we have not seen a
    technical solution yet that addresses all of the use cases that
    we've interested in.
Pelle Braendgaard:  I believe OpenTransact does.
Manu Sporny:  I do not believe that OpenTransact solves some of
    the use cases that have been put forward. However, if you can
    make the technical case that it does, I see no reason why we
    couldn't also standardize OpenTransact. The end result of this
    community group could be two different specs for dealing with
    payments on the Web. It might be OpenTransact + PaySwarm. We
    shouldn't look at this as an all-or-nothing thing. Maybe
    OpenTransact is better at solving a subset of use cases, maybe
    PaySwarm is better at another subset.
Pelle Braendgaard:  This is why I've been proposing the layered,
    step-wise approach. It's how many successful standards have been
    created. I think that is important, we do not need to address all
    use cases there.
Pelle Braendgaard:  I think there are a number of technologies
    out there that already solve the distributed use cases. It can
    already be done via OAuth. I don't see the need for most of the
    PaySwarm standard. It's definitely not following a layered
    approach, I thought we agreed it was going to do that?
Manu Sporny:  We outlined why we thought OAuth was not a valid
    solution. If we implement OAuth, it's not a solution to the
    digital receipt problem. OAuth duplicates functionality already
    provided by digital signatures. Digital signatures are the
    correct technical solution for delegating access and for signing
    contracts and receipts.
Pelle Braendgaard:  I think OAuth is different from digital
    signatures... OAuth provides distributed transactions and
    distributed checking of receipts. It provides a good standard for
    delegating access. I disagree... yes, OAuth doesn't support
    digital signatures, but it doesn't need to. Digital signatures
    should be an optional thing for digital receipts.
Pelle Braendgaard:  We should really look at OAuth 2 and it seems
    to work very well for the majority of people out there, it's a
    good standard. But it works for accessing receipts. We should not
    require digital signatures. The requirement for digital
    signatures should not be the reason that you don't pick OAuth 2,
    which is an official Internet standard now. I agree that it
    doesn't work for receipts... but it works for /accessing/
Manu Sporny:  Right... so we actually implemented the latest
    PaySwarm demo using OAuth and the finding we came to showed that
    the implementations were overly complex by integrating OAuth. You
    ended up doing many more HTTP calls than necessary and even after
    you implemented OAuth, you still had to implement digital
    signatures. We found that in fact, all you needed to implement
    was digital signatures and all of a sudden there was a massive
    reduction in complexity for the implementations. What OAuth 2
    does is effectively replace digital signatures with this token
    mechanism... but if you just implement digital signatures, all of
    a sudden you have access control for free, because you know who
    is making calls to your system and whether or not they're allowed
    to perform certain actions on your system. You also get digital
    receipts for free because those depend on digital signatures as
    well. At the end of the day, all you really need digital
Pelle Braendgaard:  I completely disagree with your conclusion.
    They're two completely different things. We don't want end-users
    to deal with digital signatures. We only want servers to deal
    with digital signatures. Until you can do digital signatures in
    browsers, on cellphones, we don't need to be discussing this.
    Digital signatures are a pure server side issue, I'm fine with it
    there, but we shouldn't throw out OAuth 2 just because we need
    digital signatures.
Editorial note: you can do digital signatures in browsers and
    cellphones today: http://digitalbazaar.com/forge/
Pelle Braendgaard:  I disagree with the way you guys are pushing
    forward with this, I don't fault your company for pushing ahead,
    I disagree with this being the W3C Web standard solution. I don't
    mind you guys experimenting with it and pushing it out.
    OpenTransact is simple and used, this is why I wanted to join in
    with W3C discussion, but you are discarding a bunch of standards
    that are already Internet standards. I don't want to be nasty or
    angry, I just feel that this is going the wrong way. Having these
    sorts of things on the Agenda, I just don't think we're there
Manu Sporny:  So, I think the best way to proceed is for you to
    put the proposal forward on the mailing list and see how much
    uptake that gets. I appreciate your feedback, but I'm still not
    hearing a technical argument for how OpenTransact addresses the
    use cases that we put forward as a group. Therefore, it's just
    not the correct technical solution until it addresses those use
    cases. I don't disagree that we should take a layered approach,
    and perhaps if there is disagreement on which use cases should be
    addressed, then that is a good signal for the requirement of two
    different specifications. Maybe we should standardize both.
    Typically that is what happens when you have fundamental
    disagreements on what the technology should do. If we are headed
    into a situation where we believe there are certain use cases
    that should be supported and you're not convinced that we need to
    support those use cases, then perhaps we need to have two
    different standards. We're not trying to plow through and just
    standardize PaySwarm - we need to make sure that the use cases
    that are important to people must be addressed. Is that a fair
    view of the situation?
Pelle Braendgaard:  Yes. I think anyone who comes into the group
    is going to think that PaySwarm is the W3C standard that is being
    worked on. I disagree with that. I don't think that's right.
Manu Sporny:  Well, you have commit privileges to everything. You
    were given commit privileges at the very beginning, so you have
    the power to change the perception if you'd like. I think you
    should propose something, I think we should evaluate it, and I
    think that we should figure out how we can continue to work
    together on this. Does that seem like a fair and reasonable way
Pelle answers in the affirmative.
Manu Sporny:  Ok, based on that any updates or changes to the
    agenda that should be made?
Pelle Braendgaard:  I'll hear what you have to say on these

Topic: Spec updates

Manu Sporny:  We have a number of spec updates that happened last
    week. This is the latest implementation info that we have, we're
    going to have a live demo launched soon.
Commerce Web Vocabulary (http://purl.org/commerce)
PaySwarm Web Vocabulary (http://purl.org/payswarm)
PaySwarm Web API
PaySwarm Web API diff-marked copy to previous version is here:

Topic: Vendor Registration

Manu Sporny:  The idea here is that in order to operate on the
    network, you have to be able to create digital signatures -
    assets, listings, contracts, receipts, requests - all digitally
    signed. When you register your public key with the PaySwarm
    Authority you get some config info back. The destination
    financial account, default license, a whole bunch of preferences
    returned by PaySwarm Authority during registration. Vendor
    registration is used by a for-profit blog, web app store, etc.
    It's how a website registers with their PaySwarm Authority. The
    process is outlined in the link above. Two things that happen
    during Vendor creation: Identity is created, financial account is
    created. Any questions?
David I. Lehn is scribing.
Mike Johnson:  I think we're all pretty clear on this, Pelle?
Pelle Braendgaard:  Just reading it now. This is where public
    key/digital signatures come in. Where does vendor get their key,
    how do they sign?
Manu Sporny:  The WordPress blog, for example, generates the
    public/private keypair. Keeps private key, registers public key
    with PaySwarm Authority. Registration works much like how
    Twitter/OAuth works, but simpler - you just register a
    public/private keypair from your server software. Registers
    public key w/ PaySwarm Authority, then all you need to do is make
    requests that are signed. You don't need to do the big OAuth
    token dance to get a token so that you can make requests, no
    nonces need to be tracked, no tokens need to be tracked.
Mike Johnson:  Any software written in any Web-capable language
    can do this key creation/registration... PHP, Python, Ruby, etc.
Pelle Braendgaard:  So, what does this buy us over OAuth 2?
Manu Sporny:  You don't have to do the OAuth token dance and you
    don't have to implement/use OAuth. You eventually need digital
    receipts. Even if you implement OAuth, you still need digital
    signatures. So you simplify the system by not implementing OAuth
    without reducing what you can do with the system. You still need
    digital signatures/crypto for contracts, receipts, assets,
    listings, encrypting information over insecure channels (like
    HTTP), reduced cost because you don't need to buy an SSL
    Certificate for $30-$50/year.
Pelle Braendgaard:  None of those things are true, the only
    person that needs an SSL certificate is the PaySwarm Authority.
Manu Sporny:  If you are going to have a callback from the
    PaySwarm Authority back to the WordPress software (for example,
    to notify that a purchase is complete), you absolutely need to
    have an SSL certificate on the WordPress software otherwise you
    open yourself up to a MiTM attack and you leak personal purchase
    information to the Web.
Pelle Braendgaard:  but for receipts, you just need the PaySwarm
    Authority to have SSL.
Manu Sporny:  But then you can't do digital signatures for things
    like requests.
Pelle Braendgaard:  What kind of request?
Manu Sporny:  A request to another participant on the network
    that needs to verify the origin of a message. To do anything that
    you would use OAuth to do. For requesting the processing of a
    purchase request. To agree to a bill of sale. To digitally sign
    an asset or listing.
Pelle Braendgaard:  I hear no reason why a vendor needs to have a
    public/private keypair, they can just use OAuth.
Manu Sporny:  Then how does a vendor digitally sign anything?
Pelle Braendgaard:  They don't have to digitally sign anything.
    Digital signatures is just one use case for a small use case. We
    increase complexity by incredible amounts for a small use case.
Manu Sporny:  It's a use case that's important to us. You can't
    make the argument that because a use case isn't important to you
    that it's irrelevant. You can't say that OAuth 2 solves all of
    the use cases that are "important" and ignores the "unimportant"
    ones. That dodges the question. How do you address the many use
    cases that we have that require digital signatures? The question
    was: How do you use OAuth to address the digital signatures use
    cases? and the answer to that question is "You can't. You need a
    digital signatures solution for that."
Manu Sporny:  Here's an example - purchasing a meal, book or
    groceries, using a mobile phone with NFC and no data connection.
    The phone reads information from an NFC device proposing a bill,
    the phone digitally signs the bill and sends it back over NFC.
    Then the restaurant forwards the digitally signed (and possibly
    encrypted) bill on to the PaySwarm Authority for processing. You
    can only solve that via crypto/digital signatures. If you don't
    have that, you can't create these peer-to-peer solutions.
Pelle Braendgaard:  So, what you're saying is that until a
    purchaser can do digital signatures, then PaySwarm is not valid?
Manu Sporny:  No, that is not what I am saying.
Pelle Braendgaard:  We've discussed this before, you've confirmed
    that end-users are not supposed to be signing anything. I'm
    making numbers up now, but everyday in US tens of millions of
    electronic contracts happen without digital signatures. They do
    not happen in the ideal way. I like digital signatures. When it
    comes to end-users, the technology isn't there for it yet.
Mike Johnson:  Digital Signatures allow for "intents to purchase"
Mike Johnson:  Vending machine may have signed contract but no
    internet connection. buyer can use nfc and phones network for
    communications, where the transaction is processed via the
    cellphone, securely and the vending machine knows that the
    contract wasn't modified. This is about having a distributed
    payment mechanism, not everyone has a data connection to the
    server. This is about being able to trust that your payment
    agreement can pass through multiple hostile networks without
    being tampered with. This is what a next generation payment
    system should be doing in a consistent way.
Manu Sporny:  Pelle, you just admitted that things are not done
    in the ideal way. Current payment networks are not flexible.
    There are no IOUs from customers without incredible risk to
    merchants. Regarding you statement about digital signatures being
    too complex for customers - they're not going to see anything
    even remotely close to "Digitally Sign Contract" button - they're
    just going to see a "buy" button and they're going to click it.
    We just need to make sure that the technology being provided
    allows for flexibility and security. You can't do this with just
    OAuth alone.
Mike Johnson is scribing.
Manu Sporny:  we need digital signatures and they become a better
    replacement for oauth
Manu Sporny:  you won't need these multiple layers, you get all
    of that through just having vendors/customers digitally sign the
Manu Sporny:  this allows us to have these use cases we want
    whereas with oauth we can't
Manu Sporny:  the decisions need to be based on technical
    argument, so if the use cases don't match we need to address it
    through the use cases
Pelle Braendgaard:  I agree with the reasoning
Pelle Braendgaard:  but I dont think it should be part of the
Pelle Braendgaard:  but why does vendor registration need to be
    standardized? It doesn't need to be standardized.
Pelle Braendgaard:  by focusing on just a few use cases where
    digital signatures are necessary you make the other use cases
    much harder to address
Pelle Braendgaard:  focus should be on the 95% of the use cases
    and push harder work onto the fewer use cases where digital
    signatures would be a good solution
Pelle Braendgaard:  its danger to push for technology that
    historically most developers don't understand
Pelle Braendgaard:  is it important to standardize things like
    vendor registration?
Pelle Braendgaard:  Vendor registration shouldn't be in the spec.
    How it happens shouldn't be in there.
Manu Sporny:  almost all of that stuff is outside the spec. It
    says that in the spec, that how the account is created is outside
    the spec.
Manu Sporny:  only thing in spec is when vendor needs to talk to
    payswarm authority, when they register their public key.
Manu Sporny:  specifically, vendor account creation is outside
    the spec
Manu Sporny:  the spec says it is outside the spec
Pelle Braendgaard:  it then goes and says how to do it
Manu Sporny:  not quite, it specifies how the private/public key
    pair is registered with the PaySwarm Authority.
Manu Sporny:  This is another reason for digital signatures - the
    vendor needs to be able to digitally sign the listing and terms
    under which the assets are available.
Manu Sporny:  We need to do this because we don't want a
    centralized asset mechanism, we want to handle this in a
    distributed manner.
Manu Sporny:  the emphasis is on the key registration, not vendor
    account creation
Pelle Braendgaard:  Still does not see it as part of the
    implementation details of the payment API
Pelle Braendgaard:  I think that section 5.3: Vendor
    Registration, including public/private key registration, is
    outside the spec. These are just implementation details as far as
    I see it.
Manu Sporny:  But that's what a spec is about, it's about
    implementation details.
Pelle Braendgaard:  by saying the key registration is already
    part of the vendor registration, you are explaining how to
    register a vendor
Pelle Braendgaard:  isn't there already a spec for registering
Manu Sporny:  We looked and we haven't found any. No existing
    specs for public/private key registration, we were surprised as
Manu Sporny:  we'd use it if it exists, but it doesn't as far as
    we know.
Pelle Braendgaard:  well then it should be renamed to registering
    public/private key pairs
Manu Sporny:  ok, we can rename
Manu Sporny:  sure someone else may want to register a key pair
Manu Sporny:  it was set up this way to enable one-click
Manu Sporny:  explains wordpress registration
Manu Sporny:  other thing that came up was that OAuth doesnt
    solve is the problem of decentralized assets and listings
Manu Sporny:  how does a website specify that they have a
    something for sale in a secure way?
Manu Sporny:  they would need SSL certificates if they dont
    digitally sign
Manu Sporny:  one solution is to centralize assets and pricing,
    that's bad
Manu Sporny:  more innovation comes from decentralization
Pelle Braendgaard:  decentralized is important, but this is the
    web and by default it is decentralized...
Pelle Braendgaard:  most people would use a third party and don't
    need an SSL-cert alternate solution
Pelle Braendgaard:  still does not understand the reason for
    offers being signed
Manu Sporny:  but then they are locked into that site they are
    offering their services from
Pelle Braendgaard:  don't think that is a problem
Manu Sporny:  don't agree, they don't get to pick who their
    payment processor or authority is
Pelle Braendgaard:  the market decides that
Pelle Braendgaard:  right now you pick your payment process and
    can switch
Manu Sporny:  all of your data is locked into that one payment
    processor, then you have a huge cost locked into that processor
Pelle Braendgaard:  that's a market issue because a smart
    business will offer portability as an advantage
Manu Sporny:  but where has that happened in the commercial world
Pelle Braendgaard:  maybe the lack of it shows there is no need
Mike Johnson:  Two different philosophies here. There has been a
    large shift on data portability. People want more control over
    how data is stored and moved across systems. With
    Diaspora/Facebook/Google+ - examples from social. I think the
    idea of distributed design and data portability are very strong
    requirements. I don't think we should lock ourselves into the way
    traditional payment processors work today. We shouldn't look at
    the state of payments today and say that's the best we can do.
    We're trying to help people control their data upfront and not
    wait for the problem to appear and then fix it at that point. The
    Web is distributed, data should be distributed. It's easier to
    implement centralized, but the issue is the philosophy: What is
    the data that is involved and who should be involved? [scribe
    assist by Manu Sporny]
Pelle Braendgaard:  I agree that things should not be locked
    down, but I still don't understand why product listings should
    have a place in a payment standard. I haven't put much thought
    into this yet. However, I don't understand why it's a core part
    of this. I don't think many small business owners would think of
    this as an issue, they'd just move their store.
Manu Sporny:  we are out of time, let's continue the discussion
    on the mailing list. Pelle we'll wait for your OpenTransact
    proposal - thanks for voicing your opinion, important to address
    that early on. Let's keep the focus on technical merit. Thanks
    for great discussion, no call during the holidays. We'll have
    another telecon after the holidays.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
Received on Saturday, 17 December 2011 07:02:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC