[OpenID] OpenID 2.0, PAPE, and handling monetary transactions

[Ben Bangert]

On Nov 27, 2007, at 6:36 PM, Eric Norman wrote:

> It would be good if you could get your head out of the
> technology and start thinking in terms of what the various
> parties need, want, and don't want.

I'm thinking in terms of the practical realities of how credit card  
charges work in the USA. If an RP trusts an OP, and the OP lies, the  
RP is on the hook. Not the OP, nor the user for trusting an OP that  
didn't work right and wasn't verified. My head is in the technology  
because as an RP that wants to process a transaction, I *need* to  
verify the user is still at the helm.

> For instance, in another message you mentioned that an RP
> can save operational costs by not having to deal with password
> resets and the like.  Good, that's something an RP would want.

That message was from someone else, I never said anything about  
operational costs.

> But they are going to have to balance that against their
> concerns about risk and liability.  For instance, if a bank
> is going to rely on someone else to do account authentication
> for them, they are going to worry about what happens if they
> rely on a false positive and (for instance) $100,000 disappears
> from a customer's account.

I don't care about massive amounts of money like a bank, I'm talking  
about sites with a simple shopping cart, and 10-100 buck purchases.  
FaceBook lets you buy $1-$5 items for example. Regardless, they all  
generally need access to a credit card to run such a transaction, so  
there's always the potential for larger charges than anticipated.

>> As I mentioned, the RP's are the one on the hook for unauthorized
>> transactions ...
>
> Right, but RPs don't want to be on the hook for that $100,000.
> That's the risk management part.  One of the things they are
> highly likely to ask of the OP is that the OP assumes liability
> for any false positives.  This is, in the above example, OP
> will pay RP $100,000 for OPs mistake.

User's aren't responsible if they choose a dumb password, and someone  
hacks their account as a result. The credit card company issues a  
chargeback. You can't hold an OP responsible if it fails to actually  
implement a PAPE it claims it does.

> If it turns out that the bank will still be on the hook for
> that $100,000 (because they can't come to a contractual agreement
> with the OP(s), for instance).  Then they will probably just
> do the authentication themselves.  Then they will at least be able
> to control the process.

Banks are a bit different from RP's that merely wish to process credit  
card transactions. I'm purely concerned about processing transactions,  
the bank remarks were by Luke Sontag in a separate thread.

> In fact, from what I read in the USSA link provided, that is just
> what they're doing.  They're being their own OP and that's the
> only choice you have.  Furthermore, they've added the security
> questions (just more passwords) on top of that.

Absolutely, and I'm using security questions as well. Security  
questions are not the same as having to remember a username *and* a  
password though. Security questions are things you shouldn't be able  
to forget, "What is your uncle's sisters last name?", etc. This is  
drastically easier to remember than another username/password combo,  
and still be as tough for someone who sat down at the same computer as  
you in a library to know.

The whole issue is that Dick Hardt and someone else said you shouldn't  
be prompted for a security question, because OpenID should keep that  
stuff with your OP. My entire point is that since I can't trust an OP  
to actually ask the user the question, I have to do it myself.

> In even more fact, I don't even see USSA saying that they're using
> OpenID!  They talk a lot about their Online ID, but I didn't see
> any mention of OpenID; perhaps I missed something.

A friend of mine who has a USSA account says its in use on the billpay  
portion of their site.

> The head is mired in technology again.  If the OP is going to be
> (partly) liable for the accuracy of what they tell the RP, then
> they damned well will care about whether the information they
> provide is used for financial transactions and how much is at risk
> to the OP.  What do you think the disclaimers above (... explicitly
> forbid ...) are about?

We've already said this, the OP is NOT liable for the accuracy of what  
they tell the RP. The RP is on the hook for charge-backs online, this  
isn't in dispute, its a well known fact.

> It's not about "trust" (whatever that means).  In the case of
> financial transactions, it's about risk management.  That includes
> both dollars and "customer loyalty".

Right, and risk management means ensuring that before doing something  
involving a financial transaction, its prudent to ensure the user can  
still present their authentication credentials. Since OP's may have  
long timeouts, its desired to have the user re-authenticate to their  
OP, which PAPE allows through the use of a max-age. There is however  
no way to verify this, which is what I've been talking about the  
entire time. Thus the use of security questions.

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2472 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20071127/bff125e5/attachment-0002.bin>