- From: Dave Lampton <dave.lampton@gmail.com>
- Date: Fri, 13 Jun 2014 02:31:48 -0700
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAHbN0eyCv-MyHWU8uaDp6UGnYsdrezysssgu-sJp2VphmsS2mQ@mail.gmail.com>
Not to mention that following the rise of the machines, my new digital cash system will no longer be optional. ;-) Dave Lampton * @dave_lampton <https://twitter.com/dave_lampton>* * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton <https://www.google.com/+DaveLampton>* www.linkedin.com/in/davelampton/ On Fri, Jun 13, 2014 at 2:28 AM, Dave Lampton <dave.lampton@gmail.com> wrote: > Hi Adrian, > Yeah, I fully agree with your points in your #1, and I'm simply running > with the idea while it's still entertaining me. :) The closest thing thus > far is that ZeroCash protocol but at this point who knows how far any of > those currencies may evolve, into some part of a long-term solution, or > whether they will both have disappeared in two years? I agree that > installing anything into government agencies will be like herding a nation > of cats. And yeah, I imagine ALL bankers will feel more than a little > nervous about the encroachment of these new machines & the threatening of > the bankers' very need for existence. The banking industry will despise all > of it. But guess what? The technology eventually sells itself every time. > Presumably, at some point (but not any time soon) the world will be even be > ready to go as far as abandoning physical money... maybe not. Maybe only in > some places. We have no idea what's the future holds, but I have a feeling > that getting from this stage to any kind of deployed system actually > transacting *cash* in US dollars... we're talking decades! So, if we work > hard it may be an official recommendation by then. ;-) > > Dave Lampton > * @dave_lampton <https://twitter.com/dave_lampton>* > > * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton > <https://www.google.com/+DaveLampton>* > www.linkedin.com/in/davelampton/ > > > > > On Fri, Jun 13, 2014 at 1:57 AM, Adrian Hope-Bailie <adrian@hopebailie.com > > wrote: > >> Hi Dave, >> >> I think pursuing a better over-all system is a valid effort and I'm keen >> to help if you ever want a sounding board or an argument :) >> >> My point is that there are two things that need to happen in parallel: >> >> 1. Invention >> Invent better ways for payments to work. >> Bitcoin, Ripple, DNS-based, distributed/federated systems etc. These are >> all valid endeavours and are definitely disrupting the industry. >> Using the concept of the Bitcoin block-chain for other distributed >> systems is a great example of why this type of innovation is great! >> >> That said, the traditional centralised payment system is going nowhere >> soon. >> If we genuinely expect the world's national/federal reserve banks to >> simply roll-over and hand control of the world's finances to a bunch of >> distributed systems I think we are being very naive. >> I suspect that over time the two systems (modern/distributed and >> traditional/centralised) will start to merge and that is where I hope >> standards will become relevant and facilitate innovation. >> >> 2. Standardisation >> While the innovators innovate we can still look at the current status quo >> and identify problem areas or areas where standardisation will improve the >> status quo and develop those standards. >> >> My understanding of the way the W3C works is that nothing becomes a >> standard until it's actually being used or at a minimum there are working >> POCs so innovative ideas are going to take a long time to become standards >> if they are too disruptive (that is not to say they shouldn't become >> standards eventually). >> >> My suggestion is that the payment process be broken down into a generic >> state-flow and we look at ways to standardise each step and not the whole >> end-to-end process. >> (This seemed to come up in a number of the conversations at the workshop >> in March). >> >> At the end of the day, payments work right? Most of us are able to >> perform a payment. >> The friction is mostly due to interoperability (inter-bank), security and >> regulatory issues. >> Exactly the kind of issues that good standards address. >> >> My suggestion would be to take all of our use cases on the wiki and pull >> the elements from them that are common to a specific stage in the payments >> process and then focus on standardizing those stages. >> Where the scope starts to grow too big explicitly make the standard >> extensible to handle a broader range of use cases and new standards that >> extend the base standard for those scenarios. >> >> I started writing these stages out here but it's becoming a long list. >> Will kick off a new thread to discuss these in detail and get feedback. >> >> Adrian >> >> >> >> On 12 June 2014 18:18, Dave Lampton <dave.lampton@gmail.com> wrote: >> >>> Hi guys, I half expected to get flamed this morning for introducing way >>> too much noise to the conversation, so thank you for being polite! :-) >>> >>> Adrian, yes, I think you're absolutely right. My proposal probably DOES >>> belong under IETF considerations not W3C. (It's been years since I've >>> participated at all with any of these standards groups.) In fact, I was >>> initially just thinking my end result was going to be a simple new PROTOCOL >>> for monetary transactions running on a *privileged port* (which also >>> requires an IANA assignment) - clearly IETF territory. But once I started >>> thinking that I'd rather just piggy-back onto wss:// (WebSocket+TLS) I >>> stopped thinking about the port, just assuming I'd be using TLS/1.0 + >>> HTTP/1.1 on an upgraded port 80. I also initially looked at *the four >>> new *Resource Record types provided by DNSSEC, but yeah I will try SRV >>> - that looks like the right way to do things going forward. Thanks. >>> >>> I too am still not convinced identity is always a necessary component >>> either. Especially if using a trusted channel. If the channel itself >>> identifies the payer, the payee has enough to record the debt as paid. >>> >>> Being so unsatisfied with the present ecosystem and intending to >>> eliminate the need for any third party involvement in transactions, I was >>> never actually intending to attempt to integrate with the existing >>> proprietary or closed payment channels but would instead seek to create a >>> more appealing solution that they will want to migrate to simply because it >>> would be the simplest, and most universally useful Open solution. >>> >>> Cheers. >>> >>> Dave Lampton >>> * @dave_lampton <https://twitter.com/dave_lampton>* >>> >>> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >>> <https://www.google.com/+DaveLampton>* >>> www.linkedin.com/in/davelampton/ >>> >>> >>> >>> >>> On Thu, Jun 12, 2014 at 5:08 AM, Anders Rundgren < >>> anders.rundgren.net@gmail.com> wrote: >>> >>>> On 2014-06-12 09:32, Adrian Hope-Bailie wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> <snip> >>>> >>>> >>>>> I believe a greater discussion is required around what constitutes an >>>>> effort to "standardise" and what is actually invention of completely new >>>>> ideas. If there is to be a standard developed that marries the Web Platform >>>>> with the traditionally closed and proprietary payments ecosystem it will >>>>> need integrate better into existing payments channels and not simply >>>>> propose to replace everything. >>>>> >>>> >>>> +1 >>>> >>>> >>>> I also think there needs to be more discussion about whether identity >>>>> is that important. If a payment is initiated by the payer via a channel >>>>> they trust (internet banking, wallet app etc) and the payee simply receives >>>>> a digitally signed proof-of-payment if the form of a receipt from an entity >>>>> they trust (their payment gateway, bank, wallet provider etc) why does the >>>>> payee need access to the payer's details at all? >>>>> >>>> >>>> +1 >>>> >>>> Anders >>>> >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> On 12 June 2014 03:30, Dave Lampton <dave.lampton@gmail.com <mailto: >>>>> dave.lampton@gmail.com>> wrote: >>>>> >>>>> Hi all, I am still relatively new to this group and trying to >>>>> catch up with the work that has been done thus far on Web Payments, and >>>>> I'll be the first to acknowledge that I may have still missed some >>>>> important details (but I don't believe so). Likewise, I don't want to >>>>> conflate the conversation too much with my own ideas for implementing >>>>> "digital cash" transactions, so you can take my comments with a grain of >>>>> salt, at least for now. :-) >>>>> >>>>> >>>>> To me, the proposed system already just feels overly complex for >>>>> the tasks at hand - lots of moving parts, several steps involved. I'm all >>>>> for using existing open standards, but it seems like we may be limiting >>>>> ourselves (or rather, complicating the problem, I think) instead of simply >>>>> inventing only what's really needed. >>>>> >>>>> >>>>> TL;DR - I'm with Melvin Carvalho and his comments made yesterday >>>>> re: his fundamental dissatisfaction with 3rd party identity solutions (even >>>>> just the concept of a 3rd party doing this for me is troublesome). I'm >>>>> largely unsatisfied with the various identity systems already competing - >>>>> they are not particularly fun or easy to work with, and the one you need >>>>> today is usually that one you've never needed to look at before today. >>>>> >>>>> >>>>> Additionally, I still feel uneasy about using email addresses at >>>>> all in any sort of next-gen payment system, but especially if the real goal >>>>> is to ultimately just attach to browsers/devices anyway. This "shim" >>>>> already sounds like something we would prefer to throw away, so then, let's >>>>> just leap-frog it altogether. >>>>> >>>>> >>>>> Furthermore, I agree with a few others that URI's are wholly >>>>> inadequate in the role of endpoints because more than one can be live on >>>>> the same host and therefore they invite people to potentially host multiple >>>>> people's money (and the transactions thereof) on a single host or device, >>>>> which just seems like the quick road to widespread corruption. Using the >>>>> browsers as secure endpoints seems like an even worse idea, regardless of >>>>> who suggested it all the way back in 1990. ;-) Browsers are too transient >>>>> or inconstant for my taste, and again, multiple instances can be running >>>>> simultaneously on a host. If used properly they could work fine, I suppose, >>>>> but they are also a piece of software which means they are also game-able, >>>>> open for abuse, emulation, fraud. >>>>> >>>>> >>>>> And while I'm complaining about everything, I'll even point out >>>>> that our de facto API these days, a RESTful interface, is also overkill for >>>>> the very few types of messages we actually need to pass around. I find that >>>>> the problems can be solved with a small set of JSON-LD (or BSON-LD?) >>>>> messages (representing individual sets of currency units and the >>>>> transactions intended to be applied to them) which can be passed around >>>>> over secure Web sockets (wss:// protocol over port 443). >>>>> >>>>> >>>>> So... in my mind, it seems our digital "wallets" or "accounts", or >>>>> whatever we call the things that send and receive transactions and are the >>>>> "physical" homes for our digital money, should each only be assigned to one >>>>> and only one *fully qualified domain name* such as " >>>>> usd1.davelampton.com <http://usd1.davelampton.com>" for example. An >>>>> FQDN is simply an assigned hostname controlled by the domain owner, who can >>>>> point it at any host or device on his or her domain subnet, by using DNSSEC >>>>> <http://www.dnssec.net/>, specifically (i.e.we would probably need to >>>>> insist on the adoption of Secure DNS, since standard DNS has known security >>>>> flaws). A new type of resource record would need to be used, perhaps a >>>>> "CTX" record for "currency transaction exchanger"??Anyone controlling a >>>>> FQDN controls the (necessarily homogeneous) currency units (money) held in >>>>> the one CTX residing there, period. No password needs to be known or saved >>>>> by the stupid humans. (No passwords using "123456"!) Thus >>>>> >>>>> far, I'm yet to be really convinced any separate IdP is even >>>>> required once endpoints are secured by a unique hostname (FQDN)... more >>>>> discussion on that later(*). >>>>> >>>>> >>>>> Someone asked: >>>>> >>>>> > How will the request to this identity provider location/URL be >>>>> authenticated? >>>>> So my answer to this is simply to use ZoneSigner < >>>>> https://www.dnssec-tools.org/wiki/index.php/Zonesigner>, a DNSSEC >>>>> tool used to secure the reverse delegations. >>>>> >>>>> >>>>> >>>>> When an end user creates an account with the clearing house (or >>>>> central bank, or whoever is clearing transactions on that currency), a new >>>>> unique keypair is generated and assigned - private keys saved and public >>>>> keys shared only by those two parties. One unique keypair per CTX account - >>>>> and only one CTX account per FQDN. >>>>> >>>>> >>>>> In general, the Peer-Assisted Key Derivation Function (PAKDF) as >>>>> suggested by Evan Schwartz is a great solution for turning a weak password >>>>> (the kind humans can remember) into a strong signed key. If a unique >>>>> keypair is generated by the clearing house / central bank for that currency >>>>> and then assigned to the corresponding account/wallet nobody else will ever >>>>> know or manage any server or account/wallet passwords other than for >>>>> server/endpoint administration, perhaps. We can thus begin and end with >>>>> strong keys and not bother with the human incapacity for remembering >>>>> important things. I don't think it's even necessary for anyone to know a >>>>> password other than possibly for the Web-based administration interface to >>>>> manage the hosted transaction services. >>>>> >>>>> >>>>> Now, in my own proposed (work-in-progress) solution, something >>>>> akin to your "Telehash" service would be hosted by the clearing house / >>>>> central bank of the corresponding currency itself and is responsible for >>>>> auth/auth of incoming requests for services, the immediate transaction >>>>> approval or disapproval, the immediate processing of each of those >>>>> transactions, and the updating of the public distributed database which >>>>> keeps tabs on each outstanding piece of currency (after already publicly >>>>> invalidating the previous FQDN's ownership hash for that unit of currency >>>>> prior to generating and publicly sharing the newly signed ownership hash. >>>>> Anyone can test any piece of currency in the marketplace at any time, but >>>>> only the current owner will get a matched signature, because their FQDN was >>>>> used to generate the current hash value stored with the currency's serial >>>>> number in the publicly distributed database. >>>>> >>>>> >>>>> (*) A bit more discussion: an FQDN is literally as close as we get >>>>> to something physical on the Internet because it IS physical and relatively >>>>> static. By attaching software objects to FQDN's we achieve a "physicality" >>>>> presently missing in the digital realm. This physicality implies true >>>>> uniqueness at all times - just like real cash. A digital entity (in this >>>>> case, some unit of digital cash) can move in the digital universe only when >>>>> a transaction is approved and executed, and may only exist in one place at >>>>> a time (namely, its current, pre-approved home). This is what is required >>>>> for money to only belong to one individual (account) at a time, only after >>>>> issued a new UUID and after previous incarnations have been publicly >>>>> invalidated already and marked for removal at some convenient time. Perhaps >>>>> Dave Longley's last comment alludes to this but I would emphasize that no >>>>> separate IdP is required - one's clearing house or central bank for the >>>>> currency being held in a >>>>> particular wallet effectively becomes the IdP. Each wallet can >>>>> only hold currency issued or managed by the clearing house / central bank >>>>> that issued that money (accounts themselves acting here as the user's >>>>> identity service provider). I think this concept of physicality can (and >>>>> should) be expanded to lots of other "nouns" that we would like to have >>>>> live in only ONE place at a time in our digital universe (the whole Net or >>>>> perhaps just a local subnet). As long as each one is *uniquely* attached to >>>>> a FQDN (or another software object that is already attached to a FQDN, >>>>> potentially ad infinitum...) and each previous instance (in some other >>>>> physical location) has been publicly invalidated before the newly created >>>>> instance arrives in its present destination, then we can trust its >>>>> uniqueness. >>>>> >>>>> >>>>> OK, I'm probably rambling now... while I could go on and on, I've >>>>> probably already ruffled more feathers than perhaps I should in one day. >>>>> >>>>> >>>>> Cheers. ;-) >>>>> >>>>> >>>>> >>>>> Dave Lampton >>>>> _@dave_lampton <https://twitter.com/dave_lampton>_ >>>>> _DaveLampton <https://www.facebook.com/DaveLampton> >>>>> +DaveLampton <https://www.google.com/+DaveLampton>_ >>>>> www.linkedin.com/in/davelampton/ <http://www.linkedin.com/in/ >>>>> davelampton/> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jun 11, 2014 at 3:03 PM, ☮ elf Pavlik ☮ < >>>>> perpetual-tripper@wwelves.org <mailto:perpetual-tripper@wwelves.org>> >>>>> wrote: >>>>> >>>>> On 06/10/2014 06:25 AM, Manu Sporny wrote: >>>>> > TL;DR: There is now an open source demo of credential-based >>>>> login >>>>> > for the Web. We think it’s better than Persona, WebID+TLS, >>>>> and >>>>> > OpenID Connect. If we can build enough support for Identity >>>>> > Credentials over the next year, we’d like to standardize it >>>>> via >>>>> > the W3C. >>>>> Congratulations! >>>>> >>>>> I find it very impressing especially since you got running >>>>> pushed to a >>>>> public repo - kudos++ >>>>> >>>>> First question coming to my mind: >>>>> >>>>> "The way that both Mozilla Persona and OpenID do it is fairly >>>>> similar. >>>>> OpenID assumes that your email address maps to your identity >>>>> provider." >>>>> >>>>> In my case, and I believe nowadays quite many other people, I >>>>> control >>>>> domain which I use for email address. With simple DNS >>>>> configuration I >>>>> use different 'providers' for my email server and my web >>>>> server (here >>>>> myself). >>>>> In this situation I find using webfinger[1] (also used by >>>>> OpenID >>>>> Connect), more attractive then hiding from myself via >>>>> http://login-hub.com - even if His Holiness @Pontifex with >>>>> His Holiness >>>>> @DalaiLama would run it very carefully together ;) >>>>> >>>>> I still need to take some time and wrap my head around your >>>>> design but >>>>> maybe you could easily evaluate complexity of including >>>>> webfinger based >>>>> flow as an alternative option for those who may prefer such >>>>> setup? >>>>> >>>>> Once again - GREAT WORK!!! >>>>> >>>>> [1] http://webfinger.net >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >
Received on Friday, 13 June 2014 09:32:17 UTC