security-services message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [security-services] When does an IdP know that a user has successfullyfederated with an SP?
- From: "Conor P. Cahill" <concahill@aol.com>
- To: "Scott Cantor" <cantor.2@osu.edu>
- Date: Tue, 27 Apr 2004 20:53:47 -0400
The way I look at things, the only requirement in a federation is that
the IdP agree to issue an identity handle for the user when requested
by the SP (perhaps with the user's consent on a case by case basis).
There is no requirement that the SP create, associate or otherwise do
anything on its system as a result of the federation.
If the IdP is really concerned that the SP received the identity
handle, a) the IdP can use the artifact model for communications (it's
much more likely that the IdP will know whether or not the response is
received by the SP on the back channel, b) the IdP can, after some
period of time, send a registername identifer requuest (or whatever
scott's named it now :-)) to the SP using the same new ID (the request
will fail if the SP doesn't know about the old ID).
I would also say that an SP must be prepared to get identifiers that it
has not previously received and to correctly handle the situation
according to it's policies (perhaps asking the user to do an account
association at that time, or perhaps returning an error to the IdP).
I think there is no need to add any level of two phase commit semantics
to ensure that when an IdP assignes an identifier it is actually
received by the SP.
Just my $.02.
Conor
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]