Interfederation

[Tom Scavo <>]

Okay, I'm evidently doing a poor job of communicating today, so let me
summarize the points I'm trying to make as a top post and see if that
helps. I assume I have at my disposal a second signing key, not a set
of signing keys but a single signing key distinct from the current
signing key. Let me refer to these keys as Key1 (current) and Key2
(new). (If you won't allow a new signing key into the discussion, then
we're at an impasse and need to start over.)

- We would continue to publish the InCommon metadata aggregate signed
with Key1. Nothing new there: same content, same key, same location.

- We would publish one or more new metadata aggregates signed with
Key2. At one extreme, we would aggregate all the trusted IdPs of the
world into a single file. At the other extreme, each participant would
receive its own custom aggregate of trusted IdPs.

- Aggregation of SP metadata is a completely separate conversation.
AFAICT aggregation of IdP metadata is mostly technical whereas
aggregation of SP metadata is mostly policy. Thus the motivation to
separate the two.

That's it. That's all I'm trying to say.

Tom

On Mon, Feb 25, 2013 at 2:38 PM, Cantor, Scott 
<>
 wrote:
>> > 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
>
>
>
>