Attributes and Predicates

[Rod Widdowson]

> Along with Encoders too. That solves the problem of needing to 
> encode things with custom names for a particular vendor, without
> having to duplicate more configuration and do discrete attribute
>release policies just for that case.

Until 10 minutes ago, I thought that the encoders implemented
AttributeResolverPlugin and hence would be covered by the
DataConnector/AttributeDefintion work.  I see that they are not and further
that there is no support for that.  Fixing this almost certainly involves
giving the encode method of AttributeEncoder an extra parameter, being the
context, and allowing it to return null (the calling code already handles
that).  The rest is wiring.

Shall I put in a case ?

> > The code is currently written in terms of a
> > Predicate<AttributeResolutionContext> and so my intention is to allow
> > injection of a Predicate<ProfileRequestContext> and have an injectable
> > Function<ProfileRequestContext, AttributeResolutionContext> to allow the
> > requisite composition.
> 
> We can, but I would note that what you typically *really* want is to
indirect the
> access to particular *data*, not the contexts. For example, a predicate to
> evaluate the identity of the SP/RP is something that we need, and the real
> indirection there is to that name, not to the context from which it is
read.

Right the context is just a HANDLE.  It's what you've got to hand and it
allows you to find out what you need, but isn't what you need.

> In other words, you can plug in a function to read the RP identity from
the ARC,
> or from the RPC if that's somehow "better" in some isolated case. 

My argument is that although having different parameter types to the
Predicate _might_ make more sense in isolation it cannot do so in the round.


> But it's really
> getting that identity that we want to make pluggable. This is easy to do
with
> function composition.

I buy, that but my thought was that if these Predicates really will be
useful in multiple places it would make for easier configuration if the
plug-point in each place was for the same sort of thing, and we devolve the
work (which will usually be unchanged) to the point of plugin.

I'd guess it's possible to create a Predicate<AttributeResolverContext> and
a Predicate<SomeOtherContext> from each other by careful use of spring, but
isn't it easier for our users to just have to implement
Predicate<ProfileRequestContext> once?  

Further we cannot detect at configuration time if someone has plugged a
Predicate<AttributeResolverContext> in to somewhere which expects a
Predicate<ProfileRequestContext> - you'll just get an ugly run time class
cast exception.  So my argument is that - even if it may make for redundant
'there and back' navigation - it is better to have just one type for all
these predicate plugins.

The only counter example I might see is that the actual mechanism to locate
(for instance) the RP identity might be different when resolving attributes
to when encoding them.  In that case a different predicate would be required
in the two places, but I would be inclined to suggest that in order to allow
quick debugging we would want to type-garnish such predicates to allow
config time discovery of misconfiguration

> > To that end, I propose adding a new filter type to allow this sort of
> > configuration.
> 
> Meaning it just wraps the use of a predicate? That's fine.

Right simple and easy.  Probably an hour's work + tests.  We don't even have
to document it, but it does open to door towards your
> drop away in favor of reimplementation on top of predicates,