Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] questions to InCommon Ops (John and Tom)

Subject: Interfederation

List archive

Re: [inc-interfed] questions to InCommon Ops (John and Tom)

Chronological Thread 
  • From: Scott Koranda <>
  • To:
  • Subject: Re: [inc-interfed] questions to InCommon Ops (John and Tom)
  • Date: Tue, 26 Feb 2013 14:01:34 -0600
  • Authentication-results:; dkim=pass (signature verified)

On Tue, Feb 26, 2013 at 1:30 PM, Cantor, Scott
> 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
> 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?


Scott K

Archive powered by MHonArc 2.6.16.

Top of Page