IdPAttribute -> IdentityAttribute ?

[Tom Zeller]

> I just think it's a little vague in this context

Floating the idea for initial reaction. It might take until the next
call for my thoughts to settle.

> My feeling actually was that InternalAttribute was the most descriptive,
> but suggested IdP because it's shorter.

I guess I feel that InternalAttribute is more correct than
IdPAttribute, because the attribute resolver, filter, and mapper
components are not really relying party specific. I am aware that the
v2 AttributeResolver was moved from 'common' to 'idp' for v3. Since
ServiceProviders seem to have need for attribute * components, I
thought IdentityAttribute was descriptive (as well as disambiguated)
and generic across relying parties.

To me, it makes sense for an identity provider to produce identity
[provider] attributes to be consumed by a service provider, and it
also makes sense for a service provider to produce identity attributes
if necessary, but producing identity provider attributes would be
"wrong". I do not really know, but I think some SPs use an attribute
resolver to "create" attributes, based on what I have read.

I guess where I am going is re-use of the attribute * components by an
SP, and not having "IdP" in those APIs for objects, having "idp" in
package names is fine.