OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] SLO processing rules

Title: RE: [security-services] SLO processing rules

Scott, so perhaps the text slightly misleading. I know that the SA rules say SHOULD, however, the initial definition (section 3.7 4th paragraph), state that the SA MUST send a LogoutRequest to ALL session participants. Perhaps we can just clarify that paragraph and say that it implies (which I think it does) that the SA MUST send the LogoutRequest to all session participants irregardless of what the response of each individual LogoutRequest is.

So currently the SHOULD implication in the SA rules really applies to the first item (send LogoutRequest to proxying IDPs) and the third item (terminate the session at the IDP). The second item is a MUST because of the language in 3.7 4th paragraph.

In any case, I would propose to the TC to consider the SA rules be changed from SHOULD to MUST -- as I think this is the actual intent of the single logout in the general case.


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Thursday, January 06, 2005 11:31 AM
To: 'Thomas Wisniewski'; 'Greg Whitehead';
Subject: RE: [security-services] SLO processing rules

> 1. I would propose changing
> "that the authority SHOULD try and contact each SP even if one fails"
> to
> "that the authority MUST try and contact each SP even if one fails"
> I think that every SP would want to be contacted and should
> not be omitted because some other SP is offline or does not
> support a back-channel binding.

I used SHOULD because other language around the operation pretty much ceded
most decision making to the session authority about how to process the
logout. For example, the very beginning of the rules say the SA SHOULD do a
set of things in a certain order, but doesn't say MUST. That's not new

> 2. Is it worth it to consider two partial logout subcodes.
> One for a partial logout where all sps that support the
> required binding were contacted successfully (but there was
> at least one sp that did not support the required binding).
> And a second subcode where at least one sp that supports the
> binding fails. The second one would preclude the first.

I don't think it matters. Failure is failure, because the concept of
retrying doesn't work in the current protocol.

> I think it's important that (1) be changed. I don't know if
> (2) really provides much.

I've ceded the token on the specs, so if people want this changed, Rob can
apply it, but there are multiple SHOULDs that would have to be changed and
the change is not to the new material but to basic rule that the protocol
operated by, which was the SA is in charge.

> Note that there's actually a third case/subcode possible for
> a partial logout. This is when front-channel bindings are
> used and the IDP provides the user with an interface to
> select the SPs to log out from.

In this case, there's no subcode at all because there's no LogoutResponse to
send to an SP to complete the logout. The IdP is running the show.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]