John,
Thanks very much for your review! I'll attempt to answer/comment where I
know something about your question, and I've snipped out the other
questions - see inline below:
ext John Hughes wrote:
> Comments below:
>
> John
>
> *******************************
>
>
> - lots new terms are defined and used: "session authority, session
> participant, identity provider etc etc) For the reader it would use useful
> to define these terms more clearly - and perhaps up front (or at least refer
> out to the glossary)
Yes, agreed.
> - line 740 SessionIndex. Would like to see this better defined. Why called
> SessionIndex - would not SessionID be a clearer term?
Well, the reason I can specifically think of is that I wanted to make it
clear that this should *not* be any kind of identifier such that session
participants could collude to determine the identity of the Principal.
And, this value is basically an index on a session cache at the session
authority.
But, if we think this definition is not useful, then I don't mind
changing it...
>
> - line 1095 Consent. To assist in interoperability should this not be
> defined as boolean?
Actually, there should be a list of URNs specified - I just think they
haven't yet been specified somewhere, but they will be. So there may be
more than two values for this attribute...
> - 3.7 Font of this section wrong
Yes!
>
> - 3.7.1 session authority not defined in previous section
OK
>
> - line 1966 "service providers" -> replying parties?
>
OK - cut-and-paste error... I think these should really be "session
authority" and "session participant" in common with the rest of the section.
> - line 2011 Session Participant Rules on new line as title?
OK
>
> - 3.7.3.1 no text describes processing if a session participant does not
> get back the LogoutResponse
The section you note is about the session authority, and the session
authority (as Hal stated at the F2F) is going to log the Principal out
anyway, and is just informing the session participant that it has done
so. The session authority may still inform the Principal that he/she may
not be logged out at some particular SP (as the SA did not receive a
LogoutResponse from that SP). The SA may also still attempt to send
another LogoutRequest to the SP if they wish, in the hope that this time
they will get a response. I could specify rules to that effect, but they
wouldn't be particularly strong (ie. the SA MAY send multiple
LogoutRequest messages targetting the same SessionIndex/NameID) but that
seems like an implementation decision.
In the case the SP sends a LogoutRequest, and doesn't get a response,
then again they could still choose to try again (currently unspecified,
but not disallowed) or if the Principal is currently browsing at their
site, they could redirect the user to the SA to attempt logout directly
from there, or log the user out at the SP, and present them a page
saying that the SP was unable to logout the Principal anywhere other
than its own site. Again it seems more like an implementation decision.
These are good questions though.
Cheers,
- JohnK
