Re: Rise of the machines - use cases for digital cash (was Re: Proof of Concept: Identity Credentials Login)

Found this;   http://newsoffice.mit.edu/2014/whos-using-your-data-httpa-0613  Which in-turn relates to http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf 

Which in-turn (IMHO) has a good relationship to melvin’s work with http://webcredits.org/  (as his essentially ‘webized’[1] the block chain).

As soon as service providers get involved; accessibility to ‘accountability’ becomes more difficult or more expensive.  IMHO, Trust is earned, and accountability is an important part of that lifecycle.

ATM; it’s very difficult to financially reward people who meaningfully contribute towards something they believe is of value for others, in the future. The amount of plausible business cases, that works such as web payments can create, support, make commercially viable or equally; diminish the commercial viability via new risk-factors of formerly unenforceable, yet difficult to track - formats of behaviour? (e.g. we all hate spam i’d imagine.)

I think; if accountability were a more ‘ubiquitous’ concept, practically delivered as a consistent, accessible constituent of using different internet applications…

Well, when sending a well described, new an innovative business opportunity - to a large multi-national; i’d pay for the stamp, in return for the priority date.  For a warrantee on a product i purchased - i’d prefer my receipt to be stored in association to my identity, or the person for which i gifted the product; in return for the knowledge, i still had a proof of purchase available, if the product did not meet lifecycle expectations.

If organisations are systemically overcharging customers and an online form became available to track the reality of usage against the digital receipt - i’d happily provide information to the organisers of that enquiry, to see if something can be done. 

IMHO - it is not in the interests of any person to revoke identity; but rather, be provided the opportunity to use it for meaningful purpose. 

therein; accountability is important, syntax is important - to ensure the different ‘use cases’ support the functional requirements of users; and, identity is important.

‘privacy’, or the ability for a person to control their own identity - is also really important. WebID[2] has been working in this field also; over many years.  Some elements of the specification are supportive, others are not compatible.

I particularly do not like the use of the term ‘agent’ in the context of identity services; however, believe it is possible that the ‘identity credentials’ element of the Web-Payments standards; may form a reasonable format or syntax, in which a person declares ownership over a RWW [3] Cloud Storage[4]; and, whilst i understand that trying to describe some of these semantics implicit within the works, becomes largely impossible (often because the parties need to consider / understand the concept of linked-data); it is my view that FOAF seems to be a reasonable, very reasonable method; for a Person (as described by identity credentials) to create a persona (as described by foaf); which could be stored by the user, perhaps most-often within an institutionally managed platform; facilitating an array of functionality not similar to that experienced throughout this era, of web 2.0.

I think it’s important to consider that whilst we all might have the best intentions; the ability to seek a better path, and the ability to meaningfully define one; different things.  

Some of the ‘threats’ (or opportunities, depending on how it’s viewed) is that linked-data could be used to develop bigger information portfolios about individuals / users.  The best way to prevent this, is to ensure clear definitions are provided around who owns an account.

surely; a hosting provider would never claim to own or have rights to information contained within systems belonging to Facebook.com - or similar.  yet, for users, poor people - most people - it’s simply not that easy…

So, I vote for identity.  I think it’s important; and with identity, people with identity can be furnished with important digital assets of commercial, tangential or material importance to them.

[1] http://www.w3.org/community/webize/
[2] http://www.w3.org/2005/Incubator/webid/spec/
[3] http://www.w3.org/DesignIssues/ReadWriteLinkedData.html
[4] http://www.w3.org/DesignIssues/CloudStorage.html

On 14 Jun 2014, at 8:43 pm, Ricardo Varela <phobeo@gmail.com> wrote:

