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

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/

Received on Saturday, 26 April 2014 15:42:34 UTC