Function use in the IdP

[Cantor, Scott]

On 11/15/14, 9:16 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>It turns out that there are only three, all in metadata processing:
>
>	SignatureValidationFilter can take an injected Function<XMLObject,
>Set<String>>.  This is used "for extracting dynamic trusted names from
>signed metadata elements.".  It strikes me that anyone who wants to 
>override
>PKIX in JavaScript deserves everything they get, but I suppose we might
>provide such a function?

It's probably not a crazy idea. Keep in mind that's not PKIX at runtime, 
but in verifying metadata, and I like to be as flexible as possible in 
that area.

>	FunctionDrivenDynamicHTTPMetadataResolver can take an injected
>Function<String, String> to construct the URL from the provided EntityID.
>It strikes me that this might usefully be scripted, however we already
>provide the TemplatedRequestURLBuilder (which is the third consumer of an
>inject Function<String, String>) and so we may have this base covered?

I'd let Brent comment on that.

>Moving finally on to Predicates, as far as I can see the only use (apart
>from metadata aggregator) of Predictate<T> in a setter, where T is not a 
>PRC
>is in attribute consent, where we inject a Predicate<Attribute>.  This
>setter is not exposed in the user configuration, rather it is hard wired 
>in
>system.  It seems to me that while it might be interesting to allow 
>scripted
>selection of attributes, at this stage in our discovery of how consent 
>will
>work we are better off keeping everything hidden (and thus unsupported) in
>system.

That seems sensible.

-- Scott