[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [wsfed] FW: Request for clarification of WSFED issue i008 - Sign-out notification and priority (on behalf of the WSFED TC)
Forwarding this message to the TC list from Don Schmidt.
Regards,
Mary
-----Original Message-----
From: Don Schmidt [mailto:donsch@windows.microsoft.com]
Sent: Friday, August 17, 2007 8:23 PM
To: mary.mcrae@oasis-open.org; support@oasis-open.org
Cc: Marc Goodner
Subject: FW: [wsfed] FW: Request for clarification of WSFED issue i008 -
Sign-out notification and priority (on behalf of the WSFED TC)
I sent the mail below to the OASIS WSFED TC mailing list. I am a
registered, voting member of the TC.
Unfortunately, I received the attached error response from the list server
that I am not authorized to post messages. Can you please help?
I need to send this out by close of business today so that the members have
time to review before our meeting next week.
Thank you,
Don Schmidt
Principal Program Manager
Microsoft Corporation
-----Original Message-----
From: Don Schmidt
Sent: Friday, August 17, 2007 5:06 PM
To: wsfed@lists.oasis-open.org; Paul.Lesov@wellsfargo.com
Subject: [wsfed] FW: Request for clarification of WSFED issue i008 -
Sign-out notification and priority (on behalf of the WSFED TC)
It was requested at the last TC meeting that I respond on the list to issue
i008 with clarifications that have been discussed during previous meetings
and propose a resolution for review by the members. I have separated Paul
Lesov's email description of the issue into separate parts and responded to
each one individually.
<Part 1>
[Issue Description]
>Firstly I would like to clarify on the specification documentation
(ws-federation-1.2.-spec-ed->01.doc).
http://www.oasis-open.org/apps/org/workgroup/wsfed/download.php/24422/ws-fed
eration->1.2-spec-ed-01.doc
>
>According to the depiction III.9.3 of Sign-Out the IP redirects a browser
to clean-up at one service provider and then >once complete redirects a
browser to clean-up at the next service provider. This diagram
depicts sequential, not parallel >sign-out, even though section 4.2 states
that parallel approach SHOULD be used for sign-out.
[Discussion]
The referenced sections of the specification do not contradict each other,
but are potentially ambiguous.
Section 4.2 provides a generic description of the Sign-Out process which is
applicable to both SOAP and browser requestors. This includes a discussion
of both sequential and parallel message transmission, including the
robustness of these methods with respect to the likelihood of completion.
The specification recommends parallel transmission since this approach is
more likely to complete for all endpoints.
Appendix III.9.3 describes the potential sign-out message flow specifically
for the browser requestor case in which all messages must be transported by
the requestor. Since it cannot be assumed that all browser requestors can
transmit parallel requests, the sequential method is depicted as the lowest
common denominator approach. This is consistent with the syntax defined in
section 13.2.4 for sign-out messages, which includes the optional "wreply"
parameter to specify the URL to which the browser requestor should be
redirected.
[Proposed Resolution]
The text in III.9.3 should be clarified as follows:
[existing text]
The figure below illustrates the sign-out flow for a requestor that
has signed in at two sites and requests that the sign-out cleanup requests
redirect back to the requestor:
[proposed text]
The figure below illustrates the sign-out flow for a Web browser
requestor that has signed in at two sites and requests that the sign-out
cleanup requests redirect back to the requestor. The message flow is an
example of the use case in which all sign-out messages must be transmitted
by the requestor. Since it cannot be assumed that all browser requestors
can transmit parallel requests, the sequential method is depicted. This
message flow is enabled by the "wreply" parameter defined in section 13.2.4.
</Part 1>
<Part 2>
[Issue Description]
>The same depiction also indicates some sort of reply being sent from
service providers indicating clean-up complete, >while in section 4 of the
document (first paragraph) there is a statement about sign-out being a
one-way message without >any reply.
[Discussion]
The specification appears to be ambiguous. Section 4 states, "It should be
noted that a sign-out message is a one-way message (that is, it doesn't have
a reply)." Section 13.2.4 describes the possibility of a reply to a
sign-out message using the optional "wreply" parameter.
The intention of the text in section 4 is to convey that operationally
Sign-Out is a best effort operation that is not guaranteed to complete.
Therefore, no completion response can be required or expected. Section
13.2.4 refers to a physical requirement. When multiple sign-out messages
must be transmitted sequentially by a Web browser requestor, it is necessary
to redirect the requestor to the IP/STS repeatedly until all sign-out
messages are sent.
[Proposed Resolution]
The text in section 4 should be clarified as follows:
[existing text]
In typical usage, sign-out notification serves as a hint - upon
termination of a principal's session - that it is OK to flush cached data
(such as security tokens) or state information for that specific principal.
It should be noted that a sign-out message is a one-way message (that is, it
doesn't have a reply). Depending on the type of application that is being
used to sign-out, the process may vary. For example, the implication of
sign-out on currently active transactions is undefined and is
resource-specific.
[proposed text]
In typical usage, sign-out notification serves as a hint - upon
termination of a principal's session - that it is OK to flush cached data
(such as security tokens) or state information for that specific principal.
It should be noted that a sign-out message is a one-way message. No
"sign-out-complete" reply message can be required since the Sign-Out
operation cannot be guaranteed to complete. Further, sign-out requests
might be processed in batch, causing a time delay that is too long for the
request and response to be meaningfully correlated. In addition, requiring
a Web browser requestor to wait for a successful completion response could
introduce arbitrary and lengthy delays in the user experience.
The processing implication of sign-out messages can vary depending
on the type of application that is being used to sign-out. For example, the
effect of sign-out on currently active transactions is undefined and is
resource-specific.
</Part 2>
<Part 3>
[Issue Description]
>Now to expand on ISSUE i008
>
>There were really three points there:
>
>- (1) Identity provider should be certain (as much as possible with
stateless protocol framework) that sign-out requests >sent to service
providers were processed successfully.
>
> In the proposed architecture sign-out is a one-way message. Therefore
it is not possible to provide a confirm/reply >that session is terminated. I
would argue that sign-out should have a reply indicating successful session
termination. >Some parameter should specify to the requestor that
the cleanup is completed at the service provider.
[Discussion]
As discussed in <Part 2>, the Sign-Out operation is not guaranteed to
complete. Even if it completes, the time delay may be too long for a
successful completion response to be useful. Finally, requiring a Web
browser requestor to wait for a successful completion response could
introduce arbitrary and lengthy delays in the user experience.
[Proposed Resolution]
The requested change to the specification should not be accepted. The
revised text for <Part 2> includes an explanation of why this is not
possible.
</Part 3>
<Part 4>
[Issue Description]
>- (2) Priority of sign-out was the second point
>
> I will withdraw priority request from the issue, once I get
confirmation on my clarification above that parallel >sign-out is being used
not sequential sign-out. If parallel sign-out is used prioritizing does not
add any value.
[Discussion]
It does not seem useful to require prioritized processing of sign-out
messages when it is conceivable that Sign-Out operations may be performed in
batch, or may not even complete. Furthermore, what justification is there
for sign-out messages to take precedence over other requests, such as token
issuance or validation?
[Proposed Resolution]
The requested change to the specification should not be accepted.
</Part 4>
<Part 5>
[Issue Description]
>- (3) Informing the user about completed sign-out.
>
> Once Identity Provider receives success sign-out replies from service
providers (1) IP should be able to indicate to >a passive requestor that
sign-out was completed. If some service providers did not return a success
reply to a sign-out >request a user should be presented with that
information as well. I realize that this may be beyond the score of the
>specification but it is not possible without (1).
[Discussion]
As discussed in <Part 2>, it is not possible to guarantee that an Identity
Provider will receive sign-out replies in a timely manner, if at all.
Therefore, it is not possible to require that the Identity Provider will
inform a passive requestor that sign-out was completed.
Note, however, that Web requestors transmit sign-out messages using an HTTP
GET. Thus, in section 13.2.4 the specification does allow the possibility
that a Requestor or Resource IP/STS may return "realm-specific data such as
a string indicating cleanup is complete for the realm." One could imagine
some sort of Sign-Out landing page where the status of sign-out requests
could be recorded to be looked up by a passive requestor. This would be
implementation specific and is outside the scope of the specification.
[Proposed Resolution]
The requested change to the specification should not be accepted.
</Part 5>
Regards,
Don Schmidt
Principal Program Manager
Microsoft Corporation
----------------------------------------------------------------------------
----------------------------------
From: Paul.Lesov@wellsfargo.com [mailto:Paul.Lesov@wellsfargo.com]
Sent: Thursday, July 05, 2007 12:54 PM
To: wsfed@lists.oasis-open.org
Subject: [wsfed] FW: Request for clarification of WSFED issue i008 -
Sign-out notification and priority (on behalf of the WSFED TC)
----------------------------------------------------------------------------
----------------------------------
From: Paul.Lesov@wellsfargo.com [mailto:Paul.Lesov@wellsfargo.com]
Sent: Thursday, July 05, 2007 12:05 PM
To: Greg Carpenter
Cc: mikemci@us.ibm.com; Chris Kaler; abbieb@nortel.com; mkaiser@us.ibm.com
Subject: RE: Request for clarification of WSFED issue i008 - Sign-out
notification and priority (on behalf of the WSFED TC)
Firstly I would like to clarify on the specification documentation
(ws-federation-1.2.-spec-ed-01.doc).
http://www.oasis-open.org/apps/org/workgroup/wsfed/download.php/24422/ws-fed
eration-1.2-spec-ed-01.doc
According to the depiction III.9.3 of Sign-Out the IP redirects a browser to
clean-up at one service provider and then once complete redirects a browser
to clean-up at the next service provider . This diagram depicts sequential,
not parallel sign-out, even though section 4.2 states that parallel approach
SHOULD be used for sign-out. The same depiction also indicates some sort of
reply being sent from service providers indicating clean-up complete, while
in section 4 of the document (first paragraph) there is a statement about
sign-out being a one-way message without any reply.
Now to expand on ISSUE i008
There were really three points there:
- (1) Identity provider should be certain (as much as possible with
stateless protocol framework) that sign-out requests sent to service
providers were processed successfully.
In the proposed architecture sign-out is a one-way message. Therefore
it is not possible to provide a confirm/reply that session is terminated. I
would argue that sign-out should have a reply indicating successful session
termination. Some parameter should specify to the requestor that the cleanup
is completed at the service provider.
- (2) Priority of sign-out was the second point
I will withdraw priority request from the issue, once I get confirmation
on my clarification above that parallel sign-out is being used not
sequential sign-out. If parallel sign-out is used prioritizing does not add
any value.
- (3) Informing the user about completed sign-out.
Once Identity Provider receives success sign-out replies from service
providers (1) IP should be able to indicate to a passive requestor that
sign-out was completed. If some service providers did not return a success
reply to a sign-out request a user should be presented with that information
as well. I realize that this may be beyond the score of the specification
but it is not possible without (1).
________________________________________
From: Greg Carpenter [mailto:gregcarp@microsoft.com]
Sent: Thursday, June 28, 2007 11:11 AM
To: Lesov, Paul
Cc: Michael McIntosh; Chris Kaler; Abbie Barbir; Mike Kaiser
Subject: Request for clarification of WSFED issue i008 - Sign-out
notification and priority (on behalf of the WSFED TC)
Hi Paul,
As a Secretary and Issues List Editor of the WSFED TC I'm contacting you to
convey the TCs request for clarification regarding issue i008
(http://docs.oasis-open.org/wsfed/issues/Issues.xml#i008). In order for the
TC to adequately understand and process this issue we need more information,
preferably in the form of a specific proposal documenting what is needed to
implement the features you mention in the issue.
Best Regards,
-greg
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]