Topic for tomorrow : InitializeOutboundMessageContext

[Brent Putman]

On 2/6/14 11:03 PM, Cantor, Scott wrote:
> 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. 

And related: also just occurred to me that, if we do the 'conditional'
eval making use of itself of logic implemented in the MessageEnoder
impls themselves (as it was in v2), that would pretty decide the
question of how we impl the dynamic message encoding stuff. Recall that
that's the "lookup" style vs the "Spring transition-driven" style.  This
would pretty much dictate the "lookup" style, since we essentially have
to lookup the encoder in more than one action: once in the actual
encoding action as before, but now also much earlier in the flow for the
'conditional' eval.  So the lookup component (e.g. from the testbed
idp.SpringAwareEncoderLookup) would get injected in both places.

The other alternative is to just have the confidentiality and integrity
eval logic live somewhere outside the encoders.  But since that's often
binding-specific, that doesn't seem very natural, and we'd have to have
and maintain parallel sets of code for each binding we support.

> 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.

Earlier is better, I agree.

No, the yuck factor for me is just the requirement to make use of the
encoders in places that aren't actually doing encoding.  It's yuckier in
v3 than v2 because of the loosely coupled nature of the Webflow design,
vs the monolithic ProfileHandler in v2 (in the latter it's all inside a
single class, or at least in its base classes).