Interfederation

[Scott Koranda <>]

On Fri, Feb 28, 2014 at 2:46 PM, Tom Scavo 
<>
 wrote:
> 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.

For what it is worth, my expectation for the term "production metadata" is 
that
it is a metadata aggregate feed that is schema compliant, signed, and that has
a "proper" validUntil timestamp

In short, it should not break my SPs that will consume it.

I do not expect that InCommon is making any statement about the
operational quality of the
entities within it.

Put another way, the word "production" is an adjective applied to the
metadata. It is
"metadata processed and delivered in a production quality way" and not 
"metadata
about entities operated in a production quality way".

HTH,

Scott K


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