Subject Re: draft charge, refeds working group on attribute release
From "RL 'Bob' Morgan" <rlmorgan@xxxxxxxxxxxxxx>
Date Tue, 5 Jul 2011 00:58:14 -0700 (PDT)

This is a subtle and complex business.

Indeed there are a couple of common paradoxes with this assurance business.

One is that if you go to an organization that has an IdM system that supports its internal business (administration, finance, payroll, registration, grading, etc) and ask the assurance questions:

1.  do you know who your users are?

2.  do you assign credentials in a reasonably secure fashion?

3.  are your authn systems reasonably secure, monitored, etc?

they'll say sure, all of that is good enough to support our organization's business anyway. But then if you show them LoA2 requirements that formalize all those things, cries of pain arise, and $100K compliance projects are drawn up. So we all generally do the right thing, we figure, but we faint when someone says "prove it".

The other paradox is that if you ask outsourced business apps owners (the sorts of apps that might be federated with many IdPs) what LoA they require of an IdP, they'll say LoA2, at least. But if you ask them about the non-federated practices they currently use to manage access, and whether those meet LoA2, they'll say well, no, probably not, but we've always done it this way and we haven't had any problems.

It's a formality gap, or perhaps technical measures being applied without enough business context ...

But none of this has anything to do with attribute release.

 - RL "Bob"