A couple of follow ups from yesterdays conversation

[Cantor, Scott]

On 5/10/14, 4:49 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>I have made the control of the resolver plugins and the encoders via an
>attribute "activationCriterionRef "  What was there before was disparate
>and
>confusing. 

Just sent a private note, I was suggesting we standardize on
activationConditionRef. Seems less wonky than "criterion" or "predicate".

>In the first two cases the result is the injection of a
>SecurityConfiguration with but one non-default value - a
>BasicSignatureSigningConfiguration set as the signingCredentials.  This
>last
>also being a default save for the provided credentials.  If I understand
>the
>conversations with Brent and Scott correctly, this SecurityConfiguration
>will be cascaded with with the per profile defauilt, then the per IdP
>default and finally the OpenSAML default.

Yes, I redid all that code last night. I need to verify with Brent what
order to pass them in, but I add the OpenSAML default, the IdP's profile
default (which could be a global default if no profile default is set),
and the RelyingParty configuration. This is done with strategy functions
now, so it can be overridden or changed easily without touching the
actions.

The reason I included the OpenSAML default config is that the resolvers
from Brent currently throw exceptions if you don't give them at least one
config instance, so unless we make the IdP default non-null and guarantee
it will be present, I didn't want to risk passing nothing in.

All subject to change obviously.

-- Scott