Interfederation

[Ian Young <>]

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

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

> 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