ADFS and Liability Continued...

hmm...let's see...I wrote a blog, Pam left a comment, I replied to her comment with another blog, and so (if you haven't seen it yet) Pam posted her own blog entry here...  This is actually kind of fun!

You should read (all of) her posts anyways, but to save some screen flipping here's the meat of it:

...When I read this, I felt like jumping up and down like the goody-two-shoes in the second row, me me me me oh I know the answer pick me!!!

If they were to use an Information Card for the active confirmation prior to a user making changes, users wouldn’t need to remember a password at all. You would get the impediment of requiring credentials, without the support burden attached to maintenance of a rarely-used password. Alternatively, if you felt the need to have a password, you could require a managed information card. In that case, the user would be authenticating to the home IdP instead of to the outside application, taking the password management burden off of your partner and consolidating password use to a single centralized source that would theoretically be much more commonly used, and therefore less likely to require frequent recovery. Not to mention that the Enterprise could audit use of the managed infocard in this context.

This seems to me to be a perfect scenario to envision a hybrid passive/active federation combination instead of passive federation for 85% of user activity, and partner-managed password authentication for the remaining 15%. Yes? If so, it just goes to show that the scenarios are out there, and for more than just the eBusiness world.

Brian, what do you think?

So...let's see...What do I think? 

I don't think the problem is in the way that the credentials are stored.  Let's suppose it's an InfoCard from some Identity Provider, then the liability would then fall on that Identity Provider if/when a users account gets compromised.  Why would someone sign up for that?  In the case that we're dealing with internally, Microsoft is the Identity Provider, and our lawyers don't want to sign up for the risk - why would anyone else?

Thinking about this slightly differently – Our lawyers have the problem, because if someone hijacks my corporate user account, and goes into my 401k and wipes out my retirement savings – who is ultimately responsible?  If Microsoft did the authentication, Microsoft is, if the partner did it, they are, and if some 3rd party identity provider did the authentication – then THEY are responsible (would we even consider a 3rd party - umm...let's hope not)

So let’s say we use an infocard.  And not only that, but we use a Managed infocard.  Ok, so now I’ve got a managed card on my machine – So when someone hacks my account, selects the highlighted infocard, and THEN wipes out my 401k… Now who’s responsible?

I can absolutely see where an InfoCard can help the end user - but I'm the IT Geek who's trying to deploy the infrastructure.  How do I sell being an Identity Provider to my CIO?