Hi Adrian, Let me see if I can give a shot as to how this Trust design and the network it might engender could play a role in the sorts of transactions you mention (e.g. buying an application for your smart phone). Bear in mind I'm not any kind of expert in protocols, programming or even questions relating to privacy vis a vis transparency. In other words, I'm faking it all the way... with the hope there could be something useful here.The essence is creating a network of accounts where identity (and related info) are separate.from the payments themselves.Frankly, the motive for creating such a Trust design was not related to questions of anonymity vs. identification, but rather as a method for allowing a viable micropayment (by pooling multiple payers' signals into one transfer) which may or may not be accompanied by individual payer identification... along with one-click (one step) signalling which must have no burdensome requirements for user input of data (which would raise click through resistance to the point of impracticability.)A one-step system absolutely requires payer identification on the signalling side... but not necessarily on the recipient side. For example to donate to a candidate legalities require payer id... but to donate to a charity does not. (this is the essence of cash itself... you know you want to buy a pack of gum and make the payment... but the store clerk has no need to know your identity.)SO...in this digital wallet case... a transfer to a recipient does NOT come from an individual... but rather comes from the Trust... which may or may not be accompanied by any payers individual information except where required by law or at the option of the payer.Now the essence of the design does not confine it to the micropayment... i.e. 20 people designating 25 cents to a recipient is no different than one payer designating $5 to a recipient.However, there is a difference between the two usages I mention (charity and politics) and more general payment. In the first cases no material or digital exchange is expected other than some form of receipt confirming execution of payment.This would be a problem for purchasing an application....This could be addressed as it relates to anonymity if that's your goal... by having it (or the rights to it should the Trust already have it in its data base because of previous purchasers) granted to the Trust which then downloads it to the individual purchaser.Just exploring here... does it make any sense?And the question of whether an account holder must or should be an identified individual as opposed to some sort of encoded private key connected to an individual is also inevitably important.... as is the question of security vs transparency for the Trust (or Trusts) itself.** I contend the point of signaling for a one-click system is a natural monopoly... however it need not necessarily be one Trust but could be many similar Trusts operating through the same signalling point.Tom CrowlOn Wed, Jan 4, 2017 at 7:58 AM, Adrian Gropper < " target="_blank"> > wrote:AdrianHow should we do this?Tom,The signature(s) I'm controlling with this private key are used to authorize API transactions. These transactions need to be paid for, to or from me, depending on the API. This payment, like the use of my signature, needs to be cash, in order to preserve the anonymous, pseudonymous, or verified class of signature I use in that particular API.
I probably agree but I have a much simpler issue. I need a way to pay for API access without disclosing any PII. I already have one app in my smartphone that's essential: it controls signing things with my private key and manages restoration of that private key if it's compromised. We're currently demoing uPort for that purpose but there will be dozens or hundreds of these as standards like FIDO U2F and blockchain DID make it through the pipeline.--On Wed, Jan 4, 2017 at 10:01 AM, Tom Crowl < " target="_blank"> > wrote:Build the co-op wallet* for Internet payment.This is a link to an Act Blue donation page.... I'm sure it has some success.But the click through resistance created by the need to input multiple data fields for even a very small contribution severely limits both participation and total contribution. Sooner or later the need for a one click contribution capability.... with donor identification where needed.... and including viability for very small amounts will be realized.The wallet/cash card system for the Internet micropayment can be catalyzed more easily than it may at first appear... especially when combined with such an account's additional potentials in other areas of payment*The key is the Trust design underlying the card system whereby the user’s information and instructions are kept separate from the funds deposited which are placed in a pooled trust with other account holders funds but with each individual user retaining complete control over the dispersal of the funds within the limits of his/her share of the trust… combined in the case of the pooled micropayment with an anticipated threshold for total payment transfer to the recipient at or above the level required for system viability (a fairly low level in practice) and how this then greatly reduces transaction costs for the micropayment by passing through incurred transaction costs to the recipient at an easily manageable level. And all in conformance with legal requirements for payer/donor identification which may or may not be required in a given transaction.Tom CrowlAdrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
Archive powered by MHonArc 2.6.19.