Various services may wish to provide users with information regarding their accounts and privileges, such as WebAccount or portals. In light of the potential redesign of the existing ID system, a generic interface to this data will prevent unnecessary recoding of these applications. The following are requirements of OIL:

1. Modularity. New backend modules providing data may be designed and deployed without making non-configurational changes to OIL.

2. Strong authentication. Authentication must fulfill the modularity requirement. Strong authentication requires user-level credentials, such as those provided by Kerberos or WIND. "Magic token" authentication to allow all requests from a given server or service to succeed are not permitted.

3. High availability and redundancy. To the extent possible given the nature of the backend modules implemented, OIL must be distributable across multiple servers to allow for appropriate scaling and reliability. No single points of failure are permitted (as possible).

4. Content neutral. The protocol used by OIL must make no assumptions about the content of the requests passed to the backend modules or the responses generated.

1. User access web site providing relevant information.

2. Web site provides authentication via WIND and obtains a suitable token.

3. Web site passes token, backend module name, and any module arguments to OIL server. XML may be suitable for this transaction.

4. OIL verifies the token, parses the module name, and passes the arguments (if any) to the appropriate backend module.

5. The backend module performs the requested operation and passes result information back to the OIL server. XML may be suitable for this transaction.

6. OIL passes the result object back to the requesting web site.

There is currently no notion of "registered" services. However, service registration could conceivably be required, possibly using WIND to handle the verification of the service.

OIL may restrict where requests can come from via SSH or client auth SSL. This is to prevent an off site service from redirecting a user to WIND, obtaining a single use ticket in the name OIL, then passing that ticket back with a request to make a change. While this is not worse than a remote site asking a user for their password and then initiating an FTP or telnet session, the added security may prevent future problems in a more strongly authenticated infrastructure.

• OIL README