Interfederation

[Tom Scavo <>]

On Thu, Feb 27, 2014 at 2:49 PM, Cantor, Scott 
<>
 wrote:
> On 2/27/14, 12:55 AM, "Tom Scavo" 
> <>
>  wrote:
>>
>>Btw, staging InCommon metadata in this way has significant benefits.
>>It essentially makes test IdPs a non-issue since presumably these
>>would not be released to production metadata. It also makes it easy
>>for participants to experiment with multiple IdPs, which is something
>>we don't support very well today.
>
> I think there's a disconnect in how I would have understood the preview
> aggregate to work. I *never* considered it non-production in any sense. It
> simply had newer production capabilities sooner than the regular one so
> that software compatibility issues would be identifiable.

Yes, you're right, what I've suggested above was never a
consideration, I admit. That said...

> As you're describing it, I would never associate my SP with it, because
> you're telling me it's not production. That's the opposite of what we
> want. We want people with more risk tolerance to test new syntax out.

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.

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. Now sometimes
the deployer will use the substring "test" or "dev" in some metadata
element, and our manual process will catch that, but in general,
there's no way to ensure a production deployment. So the term
"production metadata" is a misnomer. It's production in the sense that
it passed our automatic and manual processes, but that's it.

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.

>>Okay, that would be...interesting. What about the following
>>compromise? What if we manually vet all *new* IdP metadata but let the
>>chips fall where they may otherwise?
>
> I'm not sure what you mean by "new" in that sentence.

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.

Tom