Assume that institutions simply maintained databases of (pseudonymous or identified) user ids and passwords. Note carefully that the idea here is that a member of the institutional user community has a single userid and password for access to all licensed resources, and not a separate userid and password for each licensed resource.


Using SSL-encrypted forms (which eliminates the problems of transmitting passwords in the clear), it would be fairly easily for a resource to ask for this userid and password securely; one could then have a special purpose protocol so that a resource could securely check whether the userid and password were valid by querying an institutional userid/password database server. Note that SSL can set up an encrypted connection with a server certificate but no client-side certificate.


The special purpose userid/password checking protocol doesn't exist today, but is not hard to design or implement, and since it only needs to be implemented by the resource operator and by an institutional server or two at each licensee institution, it might be much less problematic than making all licensee community users go through the complications of obtaining and installing certificates on their machines. Further, similar protocols for userid/password checking are already in use for validating users to terminal servers (i.e. TACACS, RADIUS); these might be used, or at least adapted.


Users are already familiar with user ids and passwords, including the need to keep passwords secure, to change them, and to pick them well (or at least they are more familiar with these issues than, for example, certificate use). Userids and passwords can be carried in the minds of people rather than being installed on specific machines the way that certificates are; this helps with kiosks, computer labs, libraries and other shared machine settings - assuming that one can teach the user to log off when he or she is finished, rather than just leaving the machine signed on. Probably the biggest problem with this approach - which is not shared with certificates - is that the resource operator obtains a set of globally valid credentials for the user, and has to be trusted to keep them secure. There are also some secondary problems - Trojan horse resources that capture user ids and passwords under false pretenses, for example, are a much more serious threat than they are in a certificate exchange environment.


Let's consider passwords and user ids carried over SSL encryption from the perspective of our requirements definition. It's clear that they are feasible and deployable. Assuming that a protocol for verifying user ids and passwords with an institutional server is standardized and deployed, the amount of work faced either by a licensee institution or a resource operator is quite manageable. Special desktop software is not required for web access; for other protocols, such as Telnet, an SSL- capable Telnet is needed (my understanding is that some of these are under development). Z39.50 credentials are a particular problem because no Z39.50 interface to a service like SSL is currently defined. User ids and passwords are clearly linked to people rather than network addresses of machines. One problem with userids and passwords is that they don't encourage seamless navigation among resources; each resource is going to explicitly annoy the user by asking for his or her userid and password on each visit.


While passwords represent relatively weak security, a system can be put in place to require them to be difficult to guess (by forcing the use of pass phrases rather than passwords, or avoiding use of words in a dictionary), and also insisting that they be changed frequently. The use of an SSL based transport removes the security problems of transmitting them in the clear. The protection provided by SSL will depend on whether US-only (long key) or international (short key) versions of SSL are supported by the user's browser. Userids and passwords are subject to systemic compromise from two perspectives; if the institutional password verification server is compromised, new passwords would have to be issued to all members of the user community. Also, each resource operator now shares in the responsibility for keeping userids and passwords secure; if any resource operator's site is retaining user ids and passwords, and is compromised, this will compromise all other resource operators as well as the home institution (if the institution is using the same userid and password for internal and external authentication and authorization purposes).


Granularity and extensibility. An institutional password server will just verify that a particular userid/password combination is valid (it would also know what resource operator was asking). In situations where an access management decision needs to be made that goes beyond validity of the userid/password pair, the key question is the locus of that decision. The resource operator will either have to maintain a list of valid Ids (identities) or the password server will have to keep information about what resources a userid has access to. Or the institution would have to offer resource operators access to a user attribute database keyed on userid.


Cross-protocol flexibility: because passwords operate at a higher level of abstraction than protocols they are general. Telnet and Z39.50 support should be straightforward, assuming that there is encryption on the link over which the passwords are transmitted, as discussed above.


Privacy and accountability. The use of user ids and passwords transfers personal information directly to the resource operator. This information may be pseudononymous or identified; it will not be anonymous. To this extent, it undermines privacy but offers accountability. Management data faceted by demographic categories will be available from the resource operator only to the extent that the licensee institution provides demographic data as a byproduct of userid/password validation. there is no opportunity for the licensee institution to collect statistical information directly, other than a count of how often userid/password pairs are validated by the various resource operators.


Summary: to the extent that an institutional password verification server controls the export of individual and demographic information, passwords could work surprisingly well in an SSL-protected context. A primary benefit is that users are familiar with the model. There are important missing pieces here, particularly the protocol to permit resource operators to verify userid/password pairs with institutions that issued them. Probably the greatest weakness of this approach is the dependency on each resource operator to protect userid/password pairs, and the danger of systemic compromise due to a security failure on the part of a single resource operator.