IdPAttribute -> IdentityAttribute ?

[Tom Zeller]

> 1) Whilst I do care about names I don't care enough to add entropy.
> However, during my mercifully short exposure to it I did learn to hate
> Hungarian.

Bike shedding, yak shaving, name smithing ...

> 2) I don't think that this helps in disambiguation which feels like the best
> reason to do this.  To me (but bear in mind that I know this code pretty
> well) the current code makes it pretty clear what is going on.
>
> So:
>
> resolver.resolverAttributes(context)
> List<IdPAttribute> attributes = context.getResolvedIdPAtributes();
>
> Describes what is going on just as well as your example.
>  - IdPAttribute is qualified because of [dis]ambiguation issues.  Hence the
> getter id qualified.
>  - The local 'context' variable is not ambiguous at this point (I am
> assuming) so not qualified)
>  - Ditto the local 'attribute'.

Yes, agree.

For the list, Rod and I chatted earlier this week, and I asked him to
be open to other prefixes than "IdP" for the newly refactored
IdPAttribute, because ... well ... I am still getting used to it.

We talked about how disambiguation was the purpose of name
qualification. Did I get that correct, Rod ?

And, so, I think IdentityAttribute is more descriptive than
InternalAttribute, which is more correct than IdPAttribute.

In the end though, I am okay with the "IdP" qualification, especially
because it is shorter, but I liked "Identity" from the perspective of
an IdM product.