Interfederation

["Cantor, Scott" <>]

> > I don't understand your resistance to simply creating a republishing
> > agreement rather than creating custom feeds.
> 
> I'm suggesting we do both.

I heard you strongly resisting a simple cross-signing of some subset of 
entities, so if that's not what you meant, I don't think we understand.

I don't hear anybody asking for custom aggregates per SP, so given that it's 
a ton of work, I don't see why we'd want to do it.

> I didn't say that it was. Including "foreign" entity descriptors in
> the InC aggregate conflates (or dilutes) the trust semantics of the
> InC metadata signing key.

Even were that to be true, nobody said it had to be the same aggregate we 
have now.

> InC Ops makes (implicit) guarantees with
> respect to InC entity descriptors in metadata. (Do we need to
> enumerate them?) We can't make the same claims about "foreign" entity
> descriptors so I think we have to introduce a new signing key, that
> is, a second signing key with different semantics. Custom metadata
> aggregates are not a strict requirement but they do isolate the
> entities that new key implicitly covers.

I don't see how you get from "maybe we need a different aggregate" to "it's a 
different signing key". I don't see any good reason for that.

> Btw, at this time we can only aggregate IdP metadata. SP metadata
> aggregation is functionally equivalent to proxying IdP attributes OUT
> of the InCommon Federation. That can't be done without a much larger
> policy discussion, I'm afraid.

It's nothing at all like that. You have nothing to do with moving attributes. 
If you start running gateways, then you're moving attributes.

> That may be a good reason to favor packaging all IdPs in a single file
> but it doesn't change my PoV about a new signing key.

I hesitate to say "all" but I would say that "most" of the point of doing it 
this way is to *not* have a different signing key. I suppose one new key for 
signing any such aggregated feed is better than having one key per source, 
but it's still moving away from addressing the requirement of avoiding new 
verification keys at every endpoint.

-- Scott