Topic for tomorrow : InitializeOutboundMessageContext

[Cantor, Scott]

On 2/6/14, 10:56 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Related note re: implementing the 'conditional' value for the signing and
>encryption flags, for front-channel:  If we decide to support
>'conditional' in v3, and implement analagous to v2, the
>dynamically-selected binding URI (and by implication the Endpoint since
>that's where it comes from ) would need to be resolved before any of the
>signing and encryption can be done. The URI would be used to lookup from
>the Spring context the actual MessageEncoder bean instance that we be
>used, since that's the thing that actually implements the
>binding/transport confidentiality and integrity eval (at least in v2).

If the yuck factor is the order of those steps, I don't think that's a big
concern. I would expect the endpoint check/determination to be done early,
not late. Better to detect the error and bail out than bother doing
authentication.

>  This is pretty yucky, and as we've mentioned, we may choose not to
>support 'conditional' in v3 (although I guess that means we break
>backward-compt with v2 configs - can we actually do that?).
>Alternatively, we have to come up with a different notion of what
>'conditional' means and/or how to evaluate it.

The closest we could come to "breaking" it is to treat conditional as
"always", but I think it's still a useful setting.

-- Scott