New Function in IdP V3.4/V4

[Cantor, Scott]

> The plan is _not_ to make it invisible.  The current attributes map directly
> onto C3P0 ones so we'd need to put in a parallel set of attributes that map
> DBCP, do the "either one or the other" test and then fork.

Hmm. In that case I think we would need to do *something* for 3.4 then so people can switch to the non-deprecated thing like we planned. I had been assuming the plan was to remap the existing settings or something.

> Urk, not sure why I didn't spot that.  Obvious mitigation is to require/allow an
> encrypted shell command, we can take that to the case; I quail at using xsec,
> although we _do_ have the infrastructure.

We should discuss Friday but I don't know if we'll arrive at a clear consensus. When you combine this with, e.g. remote config sources, I'm just shuddering.

> The basic idea is that in V3 we have driven the sec: namespace into a corner
> such that it is now only used in
>    - LDAP Data connector (<StartTLSTrustCredential>,
> <StartTLSAuthenticationCredential> )
>    - HTTP Client behavior:
>         - HTTPMetadata resolvers (<TLSTrustEngine>),
>         - HTTPDataConnector
>     - Metadata SignatureValidation Filter (<TrustEngine>)

Ah, right.

-- Scott