entity descriptors from multiple registrars

[Tom Scavo]

On Wed, Sep 17, 2014 at 10:21 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/17/14, 7:38 AM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>>Suppose a deployment consumes metadata from multiple sources such that
>>its metadata store contains entity descriptors from multiple
>>registrars (i.e., federations). How does Shibboleth distinguish
>>metadata from different registrars?
>>
>>For the IdP, I think I know the answer: Install the
>>mdrpi-match-idp-ext add-on on Shibboleth IdP 2.4 (or later):
>>
>>https://github.com/ukf/mdrpi-match-idp-ext
>>
>>What is the answer for the Shibboleth SP?
>
> None for the moment.

Which answers my question, thanks.

The rest of this message seems to be off-topic for the users list so
I'm open to suggestion where the discussion should take place.

>I really wasn't paying attention at the time or I
> would have argued against creating a custom extension in favor of using an
> entity attribute.

I don't think that's been ruled out. In InCommon, at least, the
previously mentioned extension has not been deployed AFAIK so we're
free to solve the problem any way we like.

> I think when you dig into this a little, though, the answer is that I
> don't care who the registrar is, but what some particular policy is.

If we think that registrars will support multiple policies, then yes, I agree.

> And I
> think that ought to be expressed directly rather than through implication
> based on the registrar

As you probably know, the MDRPI SAML metadata extension carries the
registrar's policy URL in addition to the registrar's identifier, but
if the policy changes, the URL MUST change (according to the spec) so
I'm not seeing much value in keying off the policy.

> or based on a more far-reaching policy statement
> that probably includes many different things, some worth caring about and
> some not.

I'm not following you there but clearly there is much to talk about
(and my need is immediate). Where should this discussion take place?

Thanks,

Tom