RE: [security-services] Affiliation ID

["Scott Cantor" <cantor.2@osu.edu>]

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

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

-- Scott