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

Tom Jones thomasclinganjones at gmail.com
Mon Apr 23 16:09:51 UTC 2018

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.

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

Peace ..tom

On Mon, Apr 23, 2018 at 8:42 AM, Anders Rundgren <
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
> 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#sat
> urn---optimized-for-payments
>> Peace ..tom
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180423/de016fd6/attachment.html>

More information about the Openid-specs-fapi mailing list