Interfederation

[Tom Scavo <>]

On Fri, Feb 28, 2014 at 4:36 PM, Cantor, Scott 
<>
 wrote:
> On 2/28/14, 3:46 PM, "Tom Scavo" 
> <>
>  wrote:
>>
>>I don't know what you mean by "production."
>
> I'm not talking about the entities themselves. What I heard you suggest
> was that the preview file would be used as some kind of staging area for
> things that hadn't been approved yet

Yes, you heard right.

> and I thought our name for the
> main/standard file was "production" at this point. So in effect, that
> makes the preview file non-production, and that's what I was referring to.

Okay, I see what you mean now.

>>Consider my dilemma. An organization submits IdP metadata (having
>>never registered IdP metadata before). How do I know by inspecting the
>>metadata whether the deployment is a production deployment, a test
>>deployment, or whatever? The short answer is: I don't.
>
> I'm not asking you to. I'm just against using the preview aggregate as a
> home for systems that aren't also in the rest of the aggregates.

Okay, I understand the point you're trying to make. So you're saying
you don't agree with the use of the preview aggregate as it's
currently used by UKf, right?

>>With eduGAIN metadata, things will be worse. If we accept entity
>>descriptors without human review, we won't be able to catch those
>>deployments that "smell funny" by inspecting their metadata. We may
>>decide to live that limitation, I don't know. That's why we're having
>>this discussion, I guess.
>
> I believe we can, and must, live with that limitation, or interfederation
> becomes essentially just an extension of the federation itself.

No, I don't think that will ever happen. There's no way that an entity
imported from eduGAIN can ever satisfy the (unwritten) InCommon
Metadata Registration Practice Statement since the latter begins at
the time an organization signs the Participation Agreement.

>>I mean new IdPs in the sense of introducing a new entityID into
>>metadata for the first time. So I'm suggesting (in contrast to what we
>>do now), that we would vet IdP metadata *once*, at the time it is
>>first introduced, and then let updates happen as they may. I want to
>>emphasize that I'm suggesting this for eduGAIN metadata only. InCommon
>>metadata would continue to be manually vetted with each and every
>>update.
>
> If you're vetting it, then you're implying some kind of follow up process,
> it seems to me. That in turn means you're reaching out to system owners
> who had no intention of following InCommon's processes or rules for their
> system, and asking them to change something. That becomes a registration
> process, which is the part we're trying to avoid by interfederating.

Yes, I understand, and no, I'm not suggesting we apply the same
process that we currently apply to InCommon metadata.

> If you're not suggesting some kind of follow up, then you're just dropping
> the entity

Oh yes, I fully expect to "drop entities on the floor" (to use Ian's
term). The only question is how aggressive do we want (or need) to be.

> in which case all you're really saying is that the import from
> eduGAIN might include not just automated filtering but manual. I guess
> that's ok, in terms of process, if it scales

Yes, that's the basic question, I guess.

> but it doesn't warrant
> putting them into the previous aggregate in the interim, IMHO.

Okay.

Thanks,

Tom