Discussion Topic: Transport confidentiality and integrity; Implementing crypto 'conditional' flag

[Cantor, Scott]

On 2/13/14, 9:35 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>And then as far as the IdP actions and the crypto 'conditional' flag,
>they really just have to examine this subcontext's flags which were
>populated (or implicitly defaulted) earlier in the flow and that's it.
>Very simple, and loosely coupled.

I'm still struggling with how I think the various security parameters
should be placed in the tree, but modulo that question, I don't see
anything to disagree with in terms of all that.

>The only outstanding question in my mind at the moment is whether this
>approach works or not for other use cases and protocols they we haven't
>implemented or considered . So far I haven't come up with any, but that's
>mainly what I wanted to get others' input on.

I think it does by definition because all you're really saying is that
whatever can be known/determined is expressed in a manner that's
independent of the binding/encoder abstractions, which is clearly
necessary since it isn't always related to either. If you could conjure a
use case in which it's impossible to determine from the emergent state of
the system whether the flags are true or not, then by definition nothing
we attempt to use to expose those values is going to work.

Either we have a way to tell or we don't.

>In meantime, I'll just check in these 2 or 3 classes as a straw man (I
>know for me it's often easier to think looking at code).  One of the
>advantages of this approach is that it's simple and easy to implement,
>and if it proves workable, then we're done.

The only comment I have is not really related to this question, but the
earlier notion of how we talk about bindings. Specifically, there's a way
in V2 to express the permissible outbound bindings (it's on the profile
definition in handler.xml), and we need that in V3 (for endoint
determination) but it's not obvious to me yet where to put it.

When I originally thought we needed to think about hanging these flags off
of some kind of binding descriptor, I was thinking that set of descriptors
might be the way we implement that signal of supported bindings.

Anyway, point being, I think with the approach of using a map to lookup
the encoder to use for a binding, we need to just have that map be a bean
we can inject in at least one other spot. For generality, I'd favor having
something called a BindingDescriptor even if there's not much in it, and
have the map be of those objects.

-- Scott