[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Minutes: SSTC Conference Call (September 22nd, 2009)
Scott Cantor wrote on 2009-10-02: > If you instead mean for this to be front channel, I still think it's > difficult to pull off safely because the ability to assign the identifier in > reverse is really just reversing the role of the IdP and SP in the flow. The > "SP" has to become an IdP and issue what amounts to an assertion in order > for the IdP to be able to validate the user's right to "be" that identifier. To elaborate on this point, what I think you're really after here would be accomplished without any new spec bits, by inserting a reversed SSO exchange in the middle of the outer exchange. In other words... 1. EntityA -> AuthnRequest -> EntityB 2. EntityB authenticates user and realizes it's a new link. 3. EntityB saves off enough state to remember the initial request. 4. EntityB -> AuthnRequest -> EntityA 5. EntityA authenticates user 6. EntityA -> Response -> EntityB 7. EntityB recovers state and creates link. 8. EntityB -> Response -> EntityA I don't see how you avoid what amounts to that, subject to whatever optimizations might be possible. And IMHO, it's a lot of extra work at an SP (which now becomes an IdP) without any obvious benefit, but it isn't anything you couldn't do now if you wanted. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]