> Hallvard Furuseth wrote:
>
> 4. Authorization State has been changed to include
>
> > It is noted that other events both internal and external to LDAP may
> > result in the authentication and authorization states being moved to
> > an anonymous one. For instance, the establishment, change, or
> > closure of security services may result in a move to an anonymous
> > state, or the user's credential information (e.g., certificate) may
> > have expired. The former is an example of an event internal to LDAP
> > whereas the latter is an example of an event external to LDAP.
>
> As I wrote in message
> <http://www.openldap.org/lists/ietf-ldapbis/200510/msg00012.html>,
>
> "internal" events that revert the auth to anonymous can lead to major
> breakage at the client side, e.g. for clients that treat noSuchObject
> as information that the some value is not present in the directory.
> At our site, e‑mail to valid addresses would bounce since LDAP informed
> the mail system that the address is not present.
>
> I suppose the draft could allow for server admins to configure such
> behaviour, and add warnings about it, but unless there is a strong call
> for this functionality I don't see a good reason for blessing it.
>
> If this change was done in response to the invalidated associations
> discussions, this is not the right answer. The possibilities that I am
> aware of is for "unacceptable" requests could get some "didn't perform
> the operation"‑result code, or cause the the server to close the
> connection.
>
I agree with Hallvard on this. It seems that this situation really could leave the client clueless as to its current state and the need to take action to reestablish its desired authentication state. I see three possibilities for the server to communicate an event that has caused the authentication state being moved to anonymous:
1. Use an unsolicited notification
2. Send a notice of disconnect
3. Use a specific result code in subsequent operation responses
#1 is probably outside the purview of the ldapbis charter; I view it as adding a new element to the protocol. #2 would work indirectly by forcing the client to reestablish a connection and the desired authentication/authorization state. #3 might require overloading an existing result code such as unwillingToPerform or strongerAuthRequired (a bad idea, I think) or adding a new result code (probably outside the purview of the ldapbis charter).
None of these options seem particularly nice, but I believe we need to choose one of them.
Roger