Metadata support: Supported resolver query semantics; Iteration

[Cantor, Scott]

On 8/12/13 6:17 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Yeah, I was mainly concerned about whether we were going to screw people
>using the OpenSAML-J metadata providers to implement discovery
>interfaces.  I assume our CDS uses that, but not sure.

Probably so. I think we need to look at it eventually, but having a
separate interface is good enough for now.

I don't think the future of the CDS itself is clear at this point and will
eventually have to be discussed.

>So if you want both the EntityDescriptor and
>RoleDescriptor when the latter is found, it's just: resolve the role
>with RoleDescriptorResolver and then getParent() to get the
>EntityDescriptor.  However if you want the EntityDescriptor in the case
>where no RoleDescriptor was found, that's going to be a second
>resolution against the Metadata(/EntityDescriptor)Resolver

Yes, I see.

>I guess a more fundamental question here is: should the
>Metadata(/EntityDescriptor)Resolver really process any input criterion
>other than entityID?  I guess entity attributes would be one case,
>perhaps other arbitrary Extensions.

Right.

>But the role-related criteria seem
>to make less sense.  Is it useful for it to support "search on entityID
>X and role Y" if it's still going to return the whole EntityDescriptor
>with *all* the roles, not just role Y?  If you want just role Y,
>presumably you'd just use the RoleDescriptorResolver instead.  Same
>thing for protocol and binding location, the other criteria which Chad
>had already defined.

Well, I think looking for all the IDPs, or the SAML 2.0 IdPs is probably a
discovery use case. So I can imagine it, but not for the reason I was
thinking of that the SP has. Which is not "major", it's just for better
logging and the obscure ability to reference support contact inforamtion.
For example, I can't issue a request to an IdP because of a role issue,
but I can still pull other information out.

-- Scott