The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued.  Therefore, unless otherwise indicated, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. 
Companies rely on printing devices for everyday operations.  Often many printing devices are available in a single building or department, each potentially having several functions.  Companies desire to monitor and control access to, and track usage of, these devices.  One approach to accomplish this is the use of “smart card” systems.  These systems use physical cards capable of storing information, usually on an embedded microchip.  The smart card may contain data personally identifying a user.  This data often conforms to a schema, or data model.  A card reader capable of accessing this information is connected to the printing device and communicates with the device. 
For example, a user desiring to use a printing device inserts a smart card into a smart card reader connected to the printing device.  The smart card reader extracts authentication data, such as a user name and password, from the card and may compare the data to data stored on the printing device or on a backend system, often remote, for authentication purposes.  Once the user is authenticated, information may be communicated to the printing device based on the user's credentials.  This information could come from the data on the smart card or from another source. 
For example, one user may not be able to access color printing capability on a printing device while another user may only be allowed to utilize the scanning capability of a device. 
The disadvantage of this approach to authentication is a lack of flexibility in adjusting the authentication system to utilize different card types and authentication systems.  One example is that a user of the aforementioned system may want to use a new card type or model.  Another example is that a user of the aforementioned system may want to change the data model on the smart cards.  Another example is that a user of the aforementioned system may want to use a different backend authentication system by changing servers, protocol types, or other aspects of the system.  Another example is that a user of the aforementioned system may want to support a new customer with a different environment after the application controlling the authentication has already been developed, compiled and released. 
One approach to the problem has been to rewrite and recompile the authentication application to support the new smart card types, data models, backend authentication systems or new environment.  There are many drawbacks to this approach.  One, it can take a great deal of time and effort to rewrite and recompile the new applications.  If the changes are minor, for example, adding a new server address to the backend authentication system, the effort is considerably out of proportion to the amount of change.  Two, it would be prohibitively expensive for users to upgrade authentication applications on a regular basis to support new customers and new cards or data models.  Therefore, a need exists to maximize the flexibility with which an authentication system may handle changes to the authentication elements such as smart cards and data models.