RE: Hal's votes RE: Ballot for Issue Groups 2, 3, 4, 10, 12,and 13 attached

[Hal Lockhart <hal.lockhart@entegrity.com>]

Darren Platt wrote:
> I agree we don't want that, and I don't think that is the 
> goal of these
> requirements.  Instead, the goal is to say that the 
> individual 'destination'
> security domains can use this information any way they want.  
> The domains
> may choose to check with the 'source' security domain each 
> time a local
> session is used, at intervals, or not at all.  They may 
> choose to ignore
> explicit logouts sent to them by the source security domain.  The
> requirement should be to define a way within SAML that this 
> info could be
> communicated between security domains.  What the domains do 
> with it is up to
> them.  I also don't think that we are specifying that we link all SAML
> assertions to active sessions either - I'm not sure if that 
> was implied by
> your comment.

Orchard, David wrote:
> I agree with Darren's comments.  I would like to standardize 
> the message
> formats, not standardize the behaviour on the destination 
> end.  This is very
> akin to what XML has done.  For example, XML defines many 
> things as "errors"
> that must be "reported" to an application.  But there is 
> little mention made
> of how the reporting is to be done, how the application 
> could/should deal
> with the error, and when processing can/can't continue.  
> 
> So I think we are in agreement that we want to standardize the
> messages/protocols/assertions/bindings, but not require 
> end-point behaviour.

I do not understand what "logout" means or what sort of conformance will be
required if a person who has been "logged out" can continue to gain access
to resources by presenting SAML assertions. I don't think the XML strategy
is appropriate for a security standard. Security consumers like to have
definite knowledge about questions like "Is access allowed?" It's okay to
say "reason codes are optional" or something of that sort, but it must be
possible to how security critical decisions will be made by a conforming
implementation.

Personally I am willing to say that (for example) an Attribute Authority
issues a statement "Joe is an authorized purchasing agent" that by policy
expires in 4 hours. I can live with the risk that he might get fired in one
hour. However, if Joe is associated with a session and some authority has
decided that this session should be considered "logged out", it seems to me
much more dangerous to say I can feel free to continue to treat whoever is
at the other end of this session as Joe.

I guess if I thought that this laissez faire attitude towards session
management was general I would have not had the same concerns. However, I do
not think this is so. for example, I remember someone else pointing out
during one of the reviews of the producer/consumer model that session
assertions might be an input to a PDP.

Hal