> By that logic, none of the OpenSRS system would exist, because there
are
> an infinite number of programming errors that can leave resellers
> vulnerable to fraud or an error that prevents them from collecting
money.
>From a software point of view, you are correct. They are all the same.
And I'd like to have this flag too.
And I believe this very function that achieves exactly the same thing
can and should be provided -- just that it will have to be something
that acknowledges the legal barrier.
For a legal point of view, step away from OpenSRS or software compare it
to financial transactions and accounts elsewhere, like banking, for
comparision. (and remember, I'm not saying I like this position -- I'm
just describing what I think is reason for the barrier)
The only thing in the API that currently affects your RSP account
balance is successful registration or renewal -- and that's according to
one basic instruction from the you. The simple flag allows a third party
to (unknowingly, perhaps) give an instruction on how their transaction
affects your account. Unless OpenSRS has something in writing from you,
authorizing that individual by name, that can't happen. Worse, OpenSRS
isn't even in on the technical transaction with this person-- all they
got was this flag. They have nothing to defend the debit, if you
challenge.
Right now, OpenSRS has no idea if the customer has paid you. This flag
would make a real-time direct link from a enduser/RSP payment to the
corresponding RSP/OpenSRS debit. If you stand next to me and, in one
transaction, take customers' money, hand me some, take product from me
and hand it to the customer, you're a commissioned salesperson, not a
reseller, and I'd be a retailer, not a wholesaler.
> Anyway, you're assuming that an API flag would always decrease
security
> even as it increases flexibility.
Software itself is not a security risk -- people are. A thing is secure
when it admits fewer people. In the financial view from OpenSRS, the
world ends at the RSP's -- there's no-one else involved. This flag takes
a simple one-rule relationship with one entity, and allows the input of
maybe thousands of others. Security admits fewer people not because each
person causes some loss, but because of the certainty that one will
eventually cause much loss -- So the fact that "anyone can easily use it
without ever having a problem" is beside the point, as is the fact that
it admits more people by design and not error.
Note that there is no decrease in security overall -- the enduser is not
more likely to commit fraud. But now OpenSRS's justification for the
debit to your account is "But your software (of which we don't know the
exact content) told us that someone else (and we have no way to be sure
exactly who) said that it was okay."
There should be a way to get the same effect without OpenSRS being able
to infer the enduser's decision (a proxy?). I like my two-RSP-accounts
idea even better today. Is there anything about it that wouldn't do what
the flag would do?
Of course, no-one at OpenSRS could tell us to go ahead and do this for
this purpose. And we can't be *absolutely* sure that they'd correct bad
information on the mailing list. Oh well.
=====
Winston D. Neutel, [EMAIL PROTECTED]
Broken Productions, http://www.broken.ca
