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: Ian Young <>
  • To:
  • Subject: Re: [inc-interfed] questions to InCommon Ops (John and Tom)
  • Date: Tue, 5 Mar 2013 16:06:24 +0000
  • Authentication-results:; dkim=pass (signature verified [TEST])

I missed commenting on this last week for some reason...

On 26 Feb 2013, at 20:04, "Cantor, Scott"

> On 2/26/13 3:01 PM, "Scott Koranda"
> <>
> wrote:
>> That something could be as simple as a different Name value in the
>> EntitiesDescriptor element?
> Essentially anything that's part of the signature, yes. Whether any
> particular mechanism makes sense is probably going to depend on what needs
> to see it.

So, what I've done in the UK so far is to make no effort to distinguish the
different aggregates. Many of them are supposed to be drop-in replacements
just with different features so that usually makes sense. The exception is
that in the test aggregate we're experimenting with EntitiesDescriptor
structure and so the document element does not have a @Name attribute; all
the rest have the same one. But our general rule that mere presence in the
metadata only implies technical trust means that we don't have to worry about
this kind of thing too much.

If you're concerned about a substitution attack of some kind, where you
persuade a client to substitute one of your current aggregates for another
one with a view to subverting their trust policy, that may not be enough. In
that case, something like a different @Name or other aggregate identifier
might make senseā€¦ but obviously just doing that adds no security at all
unless all recipients of the higher value aggregates actually check for the
appropriate identifier. Off hand I can't think of a way to configure the
Shibboleth software for such a check, and I'd be amazed to see something like
that in other software. That might then be a justification for using a
different key, as long as one key can get you access to all the metadata you
need; it's fragmentation across multiple trust roots that is the real killer.

-- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature

  • Re: [inc-interfed] questions to InCommon Ops (John and Tom), Ian Young, 03/05/2013

Archive powered by MHonArc 2.6.16.

Top of Page