Interfederation

["Cantor, Scott" <>]

On 2/28/14, 3:46 PM, "Tom Scavo" 
<>
 wrote:
>
>I don't know what you mean by "production." We've talked about this
>before---in the context of entity attributes---there is no way to
>define "production" that will make sense to even a majority of people.

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, 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.

>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.

>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.

>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.

If you're not suggesting some kind of follow up, then you're just dropping
the entity, 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, but it doesn't warrant
putting them into the previous aggregate in the interim, IMHO.

-- Scott