LionShare will use the federation trust frameworks pioneered by Shibboleth to establish trust between requesting and publishing peers. The current implementation uses PKI technology to identify parties and establish trust. In addition, LionShare is using SAML assertions in ways not intended by the SAML designers. Consequently, LionShare will map the user-supplied credentials to a set of temporary PKI credentials, and then use the PKI credentials to prove that the SAML assertions refer to the user.

The LionShare protocol uses X.509 certificates for authentication between peers. Each peer has two certificates, a "server" certificate which allows the user to share files on a network, and a "client" certificate which allows the user to request files from other peers on a network. The "client" certificate is also used to obtain credentials about the user from a modified Shibboleth Attribute Authority (AA).

The X.509 certificates are obtained from a SASL-CA -- a certificate authority which issues temporary "junk" certificates to LionShare users. Since each institution in the federation may be using a different local authentication system, a common system was needed for use between LionShare peers who may be at different member institutions. X.509 and SSL were chosen as this common authentication mechanism, since the LionShare protocol's file transfer protocol is HTTP-based.

LionShare uses certificates very differently from traditional X.509 applications. Its certificates are created when the LionShare application starts and are destroyed when the application is shutdown. The "client" certificate has a very short lifetime (8-10 hours), and private keys are never committed to permanent storage. Certificates are also specific to each instance of the LionShare peer on the network. For example, if a user is running LionShare on two computers, there will two sets of "junk certificates" for the user.

To obtain these "junk certificates," the user authenticates to the SASL-CA by using the SASL (Simple Authentication and Security Layer) protocol[1]. SASL allows two peers on a network to negotiate at run-time which authentication mechanisms they support[2]. The SASL-CA is very similar to the NMI KCA[3] but adds support for multiple authentication mechanisms. Once authenticated, the user generates two RSA keypairs on his workstation, one each for the "client" and "server" certificates (this is performed automatically by the LionShare application). The public keys from these keypairs are then sent to the SASL-CA, which generates the appropriate certificates. The SASL-CA may query an enterprise directory service, such as LDAP, to populate fields in the certificates, such as DN. Each host institution may set policies for acceptable authentication mechanisms, certificate lifetimes and acceptable public key algorithms and lengths.