[OpenID] general Digest, Vol 15, Issue 15

Ashish Jain ajain at pingidentity.com
Tue Nov 27 21:55:45 UTC 2007


Luke,

 

Not sure I agree with you.

 

Outsourcing authentication to a third party and using OpenID are two
independent issues.

 

I agree with your comment that it makes economical sense to outsource
authentication and/or identity management. There are better ways to do
that e.g. Verisign's VIP is one way for FIs to support multi-factor
authentication without much infrastructure cost. There are other hosted
identity models in specific verticals.

 

I like OpenID (hence the reason for SignOn.com). However, if my bank
starts to accept OpenID in its current form and spirit (e.g. allowing
http://www.jkg.in/openid/ as OP), then I would get uncomfortable.

 

Either way, it will make a great topic for IIW.

 

Thanks.

- Ashish.

 

 

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Luke Sontag
Sent: Tuesday, November 27, 2007 1:46 PM
To: general at openid.net
Subject: Re: [OpenID] general Digest, Vol 15, Issue 15

 

This thread would make a great topic for IIW.  "OpenID in High Value

Transactions."

 

I completely disagree that anyone who uses OpenID for financial
transactions

would be crazy.  For one, OpenID can make tremendous sense economically
for

any financial institution.  Recent data published in the November issue
of

the ISSA (Information Systems Security Association) Journal shows that
for a

50,000 member institution the cost of password resets alone can reach
over

$10 million annually.  In addition, and typically at a much larger cost,

each bank has to bear the cost of stronger (multi-factor)
authentication,

which has been mandated by the FFIEC (

http://www.ffiec.gov/press/pr101205.htm).

 

Given these two factors alone, if an institution were able to off load
the

identity management component of their service to a trusted OP, they
could

potentially save tens of millions of dollars a year.  Would a banker
think

saving millions is crazy?  I doubt it.

 

-Luke Sontag

 

 

On 11/27/07 2:39 AM, "general-request at openid.net"

<general-request at openid.net> wrote:

 

> Send general mailing list submissions to

> general at openid.net

> 

> To subscribe or unsubscribe via the World Wide Web, visit

> http://openid.net/mailman/listinfo/general

> or, via email, send a message with subject or body 'help' to

> general-request at openid.net

> 

> You can reach the person managing the list at

> general-owner at openid.net

> 

> When replying, please edit your Subject line so it is more specific

> than "Re: Contents of general digest..."

> 

> 

> Today's Topics:

> 

>    1. Re:  OpenID 2.0, PAPE, and handling monetary transactions

>       (Peter Williams)

>    2. Re:  OpenID 2.0, PAPE, and handling monetary transactions

>       (Ben Bangert)

>    3. Re:  OpenID 2.0, PAPE, and handling monetary transactions

>       (Dick Hardt)

> 

> 

> ----------------------------------------------------------------------

> 

> Message: 1

> Date: Mon, 26 Nov 2007 16:34:35 -0800

> From: "Peter Williams" <pwilliams at rapattoni.com>

> Subject: Re: [OpenID] OpenID 2.0, PAPE, and handling monetary

> transactions

> To: "Ben Bangert" <ben at groovie.org>, "Terry Hayes"

> <Terry.Hayes at corp.aol.com>

> Cc: openid-general General <general at openid.net>

> Message-ID: <129a01c8308d$4915f29a$0a14a8c0 at rapnt.com>

> Content-Type: text/plain; charset="iso-8859-1"

> 

> 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

> 

> 

> ------------------------------

> 

> Message: 2

> Date: Mon, 26 Nov 2007 17:05:17 -0800

> From: Ben Bangert <ben at groovie.org>

> Subject: Re: [OpenID] OpenID 2.0, PAPE, and handling monetary

> transactions

> To: Gabe Wachob <gabe.wachob at amsoft.net>

> Cc: 'openid-general General' <general at openid.net>

> Message-ID: <A0DA248A-0818-4325-86E0-08DCF19F76A0 at groovie.org>

> Content-Type: text/plain; charset="windows-1252"

> 

> On Nov 26, 2007, at 4:18 PM, Gabe Wachob wrote:

> 

>> I haven?t been part of PAPE, but I think the right view is one of

>> incremental advancement towards the point where it?s not insane to

>> use OpenID for user authentication in ?transactions of value?. You

>> may just be ahead of the curve. I think PAPE is one step ?

>> signatures of PAPE statements may or may not be the next step.

> 

> Thanks Gabe, the mere existence of PAPE seemed like a very clear

> indicator of this as well. I'm still confused why Dick Hardt

> considered it crazy to use

> 

>> When you deal with ?transactions of value?, use of OpenID has to be

>> analyzed in the context of the overall transaction flow, and with

>> the mindset of risk/benefit analysis, not just ?security?. I?m not

>> sure that?s going to happen entirely in an open environment like

>> these email lists ? it may be that the analysis is already

>> happening in private, and that mitigation factors to the obvious

>> security issues are already being put in place for certain

>> transactions among certain RPs and OPs.

> 

> Yep, this was what I was referring to about white-listing OP's that I

> know are honoring PAPE properly so that I can rely on their

> authentication rather than keeping my own batch of security questions

> or some other financial data for verification.

> 

>> In any case, these RPs will have to make the call about the benefit

>> of OpenID their business context. For example, in many cases

>> involving highly regulated industries such as banking or electronic

>> payments, it is the RPs and NOT the users that bear the risk (or at

>> least a good deal of the risk) of an authentication failure. Thus,

>> the argument for OpenID?s benefits takes on a different character

>> in that environment, and OpenID uptake is probably driven by a more

>> concentrated, homogenous group than we have been seeing for general

>> OpenID adoption (e.g. Visa or the American Bankers Association or

>> FSTC, not the current OpenID community). Of course, these

>> organizations have their own interests, their own constraints, and

>> their own time horizons.

> 

> Right, this is why I was rather alarmed to see the apparent belief

> that the user should be left to decide whether their OP is 'secure',

> when many times the one that can lose in the transaction is the RP if

> the user chooses poorly. What I've generally seen happen, is the user

> does something stupid, a transaction is run, the user notices and

> reports it as a stolen/unauthorized transaction, and the credit card

> company charges it back to the RP in question. So relying on a user

> to choose a 'secure' OP is out of the question.

> 

>> What this community (us here) *can* do is demonstrate how legacy

>> authentication mechanisms, such as biometrics, OTP, etc (which are

>> more well known to the ?transaction of value? communities) can be

>> used with OpenID in a trustable way. And this community (use here)

>> probably has a lot of learning to do about risk analysis and how

>> mitigation techniques go beyond technological solutions. Both

>> communities have a lot to learn from each other and I think its

>> going to take a while, but I am optimistic.

> 

> I'd also love to see this happen.

> 

> Cheers,

> Ben

> -------------- next part --------------

> An HTML attachment was scrubbed...

> URL: 

>
http://openid.net/pipermail/general/attachments/20071126/a5501672/attach
ment-0

> 001.htm 

> -------------- next part --------------

> A non-text attachment was scrubbed...

> Name: smime.p7s

> Type: application/pkcs7-signature

> Size: 2472 bytes

> Desc: not available

> Url : 

>
http://openid.net/pipermail/general/attachments/20071126/a5501672/attach
ment-0

> 001.bin 

> 

> ------------------------------

> 

> Message: 3

> Date: Tue, 27 Nov 2007 00:39:08 -0800

> From: Dick Hardt <dick at sxip.com>

> Subject: Re: [OpenID] OpenID 2.0, PAPE, and handling monetary

> transactions

> To: Ben Bangert <ben at groovie.org>

> Cc: 'openid-general General' <general at openid.net>

> Message-ID: <0E4A8172-CA72-495E-9947-9FF210B4337B at sxip.com>

> Content-Type: text/plain; charset="windows-1252"

> 

> 

> On 26-Nov-07, at 5:05 PM, Ben Bangert wrote:

> 

>> On Nov 26, 2007, at 4:18 PM, Gabe Wachob wrote:

>> 

>>> I haven?t been part of PAPE, but I think the right view is one of

>>> incremental advancement towards the point where it?s not insane to

>>> use OpenID for user authentication in ?transactions of value?. You

>>> may just be ahead of the curve. I think PAPE is one step ?

>>> signatures of PAPE statements may or may not be the next step.

>> 

>> Thanks Gabe, the mere existence of PAPE seemed like a very clear

>> indicator of this as well. I'm still confused why Dick Hardt

>> considered it crazy to use

> 

> Clearly the attack vectors against OpenID need to be more clearly

> articulated if that is the case.

> 

>> 

>>> When you deal with ?transactions of value?, use of OpenID has to

>>> be analyzed in the context of the overall transaction flow, and

>>> with the mindset of risk/benefit analysis, not just ?security?.

>>> I?m not sure that?s going to happen entirely in an open

>>> environment like these email lists ? it may be that the analysis

>>> is already happening in private, and that mitigation factors to

>>> the obvious security issues are already being put in place for

>>> certain transactions among certain RPs and OPs.

>> 

>> Yep, this was what I was referring to about white-listing OP's that

>> I know are honoring PAPE properly so that I can rely on their

>> authentication rather than keeping my own batch of security

>> questions or some other financial data for verification.

> 

> White-listing OPs cuts against the OpenID philosophy where the user

> is deciding

> How an RP decides which OPs to accept can be (and likely will be) for

> business and political reasons rather then technical reasons. If this

> is common practice, then we are not much further from the heavily

> siloed systems that we have today.

> 

>> 

>>> In any case, these RPs will have to make the call about the

>>> benefit of OpenID their business context. For example, in many

>>> cases involving highly regulated industries such as banking or

>>> electronic payments, it is the RPs and NOT the users that bear the

>>> risk (or at least a good deal of the risk) of an authentication

>>> failure. Thus, the argument for OpenID?s benefits takes on a

>>> different character in that environment, and OpenID uptake is

>>> probably driven by a more concentrated, homogenous group than we

>>> have been seeing for general OpenID adoption (e.g. Visa or the

>>> American Bankers Association or FSTC, not the current OpenID

>>> community). Of course, these organizations have their own

>>> interests, their own constraints, and their own time horizons.

>> 

>> Right, this is why I was rather alarmed to see the apparent belief

>> that the user should be left to decide whether their OP is

>> 'secure', when many times the one that can lose in the transaction

>> is the RP if the user chooses poorly. What I've generally seen

>> happen, is the user does something stupid, a transaction is run,

>> the user notices and reports it as a stolen/unauthorized

>> transaction, and the credit card company charges it back to the RP

>> in question. So relying on a user to choose a 'secure' OP is out of

>> the question.

> 

> Users are going to choose which OP to trust with the same market

> mechanisms they use to decide on numerous other trust decisions.

> A users ISP can screw a user very easily, but I don't see RPs saying

> they need to choose which ISP the user uses. Similarly, as an RP are

> you going to force the user to use a particular browser and OS?

> 

> -- Dick

> 

> -------------- next part --------------

> An HTML attachment was scrubbed...

> URL: 

>
http://openid.net/pipermail/general/attachments/20071127/48af2527/attach
ment.h

> tm 

> 

> ------------------------------

> 

> _______________________________________________

> general mailing list

> general at openid.net

> http://openid.net/mailman/listinfo/general

> 

> 

> End of general Digest, Vol 15, Issue 15

> ***************************************

 

_______________________________________________

general mailing list

general at openid.net

http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20071127/8b9dc6fb/attachment-0002.htm>


More information about the general mailing list