I think, this is a typical case of the tragedy of commons. If a secret is shared by more than two parties, nobody can identify the source of the leak. So, the damages are shared, the benefit is private.
I think that any security-concious design should avoid secret-sharing between more than two parties in one step.
Each secret-sharing should be an individual contract with two parties and clear identification of the consequences if the secret leaks.

There should be no corporate responsibility for secrets: only personal. Otherwise, it will be sold, extorted, stolen. The price that the individual is willing to pay for protecting shared secrets for which he is not personally and exclusively repsonsible is abysmally low. And rationally so.

"You recall reading that each identity theft victim will on average spend $1,495, excluding attorneys' fees, and 600 hours of their time to straighten out the mess,"

Does anyone know whether or not an identity theft SOP is available?

That is, does the 600 hours mean that people are usually first victims of identity theft and part of that 600 hours (the larger part) is discovery what to do; where to turn etc ...?

If there isn't an identity theft 'How to recover from identity theft' SOP 001; shouldn't someone around here think of writing one? (iang? How about a post - what should go into an identity theft SOP?)

working on x9.99 privacy standard for the financial industry, one of the issues that came up was distinguishing between 1) acquiring enuf information to open new accounts in the victim's name and 2) acquiring enuf informaiton to perform fraudulent transactions on existing accounts.

x9.59 was designed that it could make use of AADS technology (which we had invented)
http://www.garlic.com/~lynn/index.html#aads

however, x9.59 was primarily a business process solution to fraud, eliminating the ability for criminals to do fraudulent transactions
http://www.garlic.com/~lynn/index.html#x959

with skimmed/harvested data
http://www.garlic.com/~lynn/subpubkey.html#harvest

a major issue was the value to the crooks tended to far exceed the ability of most organizations to protect the data; security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

the 1997 business requirement for AADS chip was to meet the power & elapsed-time requirement used for the mitsubishi/sony contractless chip used in the HK transit system. such chip/technology was available by the AADS conference in jan. 1999
http://www.garlic.com/~lynn/aepay3.htm#riskm

and was demo'ed at the 1999 BAI show in Miami
http://www.garlic.com/~lynn/99.html#217

and an AADS hardware token was used in the NACHA debit payment trials in 2000 (Star & Fiserve doing implementation), 9/98 AADS NACHA project proposal:
http://www.garlic.com/~lynn/nacharfi.htm

6/2001 report on results:
http://internetcouncil.nacha.org/News/news.html