<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/2/15 9:20 AM, Marvin Addison
wrote:<br>
</div>
<blockquote
cite="mid:CACOs9MSWWCsVHX87fg7gNm2WoqdCnkxYHVtqqpq+BqE9piuVPw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote>
<div><br>
</div>
<div>I'm still trying to digest this whole thread, but bottom
line for me afaict is that there needs to be some changes to
resolve/resolveSingle in the MetadataResolver type hierarchy
to support my CAS use case of looking up an EntityDescriptor
by endpoint URL. </div>
</div>
</div>
</blockquote>
<br>
Yes. But the operative phrase there is "looking up". I would say
that's correct, vis-a-vis the terminology I've been using. Meaning
it's not a predicate. It can not be the case (at least by default)
that the resolver accepts *only* predicate criteria which it then
applies to an iteration of all its potentially 1000's of
EntityDescriptors. Maybe as an option you can turn on, with the
appropriate caveats re: knowing the size of the metadata you have.
Certainly would not work IRL for something like InCommon or UK
federation metadata.<br>
<br>
And that's for batch resolvers. When you are calling this for real,
you don't know what kinds of resolvers you have in the chain. For a
dynamic resolver, a predicate criterion simply doesn't work. You
have to have a lookup criterion that exposes some data which the
resolver can turn into the appropriate parameter(s) for the call the
metadata responder.<br>
<br>
So in summary, supporting arbitrary predicate criteria to a metadata
resolver (or any resolver) is something we could add for niche
cases, but doesn't really help with either your CAS case, or the
SAML artifact case. For those we need (in batch) secondary
indexes. That's going to be a bit of conceptual work. I'm not even
actually sure how to support non-equality-based index lookups. It's
sort of analagous I guess to whatever RDBMS's do to efficiently
support substring matching on indexed columns on e.g. a "where name
like '%Joe%'. Or what search software like Lucene does to support
full text searching. I get the sense that there's a whole bunch of
computer science in there that I don't know. Hopefully there are
some libraries to help us out... (maybe even Lucene?).<br>
<br>
</body>
</html>