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

openid at allentom.com openid at allentom.com
Tue Nov 27 19:24:10 UTC 2007


Using OpenID to authorize financial transactions would certainly raise
legal and liability issues with potential OpenID Providers.

To reduce the legal exposure resulting from the unintended use of OpenID
to authorize financial transactions, OpenID Providers would probably want
a way to publish a "Relying Party Acceptable Use" policy which states
acceptable and appropriate uses that an RP can use with an assertion from
the OP, as well as explicitly listing inappropriate uses.

For instance, most OPs would want to explicitly forbid the use of their
assertions to authorize financial and ecommerce transactions.

The PAPE extension seems to be the right place to publish this type of
information. In order to satisfy the legal requirements for potential OPs,
there needs to be a way for an OP to specify the url to a document that
explains the RP Acceptable Use policies for the OP, as well as a mechanism
for an OP to explicitly tell RPs that the assertion is not suitable for
high-value transactions. Maybe the community can define a set of
acceptable use profiles similar to the NIST levels used in the PAPE
extension.

I'd really like to talk about this issue at next week's IIW.

Thanks
Allen




On Mon, November 26, 2007 1:04 pm, Terry Hayes wrote:
> I'm always surprised that people are considering using OpenID for
> financial transactions (at least right now).  OpenID has a lot to offer
> without being used at sites that require the highest levels of security.
> However, since the question was asked, I'll respond to a
> few points below.
>
> Terry
>
>
> On Nov 26, 2007, at 12:00 , Ben Bangert wrote:
>
>
>> I've been working on an OpenID 2.0 based application to replace a
>> legacy system the past few months, and its getting close to deployment
>> (any day now!). Some interesting issues have come up
>> since I first embarked on this project, mainly dealing with all the
>> little details.
>>
>> One of the most pressing, is security. While OpenID 1.0 was
>> originally created with the intention of making it easy to manage your
>> identity, so you could post comments to blogs, etc. it is increasingly
>> being used and added to systems that do so much more.... like financial
>> websites (some banks now take OpenID), and other online websites that
>> might manage subscriptions or other activities linked to financial data.
>> With such a move, the
>> inability to do a few basic actions becomes a massive problem that I've
>> experienced.
>
> 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?
>
> 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.
>
>
>>
>> The most common need I have when dealing with a user account linked
>> to financial information, is before anything can be changed, I want to
>> ensure that they can still provide authentication credentials. PAPE
>> supports a max-age limit where I can ensure a user has been able to
>> sign-in within a specific time frame, which appears to meet this need.
>> However, whether or not the user's OP *really* honors
>> it, is questionable, and except for a small white-list of IDP I can't
>> really ensure that the user really has re-authenticated to their OP.
>
> I don't know all the details of PAPE (I'm way behind on some of the
> proposed extensions), but I'm going to assume that part of the OpenID
> authentication response includes a (signed) statement that certain PAPE
> requests were satisfied (in this case "max-age").  In other words, the OP
> is asserting that it honors PAPE.
>
> 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.
>
> 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.
>
>
>>
>> I've seen a few banks solve this problem by requiring security
>> questions, so the security question is acting as a specific password that
>> the bank can then ensure that you are you, rather than someone who got
>> lucky sitting at another terminal. PAPE is only useful if you're
>> absolutely sure the other website is actually honoring it, which
>> naturally results in having to maintain a white- list of IDP's you can
>> trust. And rather than having to restrict users to a white-list, I've
>> gone with following the bank model and having OpenID users choose
>> security questions (which is not as desirable as having PAPE I can
>> trust).
>
> 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.
>
>>
>> To top it all off, PAPE is only Draft 1, which seems silly since so
>> many sites are handling financial data, that only now did this become a
>> concern. Meanwhile the advocacy to "Support OpenID", etc. is in full
>> gear, and its rather frightening to think some sites may blindly start
>> supporting OpenID without realizing its missing something as basic as a
>> way to ensure a user can re-authenticate (quite a few OP's have very
>> long session timeouts).
>
> 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).
>
>>
>> As PAPE is an early draft, could it be extended to support some
>> sort of trust signature that can be signed off on? This could help
>> alleviate the need to maintain a white-list, by instead supporting any
>> OP that has had its PAPE support verified by means of another
>> service (maybe some OpenID non-profit that can cryptographically sign
>> OP's?).
>>
>
> Again, the OpenID model puts the user in charge.  The financial
> institution's customer needs to select a provider that delivers the
> appropriate level of security, which may include correctly implementing
> PAPE.
>
>
>>
>> At the very least, it'd be exceptionally useful to those
>> implementing OpenID on websites that do need to handle accounts linked to
>> financial data, with a set of guidelines for: * How to handle
>> re-authentication (PAPE with white-list? Security questions?) * Security
>> considerations (Can't trust an OP, since anyone can run one, and *claim*
>> it supports PAPE, ie, no way to verify the claim)
>
> PAPE may be the appropriate solution for "re-authentication".  As far
> as "anyone can run" a provider, it's up to the user to choose a good one,
> and up the bank (or other RP) to inform the user of their responsibility
> and liability.
>
>>
>>
>> Btw, thanks very much to the JanRain team for an excellent set of
>> Python OpenID libraries that actually implement such early Drafts! :)
>>
>>
>> Cheers,
>> Ben_______________________________________________
>> general mailing list general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
> _______________________________________________
> general mailing list general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>





More information about the general mailing list