[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