Interfederation

[Scott Koranda <>]

On Tue, Feb 26, 2013 at 1:30 PM, Cantor, Scott 
<>
 wrote:
> On 2/26/13 2:19 PM, "Scott Koranda" 
> <>
>  wrote:
>
>>Any and all trust about the current feed is not bound to "the key"
>>used to sign that metadata. The trust is codified in other places and
>>other ways (I can read and sign various documents) and then the key
>>and the signature of the metadata is only a way for me to be sure as
>>an SP operator that I am trusting the right set of bits.
>
> Well, the problem is the key doesn't give you any assurance that the
> document you meant to fetch from a particular location is actually the
> document at that location. You know it's what InCommon signed, but you
> have no way to defend against MITM attacks. That's why it has to expire
> and you have to block a document that doesn't expire.
>
>>So to my mind there is no need to have a new key that would be used to
>>sign a new InCommon metadata aggregate. I simply need to be sure as an
>>SP operator that I understand what sets of bits I am getting (what URL
>>I am fetching from) and that the bits once I get them have not been
>>corrupted.
>
> The URL is irrelevant to the trust decision because there's no
> verification at the transport layer.
>
> So InCommon has two options if it wants to distinguish two aggregates:
>
> - use a different key
> - put something into the aggregate
>

That something could be as simple as a different Name value in the
EntitiesDescriptor element?

Thanks,

Scott K