For consumers, there are two key insurance moments: when coverage is bought and then when it’s used, with hopefully a long span of time between the two. And if there is a claim, then it’s up to the insurer to react to help the claimant recover. But too often, the claims experience spurs policyholders to consider changing insurers, especially among policyholders who’ve been customers longer (and have been paying premiums longer).[i] What else happens when there’s a policyholder unhappy about a claim? Claimants readily take to social bully pulpits with their claims grievances, effectively using Twitter and Facebook to “regulate” insurers into action.
In addition, they also file complaints with state insurance regulators, an activity that about 34,000 US consumers did in 2013.What’s their biggest gripe? A look at the National Association of Insurance Commissioners (NAIC) stats reveals that 56% of consumer complaints filed in 2013 were issues related to claims handling, with the biggest chunk, 24%, because of perceived delays. And that’s not counting delays associated with getting referrals, pre-authorizations, and finding willing providers.[ii]
Over the past year, I’ve been involved in a variety of client advisories focused on the claims experience for both consumers as well as insurer work teams responsible for getting claims paid. Why is the claim experience so easy to go off track? For starters:
Cloud providers and many federated IAM practitioners are excited about OAuth, a new(ish) security technology on the scene. I’ve written about OAuth in Protecting Enterprise APIs With A Light Touch. The cheat-sheet list I keep of major OAuth product support announcements already includes items from Apigee, Covisint, Google, IBM, Layer 7, Microsoft, Ping Identity, and salesforce.com. (Did I miss yours? Let me know.)
OAuth specializes in securing API/web service access by a uniquely identified client app on behalf of a uniquely identified user. It has flows for letting the user explicitly consent to (authorize) this connection, but generally relies on authorizing the actions of the calling application itself through simple authentication. So does the auth part of the name stand for authentication, authorization, or what? Let’s go with “all of the above.”
However, OAuth is merely plumbing of a sort similar to the WS-Security standard (or, for that matter, HTTP Basic Authentication). It doesn’t solve every auth* problem known to humankind, not by a long shot. What other IAM solutions are popping up in the API-economy universe? Two standards communities are building solutions on top of OAuth to round out the picture:
Microsoft announced during last week's RSA conference that it would not be shipping Windows CardSpace 2.0. A lot of design imperatives weighed on that one deliverable: security, privacy, usability, bridging the enterprise and consumer identity worlds – and being the standard-bearer of the "identity metasystem" and the "laws of identity" to boot. Something had to give. What are the implications for security and risk professionals?
The CardSpace model had nice phishing resistance properties that cloud-based identity selectors will find hard to replicate, alas. But without wide adoption on the open Web, that wasn't going to make a dent anyway. We'll have to look for other native-app solutions over time for that.