Subject Re: discussion on assurance
From "RL 'Bob' Morgan" <rlmorgan@xxxxxxxxxxxxxx>
Date Tue, 5 Jul 2011 10:36:58 -0700 (PDT)

[subject line changed again ...]

I also stumbled over one reason for not being LoA1: accounts are to be attributable to an individual ("... the same claimant is accessing ..."). Some of the smaller schools around here don't bother to do it "properly", with a role-accound "director@..." that gets put through to the actual individual account - they just make the director@ an actual account with password and the individual that is currently the director gets the password. That means the claimant behind an account changes every once in a while.

Sure, at my institution we have thousands of these, unfortunately, some even used for significant business. Departments like them. Try to take them away in new environments (Google Apps, say) and you get slapped.

But it is very important to note that it is perfectly fine to have some non-assured identities living alongside ones with qualified assurance (1, 2, eg) in the same IdM system. Just because my system has some "shared accounts" doesn't mean that my system's well-identified-individual accounts can't be LoA2. Of course my system has to be able to distinguish between the two.

This is unlike, say, poor password protection, which will invalidate assurance for all identities in the system (if the poor protection is system-wide).

 - RL "Bob"