Assurance

[David Walker <>]

Waxing philosophic, understanding that philosophy probably has nothing to do with a specific service contract...

Automated processes are replacing human action in many situations these days; monitoring service health is only one.  I think it's important to incorporate these processes into our identity management strategies, but we should be very careful about trying to shoehorn them into our existing assurance profiles.

The 800-63-based assurance profiles like UCTrust Basic and InCommon Silver are entirely about the identity of people.  We specify specify requirements for identity proofing and registration processes only for when the subjects of the identity management system are people.  As was observed earlier in the discussion, the authentication requirements are also slanted toward people using browsers, although the authentication mechanisms can be used by non-person subjects (i.e., automated processes).

We do all of this to reduce the risk that the wrong person will be identified to some service.  We may also require controls like education to reduce the risk that the right people will do the wrong things.

So, what is the analog of verifying photo IDs and addresses of record for automated processes?  There probably isn't a good one, so I think we're looking at a different assurance profile.  Rather, I think we need to address the people who administer those processes and what their responsibilities are to reduce the risk that the wrong process will be identified to a service, or that the right process will do the wrong thing.  Here are some examples:

• Level of assurance (or, at least, identity proofing) of the administrators
• Sharing of secrets, private keys, etc., among multiple automated processes
• Certification that the process does what it is supposed to do
• Change control and security for the process

That said, the need for formal assurance profiles is lessened when the subjects are well-known to the relying party.  As I understand Eric's case, the subject process is actually operated by the relying party, so one would think that a specific IAQ would not be needed at all.  I can understand why the relying party would want to know that the IdP is being operated in a secure and professional manner, so requiring that the IdP is certified to issue InCommon Silver or UCTrust Basic IAQs sounds reasonable, but actually requiring the IAQ in assertions of its own identity sounds like overkill.

David

On Tue, 2012-01-24 at 16:34 -0800, Eric Goodman wrote:
>     This is a University of California specific assurance level we call of "UCTrustBasic". It was defined prior to InCommon Silver, but is effectively the same set of requirements and UC will be retiring the "UCTrustBasic" in favor of InCommon Silver as we all align better with the InCommon IAPs. 
>     
>     
>     There are a handful of multi-campus UC-based applications where we require the assertion to grant access. So yes, this is an app where the requirement is that we assert the assurance. 
>     
>     
>     That said, technically the assurance is just implemented as an attribute transmitted along with other SAML attributes; I'm not sure if that's the same thing as the AuthRequest/AuthnContext model, but I suspect it's not.
>     
>     
>     --- Eric
>     
>     On Tue, Jan 24, 2012 at 3:52 PM, RL 'Bob' Morgan <> wrote:
> >         
> >         I suppose the other thing to point out here is that I expect that there isn't really any experience with testing/monitoring in an assurance-is-required scenario because there are, at this point, hardly any real-life assurance-is-required scenarios.  I'm amazed that you have a vendor SP that is requiring something-like-Silver.  Are they actually supporting/requiring the use of the standardized AuthRequest/AuthnContext means of expressing assurance?
> >         
> >          - RL "Bob"
> >         
> >     
>     
>