[Openid-specs-fapi] problems with Zelle in the us

Anders Rundgren anders.rundgren.net at gmail.com
Mon Apr 23 16:43:08 UTC 2018


On 2018-04-23 18:09, Tom Jones wrote:
> I am strongly opposed to any attempt to "blame the user" for the failure of the system. 
> The laws are made for the people, not the people for the laws.

I'm on the same page here but if there are no known solutions, doesn't problems trickle down to "user space" anyway?


>>>Another problem is that the payer did not properly identify the recipient.

Yes, how do you (as an individual) actually "identify" a recipient?

Some 20 years ago I talked to somebody at the Swedish e-government who claimed that a digital signature created by the citizens' eID cards would guarantee that the merchant got paid.
I claimed that this was utter nonsense since I may be a crook or my bank account may be empty, and BTW the CA is not the police.

It is somewhat funny seeing the blockchain folks claiming that "smart contracts" will solve major issues although 99% of all real-world contractual issues are of human nature.

Anders

> 
> Peace ..tom
> 
> On Mon, Apr 23, 2018 at 8:42 AM, Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> wrote:
> 
>     On 2018-04-23 16:51, Tom Jones via Openid-specs-fapi wrote:
> 
>         I have been pushing hard for strong identities for all parties to a financial transaction. This article from the NY Times shows that the identity for the user is one of the entities identities that is being attacked as well. There is a tendency to add the phone number as a strong identity when we have ample evidence that it is not so. Any federation systems needs to strongly identify the client and the bank, but should also address the identifiers used by the customer.
> 
>         https://www.nytimes.com/2018/04/22/business/zelle-banks-fraud.html <https://www.nytimes.com/2018/04/22/business/zelle-banks-fraud.html>
> 
> 
>     The problem with shallow articles like above is that they describe entirely different security issues as one.
>     Phishing scams is a separate issue which the recently released WebAuthentication scheme can deal with to 100%.
> 
>     Scandinavian banks have almost zero phishing issues since they use PKI since ages back.  US banks probably have the lousiest security tech in the western world since they pit fraud against the cost for thwarting it.  OTOH, they have a liberal compensation system...
> 
>     However, the problem with a "bad recipient" is not entirely trivial to fix.
> 
>     Assume the recipient is authentic but doesn't do what you expect (send those tickets or similar).  What exactly is the solution against that?
> 
>     Another problem is that the payer did not properly identify the recipient.  Since the number-2-account registry must be somewhat "public" this is effectively a privacy issue.
>     I could imagine that if you are going to send a substantial sum to an unknown recipient, you could ask for more detailed information as a part of a payment protocol.  If the recipient refuses you have the option to not perform the operation.
> 
>     This could also be a policy enforced by your bank through the payment application.
> 
>     Another solution would be requiring high-value transactions to be preceded by payment request messages which are verified by your bank for authenticity.  This is how Saturn[*] deals with merchants.
> 
>     Thanx,
>     Anders
> 
>     *) https://github.com/cyberphone/saturn/blob/master/PSD2.md#saturn---optimized-for-payments <https://github.com/cyberphone/saturn/blob/master/PSD2.md#saturn---optimized-for-payments>
> 
> 
>         Peace ..tom
> 
> 
>         _______________________________________________
>         Openid-specs-fapi mailing list
>         Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
>         http://lists.openid.net/mailman/listinfo/openid-specs-fapi <http://lists.openid.net/mailman/listinfo/openid-specs-fapi>
> 
> 
> 



More information about the Openid-specs-fapi mailing list