W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2012

Re: making the webcredits.org spec more strict about 'source' and 'destination' fields.

From: Walter Stanish <walter@ifex-project.org>
Date: Wed, 25 Apr 2012 04:22:57 +0800
Message-ID: <CANCCdvm7--a4GSS18Y-obzeBvDAcduLmeMomP1FS8v37UcNwOw@mail.gmail.com>
To: David Nicol <davidnicol@gmail.com>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Michiel de Jong <michiel@unhosted.org>, Web Payments <public-webpayments@w3.org>
> I suggest that example identity strings in the short spec doc don't have
> fragments in them, also that the sentence where you state that any URL will
> do could affirm that when fragments are provided, the fragment is important
> and MUST NOT get stripped.

In many mature financial systems we see various types of multifactor
authentication in use:
 - Credit card processing often has a requirement for signatures,
physical addresses, expiry dates, customer names in addition to
numbers
 - International SWIFT or Western Union transfers often pair recipient
address, phone, email, name or other data along with recipient bank,
branch and account number

These additional factors within a financial transaction assist in
either reducing fraud (debit transaction) or accidental routing errors
(credit transaction) from the simplest case of only using the base
financial endpoint specifier (ie. the credit card number in the case
of a credit card debit transaction, or the bank, branch and account
number in the case of an international transfer).

There MAY be some potential to use the 'fragments' you mention for
such multi-factor 'error (or fraud) reduction' or for carrying
reporting information that may be mandated for regulatory or other
purposes (check out what's 'required' to send a SWIFT transaction
these days - you can't predict bureaucracy!), though I am not clear
enough about the proposal at this stage to say so with clarity.

Just some thoughts...

Regards,
Walter Stanish
The IFEX Project
http://ifex-project.org/
Received on Friday, 27 April 2012 18:02:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC