Metadata support: Supported resolver query semantics; Iteration

[Cantor, Scott]

On 8/12/13 5:19 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>In the new API, the query input is not fixed, it's a CriteriaSet (set of
>Criterion).  My initial feeling was that, like in v2, an
>EntityIdCriterion would be mandatory.  Then I thought, we'd better
>discuss.  Did/do we have any intention of supporting queries using the
>MetadataResolver API that *don't* include an EntityIdCriterion?

Looking at a broader set of use cases than the IdP, probably I could come
up with some, but not any that the IdP will hit.

>For example:
>1) return all EntityDescriptors that have a certain role (e.g.
>IDPSSODescriptor)
>2) return all EntityDescriptors that have at least 1 role that supports
>SAML 2 protocol
>etc.

See above. Some of those are possibly relevant for discovery purposes, but
that isn't an IdP use case.

>Note that all the other current existing criteria are really about
>qualifying things based on RoleDescriptors, and we have a draft
>RoleDescriptorResolver already (which wraps a MetadataResolver) whose
>purpose is to support querying for RoleDescriptors as the output.  So
>what we're really talking about here is other kinds of use cases.

Don't know how it aligns, but there are reasons one might want to find a
matching entity and role, but still return the entity if no role can be
found. At least there are in the SP.

>I *think* in Columbus we had discussed potentially having another
>interface provide an API like: Iterable<EntityDescriptor> etc.
>Resolvers that can could optionally support this API also. This could be
>used for the basic iteration cases.

That's what I recalled. And our time right now needs to be spent on what
the IdP needs, so keeping things separate is a reasonable way to do that.

-- Scott