Adding new Attribute Interfaces to java-api.

[Cantor, Scott]

On 9/26/13 3:53 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>How about adding ResolverPlugin, AttributeDefinition, and
>DataConnector interfaces, but not AttributeResolver and
>AttributeFilter, for now.

Those are the primary ones I'm likely to care about right now, because of
the web flow thing that changes the integration model for the big
subsystems.

>Rather than renaming BaseResolverPlugin, BaseAttributeDefinition, and
>BaseDataConnector to match our convention that Base* classes do not
>implement an interface, I'll propose that we relax that convention
>further.

No strong feelings, but I did go ahead and fix a couple of mine.

>In another thread, apologies for mixing them, I suggested using the
>"IdP" prefix for interfaces, but after further review I do not like
>that very much in idp-attribute-resolver-api.

I don't care all that much there, it's the cross-mixing cases that are a
problem. There's no other current use of "AttributeResolver" obviously.

>Not sure what the plan is for PrincipalConnectorDefinition at the
>moment, but it too could extend ResolverPlugin.

The hope I think is for that to become a SubjectCanonicalizationAction
subflow, but there's an open question as to whether that should be left
the way I did it for now, or have an actual class or interface defined.
Either way, I don't think it would be part of resolver-api anymore.

-- Scott