Interfederation

["Cantor, Scott" <>]

On 2/25/13 3:18 PM, "Tom Scavo" 
<>
 wrote:

>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.)

I haven't yet heard anything but a claim that we need one, but no
discussion as to why. I think you are making this claim because in some
sense you think the current key, acting as essentially a CA, has some kind
of implicit policy OID associated with it such that a different use case
would involve a different policy OID, and thus in this context a different
signing key.

If that's not so, then I don't know what your goal would be in having a
second key. If one looks at the key not as a CA but more like a
traditional certificate or keypair, I certainly don't sign things with
different certificates for other than simple technical reasons. I use one
certificate (or PGP key or whatever) for multiple kinds of emails and
content.

I guess others will have to weigh in, but my inclination is to start with
the assumption no new key is needed unless the case is made as to why. A
big win of not using PKI in SAML is to avoid hidebound assumptions about
why things have to be done in certain ways for reasons obvious only to
people who write PKI profiles.

>- 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.

Initially you seemed to be taking a position explicitly against that
"extreme", but allowing that nobody is saying it has to be "every IdP in
the world", I'm just saying that having a federation-level aggregate of
"many" IdPs is better than expecting every SP to manually create their own
aggregate either on their own or through some interaction with IC.

>- 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.

I don't understand this statement. If anything, IdP metadata is a lot more
sensitive given what they are allowed to do.

I would point out that for this to work for LIGO on the other end (the UK
IdP trusting LIGO), you essentially are expecting the UK Fed to do this
while at the same time claiming it's not at all similar to what IC is
being asked to do.

-- Scott