Re: [security-services] commets on sstc-saml-core-2.0-draft-06.pdf

[John Kemp <john.kemp@nokia.com>]

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