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

Cool! A "universal financial industry message scheme". I guess everyone
wants in on the act.  ;-)


On Thu, Jun 5, 2014 at 7:20 AM, Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> I was referred to http://www.iso20022.org/ - but haven't read-up yet...
>
> Timh.
>
> Sent from my iPad
>
> On 4 Jun 2014, at 8:21 pm, Dave Lampton <dave.lampton@gmail.com> wrote:
>
> 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)?
>>>>
>>>>
>>>>
>>>>
>>>
>>
>