Re: USE CASE: HTTP URI denoting a Bank-Account?

For the service portion of what I'm piecing together for each "wallet" or
"account" (the software running at each FQDN), I'm using Meteor/Node.js to
develop the concept of a central bank-backed currency unit that is
specified as JSON-LD (most likely loosely based on some of the elements of
https://schema.org/PriceSpecification). The key attributes will be a
central bank identifier, a unique permanent serial number, a timestamp of
the last transfer of ownership, a UUID serial number suffix (32 hex digits)
that encodes the current owner (identified by their FQDN) and a UUID that
represents the previous (now publicly invalidated) owner. A currency holder
who wishes to pay someone sends a pay request to the recipient's FQDN, the
recipient confirms their ability to receive the payment by then forwarding
the request to the central bank for real-time clearing along with their own
FQDN. Upon receiving a valid request, the central bank simply confirms
sender is the current owner by using sender's FQDN to decode the serial
number suffix thus confirming the identity of the current owner, then uses
a new timestamp with the new owner's FQDN to generate a new serial number
suffix, simultaneously invalidating the previous value of current owner.
Lastly, the software running at the central bank (different from what is
running at all the wallet nodes) multicasts (via UDP datagram) the
confirmation to a subset of distributed databases living at all the wallet
nodes AND sends an identical, detailed receipt to just the sender and
receiver. The distributed database of all transactions will most likely be
stored in a sharded MongoDB cluster... or perhaps in an Apache Kafka sort
of multicast messaging scenario. I will probably try both and see which
feels like a better match. Mongo is becoming so ubiquitous that it's almost
trivial to simply have a local mongoDB instance running as part of the
standard wallet platform. Kafka handles a huge amount of data easily and
partitions its data automatically. Some experimentation will reveal the
best fit.

This morning I'm working out the details of encoding the UUIDs and decoding
them to reveal the current and previous owners. An important characteristic
of my proposed solution is that "money should have no memory". Nobody
should be able to know who owned a piece of currency before the current
owner, except the current owner will know who owned it before them, and
lastly, the central banks can and probably will want to log all
transactions over time, so they would be able to see who was the owner of a
given piece of currency going back until its initial introduction by the
Federal Reserve System at some point. (In the US, it's a bit odd because
the Dept of the Treasury actually issues the currency, but I don't think it
really needs to be tracked until its original ownership by the Federal
Reserve.)

that's all for now. Oops, maybe I should think about sleep at some point
too.  :)

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 Wed, Jun 4, 2014 at 2:08 AM, Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> I do absolutely prefer users have their own fqdn...  It's a no-brainer to
> me, whilst I also appreciate the difficulties most people experience
> managing a domain and that poorly deployed fqdn's for individuals, may
> end-up with greater potential harm of lock-in, than simpler addresses..
>
> However,
>
> Given these types of addresses can simply be a method to 'denote' a
> payment location for the Purposes of sending money to an address, at
> web-scale, I guess the devil is in the detail.
>
> Certainly, your notes about digital cash got me thinking...  :)
>
> I think webcredits can do the crypto stuff; but I'm not sure of the
> identifier structure.  In your text, you suggested some form of DNS record
> attached to a domain.  I imagine that is certainly a very positive gateway
> method, and certainly. DNS for subdomains could be directed as you
> suggested previously, in different ways to connect to different financial
> servers.
>
> I guess, the other constituent was that say a service exists to send money
> to others.  Others can say how they want to be paid, perhaps an address is
> generated to pay an array of people, in an array of different formats, for
> percentages of a transaction.
>
> Bitcoin addresses are easy.  What is more difficult is finding some way of
> having an address that, say, denotes I want money to go into my Aussie bank
> account called "rewards for good internet technology contributions".  It
> might have no funds in it, and is simply there (akin to an account linked
> to a PayPal address) for the purposes of. Receiving those funds, via my www
> identifier.
>
> Banks hate bitcoin.  But the simple reality is, they've provided no easy
> alternative.  I can buy a bitcoin (which is strictly unnecessary step) then
> plug in the address of someone else who's got one, and send them "funds". I
> can't do that easily with my Aussie bank account.   So in terms of the
> functionality scope for web-payments standards, seemed like an important
> use-case to ensure was included as part of the scope of works...
>
> Perhaps how it works is a different part of the process again...
>
> Sent from my iPad
>
> On 4 Jun 2014, at 6:55 pm, Dave Lampton <dave.lampton@gmail.com> wrote:
>
> Certainly not going to appear to be a problem on the surface, but I feel
> it's a vulnerability, yes.
>
>
> 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 Wed, Jun 4, 2014 at 1:50 AM, Timothy Holborn <timothy.holborn@gmail.com
> > wrote:
>
>> Do you believe this flaw affects bitcoin addresses also??
>>
>> Sent from my iPad
>>
>> On 4 Jun 2014, at 6:48 pm, Dave Lampton <dave.lampton@gmail.com> wrote:
>>
>> Having already given this question some thought, I'd already decided that
>> a URI is probably not the best solution. It makes it too easy for one
>> server to start serving as an account/wallet for lots of people at once,
>> which may seem harmless enough at first, but it may be enough if those
>> people simply know each others' specific URIs it may be enough to start
>> gaming the system or otherwise trying to hack each other.
>>
>> Therefore in my opinion, URI specification is inadequate and
>> accounts/wallets/money bags/whatever you wanna call them should each be
>> completely specified by a FQDN (host-specific while ignoring path), such
>> that no two wallets/accounts share the same FQDN. That does also mean that
>> every possessor of a wallet must first possess a domain and/or a subdomain
>> that nobody but they control. (These can easily be managed via existing
>> registrar ownership and transfer regulations and of course, the DNS system.)
>>
>>
>>
>> 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 Tue, Jun 3, 2014 at 11:36 PM, Tim Holborn <timothy.holborn@gmail.com>
>> wrote:
>>
>>>
>>> I was wondering about how some form of HTTP URI might be provided to a
>>> bank-account customer.  Banking systems currently have an array of
>>> different identifiers that are provided between parties for the purposes of
>>> transferring funds (say, from parents to children, etc.) Existing account
>>> details work within banking systems (SWIFT codes, BSB / Account Numbers,
>>> etc.); however i couldn’t find the schema available to provide a HTTP URI
>>> of a bank account at Web-Scale?
>>>
>>> I envisage this to be similar to a crypto-currency address, perhaps with
>>> a relation to an institution?
>>>
>>> EXAMPLE (not syntactically accurate for web-payments / payswarm)
>>>
>>> whereas;
>>>
>>> IdP: bitcoin
>>> ADDRESS: 12V7BYH4jPTeeWXfEKJ1rrifizgdvkrzsU (example only)
>>> Amount: 1
>>> valueFormat; bitcoin
>>>
>>> now therefore;
>>>
>>> IdP: Westpac.AU
>>> Address: 123546799876688232234 (example only - account doesn’t exist to
>>> my knowledge)
>>> Amount $1.00
>>> valueFomat: AUD
>>>
>>> Therein; I have a foaf profile document:
>>> http://ubiquitous.rww.io/profile/card#me whereby i can list or insert
>>> my bitcoin addresses.  How can an individual create a HTTP identifier /
>>> method for a traditional banking accounts?  Equally, the address could be
>>> converted into a QRCode or other form, denoting the same details (and
>>> enabling the same transaction).
>>>
>>> Is defining a HTTP URI identifying a bank account; and, To use a HTTP
>>> URI to make a transaction to a bank-account, between institutional banking
>>> providers (?) within scope…
>>>
>>> does a method already exist (as provided by banking institutions, not
>>> via intermediary, such as paypal)?
>>>
>>>
>>>
>>>
>>
>