Evaluable criteria

[Brent Putman]

On 6/2/15 9:40 AM, Cantor, Scott wrote:
> On 6/2/15, 9:15 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
>> Offhand, it seems there's an easy solution: make three different Criterion classes, one for each type, then give CriteriaSet intelligence to do any/all/other combinations for multiple matches. I guess I'm making an academic argument at this point since I clearly haven't spent as much time as you have, so I'll just trust that the current design is best for the given cases.
> You can have three different classes, but they can't implement a common generic interface. You end up where we are, supporting explicit Criterion classes, so it's not really much of a change.

Yes.  I leapt over this logical consequence in my original message b/c I
thought it was obvious but: making the caller supply all 3 predicate
types seems bad, because it means the caller has to know all about the
internal impl details of the resolver.  Which in reality it can't.  So
you pass a single criterion holding data (only), and let the resolver
decide how to evaluate that.  In the abstract filtering credential
resolver case, it does map them to predicates which it can then eval.


>
>> That seems odd to me. What's the point of caller having control over criteria if he/she doesn't know what types are in play for criteria evaluation?
> Because the types in play are the business of the resolver. You might know some or all of the public types involved, but the internal implementation may be entirely different. If you stored metadata in a database, you would never want to evaluate an entityID criterion by running a Predicate over EntityDescriptor, you'd issue a select. You need an actual EntityIDCriterion to give you the where clause.


Exactly, that's the "lookup" criterion vs "predicate" criterion issue. 
You can't know what a resolver needs.  See my last note re: a batch
metadata resolver vs a dynamic one.

Another example is a chaining TrustEngine where the first in the chain
is an explicit key engine that uses the criteria to lookup trusted
Credentials from a CredentialResolver, and the second in the chain needs
to use the same criteria to lookup PKIXValidationInformation for PKIX
CertPath eval.  Either the criteria has to just be data that is evaled
by the trust engine as appropriate, or else you have to pass 2
completely duplicate sets of Predicates - which in reality you can't
since the caller won't even necessarily know what TrustEngines impls are
in use, or the impl details of each.

The only reasonable thing I think a caller can expect vis-a-vis
Predicates is:  if you have FooResolver which returns instances of Foo,
then it's not unreasonable to support passing in some instances of
Predicate<Foo>, to filter the results.  (What the CredentialResolvers
currently support.)  Anything else is exposing too much resolver impl
detail to the caller, IMHO.

But as I've argued, you can't really support passing *only* predicates,
unless the pre-filter collection of candidates is known to be small
enough to support efficient evaluation.  And that's in general not a
valid assumption for a batch metadata resolver.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150602/b78bd01f/attachment.html>