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

[Peter Williams]

For any deployment of openid at a bank, i'm interested in the risk management department's decision on which modes and which encryption features (of several supported by the std) the bank was willing to endorse.

For example, one can use none of the ciphering mechanims specified in the std - delegating the security controls rather to the bearer (e.g. Ssl handshake using a visa-endorsed DH ciphersuite and subsequent data integrity). Similarly, one might argue reasonably that using foreground channels exclusively makes the openid flow comply with the SET rules for moto transactions crossing the interchange, as exploited similarly in 3dsecure sso. Alternatively, the payment flows may be restricted to certain payment gateways and acquirers, which ensure the transaction is cleared internally.

All in all its an excellent test case to see what has been done - and in a way that can be rated against stable security criteria and risk management techniques. The accomodations made (if any) to bring openid into the mainstream are well worth documenting. Someone should give the bank cio a medal - for taking the same kind of forward thinking posture that wells fargo took in 1995 when adopting ssl V2.

-----Original Message-----
From: Ben Bangert <ben at groovie.org>
Sent: Monday, November 26, 2007 4:11 PM
To: Terry Hayes <Terry.Hayes at corp.aol.com>
Cc: openid-general General <general at openid.net>
Subject: Re: [OpenID] OpenID 2.0, PAPE, and handling monetary transactions

On Nov 26, 2007, at 1:04 PM, Terry Hayes wrote:

> Can you tell me which banks have adopted OpenID for  
> authentication?  Mine certainly hasn't.  Are they allowing all  
> types of transactions based on OpenID?  How does a user's OpenID  
> become associated with their account?

USAA does, not sure as I haven't used it myself.

> I certainly don't expect my bank or my brokerage to adopt OpenID.   
> I'm comfortable managing passwords for those sites separately.   
> OpenID would be great for lots of other places, like my New York  
> Times account, my blog, or even my Tivo or Netflix accounts.

Tivo and Netflix both have financial data, since you can change your  
subscription level. As Dick Hardt notes, OpenID should never be used  
for Tivo, Netflix, NY Times (since NY Times accounts can be linked to  
financial data, though they may have dropped this), and many other  
sites that in some way do handle financial information.

> In the world of OpenID, you (the bank or other RP) need to accept  
> the OP's PAPE statement.  OpenID transfers control of a user's  
> identity to the user.  They are free to select a provider that  
> gives them a set of features and a level of security that makes  
> them comfortable.  It is the user's responsibility to choose an  
> appropriate OP, one that actually implements the portions of the  
> specifications they will need for the sites they visit.

Agreed, however as a website developer I generally want to protect  
users from their own insecure choices. Ie, users will happily choose  
easy to guess passwords given the ability to do so. It would be nice  
to have a way to verify sets of OP's that properly honor PAPE,  
instead of relying on the user to know what their OP does and doesn't  
do.

> That said, it's perfectly reasonable for the bank (or other RP) to  
> notify the user that they need to take appropriate care in  
> selecting an OP.  Clearly, there is a registration step where the  
> bank associates an account with an OpenID serviced by the user's  
> chosen OP. (This may be at each login, if the OP changes in the  
> delegated case.)  At that point, the RP can in require the user to  
> agree that they are taking appropriate care.  Most institutions  
> already do this when dealing with the user's management of  
> passwords.  ("You must keep the password to yourself...")
>
> Again, this is just a result of the way OpenID puts the user in  
> control.

Most users are not security experts, nor know much about security. Is  
OpenID for the geek, or the average person? Putting a big red notice,  
"Warning, only use OpenID if you are *Absolutely* sure it properly  
honors the PAPE extension" seems like a sure way to get no one but  
the very brave to use it.

> In fact, I would be unhappy having to provide answers to security  
> questions to some entity other than my OP.  The idea of designating  
> an OP is to get most of the identity information in a single  
> trusted and managed location.  Spreading answers to personal  
> questions around to various RPs (financial institutions or not) is  
> moving in the wrong direction.

In this case, its the only way for the RP to know with certainty (as  
much as possible online at least) you're still at the helm of the  
computer. If the RP doesn't know you had to just log in again, you  
could be sitting at a terminal with a still active OpenID session  
that someone left an hour ago.

> Again, I'm surprised to hear that "so many sites are handling  
> financial data".  It is certainly not my sense that the "Support  
> OpenID" advocacy (as you call it) is pushing sites with high value  
> transactions in this direction at all.
>
> If the OpenID community does want to push in this direction, there  
> are other things to worry about first, such as consistent and  
> working support for SSL-based OpenIDs (https URLs).

When I refer to 'financial data', I mean any site that has some means  
to cause you to incur additional financial expenses. There's a lot of  
these, like Netflix, and Tivo, BaseCamp, and other sites which have  
various subscription levels, credit cards on file, etc. If you can  
change billing options, order stuff, etc. the site is dealing in  
financial transactions.

Some of these sites ask for a bit of your credit card before having  
you change options in your account, while others require a security  
question, or your password. With OpenID, no password, so the choice  
is a bit of credit card data, or the security question. I was just  
referring to the need for 'something' else to verify the user is  
still there, and is the right user before performing an option that  
can cause a financial transaction.

I don't see why its so crazy to let someone login with OpenID if you  
protect the additional actions that can incur a cost with a security  
question or some other form of verification that you can verify  
without relying on the OP. These websites do not generally have  
financial transactions as the centerpiece of their usage, but may be  
subscription based, or occasionally cause a financial transaction to  
occur.

I'd really like to see a growth in adoption of OpenID, and having a  
set of recommendations for how to handle actions that can cost a user  
money in a secure manner even if they login with OpenID seems prudent.

Cheers,
Ben