RE: [security-services] Affiliation ID

["Conor P. Cahill" <concahill@aol.com>]

Scott Cantor wrote on 6/12/2005, 1:45 PM:

 > > So as a persistent id example using an affiliation id, upon
 > > initial access/federation, the IDP would create a opaque id
 > > for the user (assume federation is allowed and active) and
 > > return it to the SP. If the user uses another SP in the
 > > affiliation, then the IDP will "re-use" the opaque id and
 > > send it to the SP. It is then up to the SP as to how they handle this.
 >
 > Right. The assumption behind affiliations is that the SPs are all sharing
 > data somehow. Normally this would be "evil". The AffiliationID and
 > metadata
 > is suppoed to provide a clear statement to the IdP that this is what's
 > supposed to happen.

This is one of the assumptions that is probably true alot of the
time.  However, another very reasonable use of affiliations is to
deal with consent from the user in an easier fashon (when the
user consents to the affiliation that makes up my portal, they
don't have to consent at each of the OEM'd SPs within the portal
and the SPs don't have to try to operate with a shared provider
ID (a way that one might hack this if affiliations weren't
available).

 >
 > > Is there any notion in ID-FF (I know there's none in Saml)
 > > about what MNI means in terms of affiliation ids? I guess one
 > > could send it to the owner of the affiliation (if the owner
 > > was an SP)? But by definition in the saml metadata spec, the
 > > owner does not have to be a member. So I guess (although out
 > > of scope), the IDP can allow the MNI to be sent to no SPs,
 > > one SP, all SPs (then it becomes like SLO), or to individual
 > > SPs (up to the IDP implementer). Does that sound right?
 >
 > Normally I think you'd send it to one SP, but I'm not sure I've ever seen
 > the question raised. Certainly nothing would break if you sent it to
 > all of
 > them, but if it's to be assumed that they share data anyway, sending
 > to one
 > should be sufficient. The caveat in the spec about allowing for
 > propagation
 > to happen covers that I would think.

I would suggest that you send it to the affiliation owner, even if
they are not a member (although I think they typically will be)
and let them deal with the rest of the work internally.

Sending it to any random SP within the affiliation doesn't seem
to make sense to me.

Conor