Attributes and Predicates

[Rod Widdowson]

>  I think you misunderstood my point here.

I did indeed.

> Given a signature of Predicate<ProfileRequestContext>, you can have a
> Function injected of type <ProfileRequestContext,String> to obtain the
> requester.
> 
> With that, I can set a default Function that composes "lookup
> RelyingPartyContext child" and "get RelyingPartyId".
> 
> Somebody can override that to inject a composition of "lookup
> AttributeResolutionContext" and "get requester".

Right so the signature is immutable which. I now understand, is what we both
desired.

What gets plugged in has to be sensitive to where it is being plugged in
(precisely because getting the String is dependent on what you are doing
right now).

I get that and I like it.  It also has the added advantage that
RelyingPartyIdPredicate is ready to use.

I'll note that this will make for some odd traversals - The attribute
resolver will be given an AttributeResolutionContext, have to find the
associated ProfileContext (via another Function of course) and then call the
Predicate which will do exactly the opposite.  I can live with this and to
be honest I'm not sure that we want to open that can or worms.