[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Comment on sstc-saml-glossary-2.0 (also closes AI #0114)
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]