> hallo all,
> 
> exec summary of what I'm about to say: Fees are good. I think we should stop thinking that fees are the problem because there are reasons why most systems end up having some kind of charges: to ensure they can keep running (and paying the people that run them, if possible)
> 
> Just thought I should add something to this comment:
> 
> "To be honest, I arrived not with a spec or even a goal in mind, but rather just some observations about our online payments, that 1) when I pay online there's always somebody between me and the person I'm trying to pay, 2) the transaction often does not happen immediately, there is often some waiting period and 3) Quite often one or both of the participants must pay a transaction fee."
> "Then I noticed that these characteristics all disappear when I pay cash. It's 1) DIRECT, 2) IMMEDIATE & 3) FREE. Incidentally, there is at least one other observation, 4) I get my change in cash"
> 
> I think that analogy is actually a bit misguided. There is a third party involved in EVERY transaction where there is no direct trust between you (the person paying) and the merchant (the person receiving). A party you both have to "trust" or the transaction cannot occur. In the case of cash it's the Government, who issues the cash both you and the merchant trust, and there is actually a "transaction fee" involved that depends on the volatility of currencies and goods' prices (plus any exchange rates if you and the merchant don't use the same currency). That difference exists even if the transaction occurs in a single currency, it's just that we dismiss it because normally its very small for established currencies - Take a situation like what happened in Zimbabwe post-Mugabe where inflation was changing so much that prices doubled every 24 hours or so and you can see how this may play a role
> 
> When another organization (say a payment provided or clearing house) gets involved, they bear the risk that normally is associated with carrying that trust (as well as other things like ensuring the money gets from you to the other person). They have to somehow charge for running the processes that ensure you get your money at the end because there are costs involved (even if you operate a wonderful time bank exchange page there is at least server costs, right?), therefore the fees.
> 
> Now, if the discussion is about how the modern organizations doing this are charging us too high fees, that is another thing. I think as it has happened before in history there will be (there are already, even) incumbents coming and making those prices go down and you as a consumer will have to "vote with your wallet", and that maybe standardisation can help those incumbents a bit... but as to whether the new organizations taking on this challenge will charge fees, that is completely up to them, let's not start by putting them in a disadvantageous state by saying "by the way I want all new payments systems not to charge fees because only evil financial systems charge fees"
> 
> (PS: I'm including on "fees" here any other type of monthly subscription charge that gives you unlimited transactions or any other way for the organization to actually get money to run the service, not necessarily just "per-transaction fees". My point is that companies HAVE to charge, not how they do it)
> 
> Saludos!
> 
> ---
> ricardo
> 
> 
> 
> On Sat, Jun 14, 2014 at 5:39 AM, Tim Holborn <timothy.holborn@gmail.com> wrote:
> 
> On 13 Jun 2014, at 11:29 pm, Dave Lampton <dave.lampton@gmail.com> wrote:
> 
>> I was going to shut-up, but since you asked...      (the crowd moans...)
>> 
>> > Sounds like what your trying to achieve, actually relates to privacy & simple user experience / ease of use.
>> 
>> To be honest, I arrived not with a spec or even a goal in mind, but rather just some observations about our online payments, that 1) when I pay online there's always somebody between me and the person I'm trying to pay, 2) the transaction often does not happen immediately, there is often some waiting period and 3) Quite often one or both of the participants must pay a transaction fee.
>> And then I wasn't seeing any of those four issues being addressed and so I guess I instinctively just started brainstorming on solutions.
>> while in the physical world I pay whoever I want and there's no waiting, no fees.
>> Then I noticed that these characteristics all disappear when I pay cash. It's 1) DIRECT, 2) IMMEDIATE & 3) FREE.
>> incidentally, there is at least one other observation, 4) I get my change in cash. [ we haven't even gotten close to that part yet. ]
>> Actually more like a simple emulation of physical cash (for lack of a written spec). Privacy, was not really a driving force for me in any of this, however, a realistic emulation of money would include the advantage of privacy, so sure, let's expect privacy... besides, nobody watches anything we do on the Internet, right??  ;-)   Making it as simple as cash, an admirable goal.
>> 
>> >The web-payments standards provides a language or syntax around how different "elements" involved throughout the "chain" can >interact in a standardised fashion.   Many of the ingredients to what your talking about, are part or in-scope for web-payments (IMO); other areas are not.
>> 
>> Right, and I really didn't know what Web payments meant exactly think there are going to be common to all transactions and maybe others that are unique to some situation. I don't intuitively expect a clean separation of concerns to exist. 
>> 
>> >If your solely hosting a service at home: what happens if your at a cafe, and your kid has turned off the power accidentally, or the repo man decides they'll take it - till you pay your bills.  I'm just making up user-stories, but of course, these situations and business cases can be extremely complicated.
>> 
>> Yes, short answer: don't know, don't care, it's your problem. That's like going to the supermarket but forgetting your wallet at home, in that, your inability to pay for your groceries was in no way caused by any inherent flaw in our currency! Bottom line, if you want to pay or get paid - your digital wallet must be powered-up, online and ready for transactions! There's nothing any of us can do to keep your kid away from the machine - your problem. I'd prefer the hosted leather solution you carry in your back pocket, kinda like a, oh yeah, wallet.
>> 
>> >I think ipv6 subnet pools are being issued to existing ipv4 subnet owners.  I queried Vint Cerf about using ipv6 addresses in a similar way, his exact words were "IPv6 is a topological identifier and should NOT be used as a logical one."...  (And I was really thankful for his response...)
>> 
>> So wherever you see an IPv4 node today, someday in the future that same location will have <some_giant_number> - minus one, of unique endpoints now available.
>> 
>> >I'll follow-up more tomorrow, but continue to encourage you to get involved, and influence how these standards work in the >interests of the people.  
>> 
>> I will mostly just watch and learn but I'll speak up if I do see anything you guys have missed.
>> 
>> >The suggestion that fqdn's should be owned by all email address holders - or as similarly described - I think, has great purpose >and is well-worth pushing forward. Not in scope for webpayments specific however....
>> 
>> No, that seems like it would be entirely at the discretion of the guy who paid for that server! :)
>> But seriously, what then, have you gained at that point by having chosen to use a FQDN? Why did you choose to use an FQDN in the first place? For me, the FQDN itself establishes the identity of the wallet hosted there. Nobody needs to know whose wallet but only that it has uniqueness like a real physical wallet it can only exist in one place at a time - that digital wallet is has a "physicality" that most software objects never have. To me, this"physicality" is an exciting and new concept we're inventing. Note that it can also be extended if other software objects then somehow attach themselves they too have gained "physicality". The concept is so new, we don't even know yet if it has real significance, my gut is that it definitely will have some new characteristics we can exploit.
>> 
>> specifies one specific machine that will be responding to the IP number pointed to by the FQDN. 
>>  if you're wanting to use an FQDN for the same reasons I was, then by allowing a bunch of people to send and receive emails from your digital wallet you've already compromised your wallet's security by letting all those people physically access it.
>> NOTE: Humans should not be physically allowed to login to or otherwise use digital wallet machines, at least not when that wallet is connected and available. I wouldn't trust anyone to be logged in to my digital wallet for ANY reason. hey, that's your real money living there, you don't want to allow anyone to mess with it so, protect it as well as your physical wallet.
>> 
>> >More broadly; some work will fall into scope with web-payments, some will not.  Some with w3c, some not.  Don't throw the baby >out with the bath water... ;) 
>> 
>> OK, I think by my focusing on my own specific requirements, I had already inadvertently stopped being helpful to the Web Payments group and was now a lone wolf.
>> 
>> >Perhaps, re; use-cases or user stories around "digital cash".  A swot analysis...  Might help us (or me at least) figure out, or validate >the requirement and a possible approach...
>> 
>> Yes, I was thinking we might be about ready for that. I'm hoping that the two use cases I have in mind will truly be the ONLY two use cases for these little guys to take care of: Send & Receive.
>> 
>> OK, sure as long as the rest of the group is not annoyed by being pretty far out of scope with my discussions.
>> 
>> Just 3 steps, Step 1: Sender notify's Receiver of the send request. and forwards her own public key.
>> In a Send request, first a human defines the SendTo: address (FQDN) and the amount and hits Send.
>> 
> http://melvincarvalho.com/blog/introducing-web-credits/
> 
>> Step 2: Receiver confirms or rejects based on the single acceptable currency type it can handle, in this case USD.
>> Receiver then forwards all info to the Clearing House / Central Bank. adding to it her own FQDN
>> >What characteristic are you trying to protect by eliminating identity (of the payee? I assume??)
>> 
>> Ha, I love this question because it makes me seem so proactively benevolent, yet in reality, I had no such lofty concerns! :) Truth is, I simply have not yet found a single reason why my digital wallet needs to confirm anybody's identity.Tell me one scenario in which my wallet needs to know who anyone is. This is what I can infer: The Central Bank has no meaningful Identity, so only Sender and Receiver are left. The Sender knows nothing about the identity of the Receiver other than their FQDN.
>> 
>> Step 3: The Central Bank receives the confirmed payment request form and first confirm sender's ownership when the signatures match. Next, the current(old) owner'sownership is invalidated by removing it from the suffix and then multicasting a UDP Invalidation message to a subset of listening wallets, and in turn those wallets all delete this message if they have it. This might be a shard in a clusterd mongodb array, or any of many other scenarios. Now the Central Bank, takes the Receiver's public key and uses it to create and attach the new suffix and then send it to be physically attached to that Receiver (the new current owberthe currency to the Receiver. And finally, the Central Bank sends out a  UDP Receipt message to some subset of listeners this time telling the world the serial and suffix of the next currency under new ownership. Both Sender and Receiver are sent their copies of the receipt message which acts as the new ownership doc.
>> 
>> >POC examples on GitHub (or similar) really very important for this area of work.  The more people get into community works, the >better...
>> 
>> Yes, this has been tricky because there are 1001 ways to do the implementation, and still do it well enough. I think all you really need is a service that says it can do the send & receive jobs of a wallet... do we just say ok and trust it? Or what makes us trust it? Answer: only people can make these decisions. People decide, and yes I think maybe we can just trust it. If it can't really do the two jobs a wallet knows how to do, then no money will be going anywhere because apparently that wallet is broken or something.
>> 
>> OK, the reason a stab at a POC hasn't been taken is because I've changed my mind on the platform a few times already. One example that could work just fine is that the wallet is implemented as a 2002-style SOA architecture using WSDL and SOAP XML. Sounds way too much of PITA if we just need to host two services? Send & Receive. I only mentioned this one to show, yes that would work fine, but it sure sounds like a lot of work to me. SOAP & WSDL? yuck.
>> 
>> What's another way? How about a simple Ruby on Rails App? With two services built out? Yup, this can also work.
>> 
>> As you can already see there are a ton of ways to do this... BUT, what would you suggest as the easiest way? What do you need in place?
>> 
>> OK my initial reaction here was to use Meteor on Node.js because I was already thinking in terms of independent little entities that can move from one host to another host, that sounds just like money changing hands doesn't it? Node provides a way to deploy the same single unit of code to every server and the server will know which parts it should send to the client if/when necessary. This too would work just fine.
>> 
>> But my preferred solution may surprise you, especially if you haven't even heard of it (yet). I'm currently proposing that every wallet endpoint should be a Docker app. Then, there are plenty of different solutions for hosting that app, in fact in it's current Docker container, it can already run on any Linux machine, but I am choosing to run the smallest Linux distribution around, CoreOS and it just happens to come with a Docker installation ready to host any Docker App like the one we just created!
>> 
>> 
>> >Imho, nothing on the web is anonymous.  Therefore, you actually mean identity displacement.  Systems are already in place to >ensure something is anonymous, save a court-order, it seems this is not enough for some of your use cases??  Or is it a problem >relating directly to the "cost" of a transaction?    
>> 
>> I'm not actually sure who brought the word anonymous to the table, because it's not a concern of mine. I was waiting to explain an earlier situation? OK, I don't know who she is`
>> 
>> >Like a pebble in water, it's impossible for an action not to leave traces or ripples...  Therefore, to me, the answer is about >accountability more than trying to find a better, darker, more secret place.  I don't particularly like the golden rule - he who has the >gold rules...  I like the concept of an egalitarian meritocracy....  Which absolutely means, success depends upon accessibility to t>he rule of law; over and above, "the golden rule"...  
>> 
>> OK, since I wasn't the requester of the anonymity, I can only speculate what she was looking for so for now I will skip this. In my mind, to "need anonymity" one must already have established their Identity, yes? (well I told you not to!)  ;^)
>> 
>> >Give the people identity - support, without improper barriers, what is best described in the texts of 'human rights' conventions - >democracy will thrive.
>> 
>> But, that's just my opinion...
>> Well the digital wallets are stupid and know nothing about the person that owns them and so is able to divulge a thig
>> 
>> And 50 years is too long.  In fact, given the growth and capabilities of entities around the world, I'm surprised so many people are giving their time away freely to define something today, over the next few years, that should have really existed for some time already...  
>> 
>> Oh, I can answer:  It is actually BECAUSE it should have already existed for some time, but hasn't.! Unacceptable situation!  :)
>> 
>> Says something about priorities I guess...
>> 
>> 
>> Dave Lampton
>>  @dave_lampton
>>  DaveLampton
>>  +DaveLampton
>> www.linkedin.com/in/davelampton/
>> 
>> 
>> 
>> 
>> On Fri, Jun 13, 2014 at 2:39 AM, Timothy Holborn <timothy.holborn@gmail.com> wrote:
>> You've hit on numerous topics I've had quite some interest in overtime...
>> 
>> Sounds like what your trying to achieve, actually relates to privacy & simple user experience / ease of use.
>> 
>> The web-payments standards provides a language or syntax around how different "elements" involved throughout the "chain" can interact in a standardised fashion.   Many of the ingredients to what your talking about, are part or in-scope for web-payments (IMO); other areas are not.
>> 
>> If your solely hosting a service at home: what happens if your at a cafe, and your kid has turned off the power accidentally, or the repo man decides they'll take it - till you pay your bills.  I'm just making up user-stories, but of course, these situations and business cases can be extremely complicated.
>> 
>> I think ipv6 subnet pools are being issued to existing ipv4 subnet owners.  I queried Vint Cerf about using ipv6 addresses in a similar way, his exact words were "IPv6 is a topological identifier and should NOT be used as a logical one."...  (And I was really thankful for his response...)
>> 
>> I'll follow-up more tomorrow, but continue to encourage you to get involved, and influence how these standards work in the interests of the people.  
>> 
>> The suggestion that fqdn's should be owned by all email address holders - or as similarly described - I think, has great purpose and is well-worth pushing forward. Not in scope for webpayments specific however....
>> 
>> More broadly; some work will fall into scope with web-payments, some will not.  Some with w3c, some not.  Don't throw the baby out with the bath water... ;) 
>> 
>> Perhaps, re; use-cases or user stories around "digital cash".  A swot analysis...  Might help us (or me at least) figure out, or validate the requirement and a possible approach...
>> 
>> What characteristic are you trying to protect by eliminating identity (of the payee? I assume??)
>> 
>> POC examples on GitHub (or similar) really very important for this area of work.  The more people get into community works, the better...
>> 
>> Imho, nothing on the web is anonymous.  Therefore, you actually mean identity displacement.  Systems are already in place to ensure something is anonymous, save a court-order, it seems this is not enough for some of your use cases??  Or is it a problem relating directly to the "cost" of a transaction?    
>> 
>> Like a pebble in water, it's impossible for an action not to leave traces or ripples...  Therefore, to me, the answer is about accountability more than trying to find a better, darker, more secret place.  I don't particularly like the golden rule - he who has the gold rules...  I like the concept of an egalitarian meritocracy....  Which absolutely means, success depends upon accessibility to the rule of law; over and above, "the golden rule"...  
>> 
>> Give the people identity - support, without improper barriers, what is best described in the texts of 'human rights' conventions - democracy will thrive.
>> 
>> But, that's just my opinion...
>> 
>> And 50 years is too long.  In fact, given the growth and capabilities of entities around the world, I'm surprised so many people are giving their time away freely to define something today, over the next few years, that should have really existed for some time already...  
>> 
>> Says something about priorities I guess...
>> 
>> Nite.
>> 
>> Timh.
>> 
>> Sent from my iPad
>> 
>> On 13 Jun 2014, at 7:00 pm, Dave Lampton <dave.lampton@gmail.com> wrote:
>> 
>>> hi Tim,
>>> yes, I may need to depart from this group soon as I agree my goals extend beyond just Web, and while I'm not sure if it will end up as a protocol, it might just be a "service specification" for every "wallet" endpoint - would likely belong with IETF.
>>> I'm calling it 'cash' only because two entities will be able to conduct a transaction without a middle-man, nobody ever taking a piece of the action. these transactions occur in real time and are as final as handing someone a paper bill
>>> I won't be printing any paper receipts, but details are always available - just point your browser at your wallet's FQDN.
>>> I'll want to specify the software stack at the endpoints, which may be spec'ed all the way to bare metal
>>> rather than having many use cases that resemble "making an operating system with better GUI",
>>> I'll have a small handful of use cases that more resemble the simplicity of flushing a toilet. :)
>>> well, identity displacement seems adequate, but I doubt my system will even include any concept of Identity
>>> I'm not really concerned with anonymity at the time of the transaction, but instead simply concerned
>>> with ensuring that "money has no memory"
>>> "I must always be able to track my spending, but my spending should never be able to track me"
>>> Adrian was right that the scope and goals of my project are broader than just Web
>>> I'll probably need to revisit the creation process for a new protocol under the IETF (check back with me in 50 years! ;-)
>>> There is a crypto-currency called ZeroCash (which is based on BitCoin) and is really quite close to reaching all of my intended requirements, however, my intent to be capable of transacting with a nation's real currency as issued by their central bank.
>>> I fully understand the issues involved in managing your own FQDN but we don't have the same goals. I won't be developing a lightweight payment system, but instead, more like your own fully-capable business checking account (but without the bank, and hosted at home, perhaps) by an individual who actually *needs* all of that extra functionality and is capable of managing his registrar and his DNS. In any case, IPv6 is around the corner and every man woman and child on the planet will have <some_huge_number> of IP addresses at their disposal. I imagine that managing one's registrar and configuring one's DNS for each wallet endpoint will be about as complex as buying yourself a wallet. also, trivial & common enough that having them managed and/or virtually hosted for you will be so common that the expenses will likely be tiny fees, or you can set one up on your smart phone. etc. not only will more & more "average citizens" be able to do these things, but there will also be plenty of cheap hosted/managed solutions available.
>>> 
>>> Dave Lampton
>>>  @dave_lampton
>>> www.linkedin.com/in/davelampton/
>>> 
>>> 
>>> Dave Lampton
>>>  @dave_lampton
>>>  DaveLampton
>>>  +DaveLampton
>>> www.linkedin.com/in/davelampton/
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Jun 12, 2014 at 11:12 PM, Tim Holborn <timothy.holborn@gmail.com> wrote:
>>> I can, and will write a volume or two about this area (identity, privacy, anonymity, etc.): however, figure it’s not something for the list, and in any case; it’ll need some editing…
>>> 
>>> When the terms ‘digital cash’ and ‘anonymity’ is concerned; are you talking about entirely anonymous? or identity displacement? 
>>> 
>>> Perhaps as an exercise; consider the instances where your identity as a purchaser, or payee becomes ‘anonymous’ (meaning, cannot be proved); vs. those where identity remains intact throughout the lifecycle of what #upaid4  or #uvoted4 
>>> 
>>> Could be retaining a readable receipt (i.e. not thermal receipt printing) from a retailer.  Could be something that forms the world of online content, could be an email with a proposal put into a powerpoint or business plan format. Many use-cases…. 
>>> 
>>> Another good activity; is looking at the manifest forms of social-policy decisions made; that could benefit if you a. had data relating to your economic footprint, and b. were entitled to actively share elements of that data, in a structured format; as to support research.
>>> 
>>> Whilst I absolutely believe enormously beneficial to encouraging users with an Email Address - to migrate towards owning and operating their own domain - it’s not specifically within the ‘domain’ of web-payments.  Perhaps it’s something that could be formally supported by the group; should an appropriate group become recognisable, in how to push that form of promotional activity (Not for profit styled) to web-users.  I also think part of that function, requires improvements to traditional domain-management tools.
>>> 
>>> A bit like making an operating system with better GUI. 
>>> 
>>> On 12 Jun 2014, at 11:30 am, Dave Lampton <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" 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, 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, 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
>>>>  DaveLampton
>>>>  +DaveLampton
>>>> www.linkedin.com/in/davelampton/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jun 11, 2014 at 3:03 PM, ☮ elf Pavlik ☮ <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
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> 
> 
> -- 
> Ricardo Varela -  http://twitter.com/phobeo
> "Though this be madness, yet there's method in 't"

Received on Saturday, 14 June 2014 12:21:51 UTC