Assurance

[Eric Goodman <>]

Hi all,

We have a vendor who is delivering a Shibbolized application that requires an assurance assertion before users are granted access. The assurance assertion is essentially the same as InCommon Silver assurance. The vendor also requires that we provide an account they can use to perform automated system logins via Shibboleth (to monitor the system). Because their application is configured to require this InCommon Silver(-like) assurance assertion, they want the monitoring account to be flagged with an InCommon Silver(-like) IAQ. 

This seems to be illegal under the InCommon Silver IAP; we know for a fact that there is no individual behind the account performing the login. I don't see a reasonable way to provide a system account with an InCommon Silver IAQ -- that seems to break the ground rules of InCommon Silver compliance. 

It's at about this point that I start thinking: "This can't be a unique problem; I wonder what other people do in this kind of situation?" 

And that's my question to the list: What do you do in this scenario? Would you give InCommon Silver IAQs to the monitoring/automated account? Do you have developers code your application to maintain a list of special accounts that do not require InCommon Silver IAQ for system access? Something else?

Thank you for any input you can provide!

--- Eric

Eric Goodman

Identity Management Systems

UC Santa Cruz

P.S. Not having been a member of this list for a long time, I'm not sure if this question is more appropriately asked here or on another list (say mace-dir), so advice on that front is also appreciated.