[Auth]why weak/strong AIS is the server's problem, not the protocol's

[david nicol]

the design philosophy at work here is, flexibility through 
simplicity.

Weak AIS is defined as: server returns NULL when it does not know you.

Strong AIS is defined as: server keeps user and does not return
her to client until she has authenticated herself.

Initially I figured that Weak makes it simpler to have a client
consult multiple servers, until I realized that 

        * the magic of Frames
allows a client to request multiple simultaneous strong AIS
handshakes at the same time, and also,

        * an AIS server that uses
401 Authentication Required headers (this is NOT POSSIBLE using
simple CGI, but is straightforward if you don't mind writing your
own, dedicated AIS server, which certainly makes sense for
any serious, central AIS installation) won't need to paint any
user screens -- it can issue its 401 and then issue redirections.

Defining both Weak and Strong behavior into the handshake protocol
is tempting but it does not add any features that cannot be had by
defining parallel AIS services at the same host.  For instance,

        https://ais.dotgnu.int/StrongAIS/

could be the aissri for a strong AIS and

        https://ais.dotgnu.int/WeakAIS/

could be the aissri for a weak ais that both use
the same data for authenticating the users, and both use
cookies with a path of "/" for tracking user AIS sessions.

By keeping the requirements for compliance down two three programs,

        present ::: associate a OTU key with a user and redirect them

        query ::: exchange an OTU key for an identity (in AISXML)

        about ::: provide human-readable information about this AIS server


an AIS server does not have to provide both strong and weak behaviour to
be compliant.