- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Fri, 13 Jun 2014 22:40:47 +1000
- To: Dave Lampton <dave.lampton@gmail.com>
- Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments CG <public-webpayments@w3.org>
- Message-Id: <67371522-74BB-4EEB-B058-78B62651B914@gmail.com>
3d printer, gold "ink", connected to some form of destructible bitcoin tech. Not sure what happens when the printer runs of of ink half-way through a print. Or jams, takes the digital coin, and forgets to print your gold. And of course, the ink would be worth as much as the coin printed with the ink, so arguably, using electricity to transfer the ink or use it to print it into a different "product structure" is arguably a form of depreciation, depending in energy efficient, cost of time, etc. Or given the status of the fiat economy, perhaps it doesn't need golden ink. Just an insignia that is recognised, printed on a cheaper material. Yet, in your use-case of "rise of the machines", I'd argue a multitude of resources would become far more valuable than gold, with better liquidity than cash... Litre of fuel. Specialised pharmaceuticals. All sorts of things... Still, I believe the rule of law is the best form of currency derivative... It's just not as accessible as it should be, to far too many people.... Mind, knowledge is perhaps more valuable. Perhaps. Depends on provenance... Hehe.. In anycase. I haven't been able to nail down where digital "cash" is required. Perhaps though. Voting or petitioning is a good business case. How could a majority of people, seek to vote on a subject for which they may be persecuted for participating in any such vote or being a signatory to a petition, which held a controversial view... On one side. It's important to validate real people voted, once each. Etc. On the other, it may be dangerous to or people may be fearful of putting their name on the vote. Perhaps if voting on civic issues became a daily thing: every council meeting, or whatever the local government in your area is called: perhaps people would become persecuted if they continued to contend a particular view. Actually, in reality - most countries have an anonymous voting system. The reasons for that, are well founded in our democracies. How's that done digitally...? I imagine, that provides a similar argument to your notions around digital cash?? Timh. > On 13 Jun 2014, at 7:31 pm, Dave Lampton <dave.lampton@gmail.com> wrote: > > Not to mention that following the rise of the machines, my new digital cash system will no longer be optional. ;-) > > Dave Lampton > @dave_lampton > DaveLampton > +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 >> DaveLampton >> +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 >>>> DaveLampton >>>> +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 12:41:26 UTC