> Assuming we're talking about the same thing (that the SP needs to be
> able to tell the IdP that it wants a new persistent relationship if
> one doesn't already exist) -- it is needed.
That's the implied semantic already. The question is why an SP would need to
be able to say that it only wanted an existing identifier and not a new one,
if necessary.
> The SP needs to be able to represent such an option to handle the case
> where it has presented the user with an option to use their IDP
> identity at the SP (e.g. the Passport button on Ebay) which is a
> clear indicatation that the user wants the federation.
Sure.
> Of course, in such a case, the IdP can still confirm the federation
> with the user, but will, in the right circumstances accept the SPs
> request without needing additional confirmation and create the new
> permanent relationship with the user.
If the issue is confirmation, then the real distinction is not "create a
federation vs use an existing one", but rather "I got consent from the user
for you to create a federation" vs "I want one, but you need to ask". That
strikes me as fairly dubious as a principal (I suppose a signed AuthnRequest
provides some comfort here), but either way it's something that could be
handled via that consent flag thingy and not by reverting NameIDPolicy to
the more complex ID-FF model.
-- Scott
