Re: Building regulatory hooks into the payment protocols (Re: decryption strategies / requirements)

> His main pitch was that you provide the hooks for the regulators into
the protocol in a way that notifies all of the parties in a transaction
when a particular action would result in a "regulatory side effect",
like the reporting of a transaction (or set of transactions) greater
than $10K (anti-money laundering regulatory requirement in the USA).

Suppose instead of the USA this occurs in Crimea.  Does the
transaction get reported to Kiev or Moscow?  Or both?

On 26/04/2014, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 04/24/2014 09:52 AM, Timothy Holborn wrote:
>> I've been reading:
>> http://www.computerworld.com.au/article/543477/should_australians_prepare_rubber-hose_cryptanalysis_/
>>
>> Where access to your systems is required without your consent - what
>>  options of how that is done, should be available to be asserted as a
>>  preference by the user prior to any-such event of involuntary
>> fulfillment.
>>
>> thoughts anyone?
>
> Yeah, many of thoughts on that area. :)
>
> The potential solutions you provide are a good start. I think we need to
> formalize this set of use case a bit more. Perhaps if you could write
> something up on the wiki, or add a few use cases to the use cases list:
>
> https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
>
> I think the ideal place for this is something that Erik Anderson, from
> Bloomberg, was pushing at the Web Payments Workshop: Build the
> regulatory hooks into the protocol.
>
> His main pitch was that you provide the hooks for the regulators into
> the protocol in a way that notifies all of the parties in a transaction
> when a particular action would result in a "regulatory side effect",
> like the reporting of a transaction (or set of transactions) greater
> than $10K (anti-money laundering regulatory requirement in the USA).
>
> For example, let's say that you live in the USA and complete a $30K
> consulting contract. You are paid for it using web payment technology.
> By law, the payment processor must report that transaction to the
> Financial Crimes Enforcement Network. The following could be how the Web
> Payments architecture would work with that system:
>
> 1. The vendor is given the option to not continue the operation
> (invoicing the customer) and be reported to FinCEN. The customer is
> given the same option.
> 2. If the vendor and customer chooses to continue, basic information
> that will be reported to FinCEN is collected and shown to the customer
> and the vendor.
> 3. Most likely, the FBI/NSA would like to see all of the details of the
> transaction, but in the name of privacy, the customer and the vendor
> would rather they get a court order to do so. The payment processor
> would encrypt all of the details w/ at least two keys - one of them
> being a FinCEN's key specific to the transaction, the other being the
> justice department key specific to the transaction. The encrypted
> document would be sent to the justice department for storage.
>
> This approach requires at least two different branches of government to
> collude in order to read the details of the transaction.
>
> The question of whether or not the payment processor holds on to the
> transaction information is still of concern. It could be a point that
> payments processors compete on (we store your digital receipt
> information encrypted so that only you can read it).
>
> All that said, we have the basic technology in place to do all of this
> today (JSON-LD + Secure Messaging + Web Commerce specs).
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>


-- 
GENERATION 26: The first time you see this, copy it into your sig on any
forum and add 1 to the generation

Received on Monday, 28 April 2014 20:16:39 UTC