The Trust Policy (TP) Module Manager administers the TP modules that may be installed on the local system and defines a common application programming interface (API) for these libraries. The TP API allows applications to request security services that require policy review and approval as the first step in performing the operation. Operations defined in the TP API include verifying trust in:

• A certificate for signing or revoking another certificate
• A user or user-agent to perform an application-specific action
• The issuer of a Certificate Revocation List (CRL).

A digital certificate binds an identification in a particular domain to a public key. When a certificate is issued (created and signed) by a Certificate Authority (CA), the binding between key and identity is attested by the digital signature on the certificate. The issuing authority also associates a level of trust with the certificate. The actions of the user, whose identity is bound to the certificate, are constrained by the TP governing the certificate's usage domain. A digital certificate is intended to be an unforgettable credential in cyberspace.

The use of digital certificates is the basis on which the OCSF is designed. The OCSF assumes the concept of digital certificates in its broadest sense; that is, an identity bound to a public key. Certificates are often used for identification, authentication, and authorization. The way in which applications interpret and manipulate the contents of certificates to achieve these ends is defined by the real world trust model the application has chosen as its model for trust and security.

The primary purpose of a TP service provider is to answer the question "Is this certificate trusted for this action?" The OCSF TP API defines the generic operations that should be defined for certificate-based trust in every application domain. The specific semantics of each operation is defined by the:

• Application domain
• Trust model
• Policy statement for a domain
• Certificate type.

The trust model is expressed as an executable policy that is used/invoked by all applications that ascribe to that policy and the trust model it represents.

As an infrastructure, OCSF is policy neutral; it does not incorporate any single policy. For example, the verification procedure for a credit card certificate should be defined and implemented by the credit company issuing the certificate. Employee access to a lab housing a critical project should be defined by the company whose intellectual property is at risk. Rather than defining policies, OCSF provides the infrastructure for installing and managing policy-specific modules. This ensures extensibility of certificate-based trust on every platform hosting OCSF.

Different TPs define different actions that may be requested by an application. There are also a few basic actions that should be common to every TP. These actions are operations on the basic objects used by all trust models. The basic objects common to all trust models are certificates and CRLs. The basic operations on these objects are sign, verify, and revoke.

Application developers and trust domain authorities benefit from the ability to define and implement policy-based modules. Application developers are freed from the burden of implementing a policy description and certifying that their implementation conforms. Instead, the application only needs to build in a list of the authorities and certificate issuers it uses.

Domain authorities also benefit from an infrastructure that supports TP modules. Authorities are sure that applications using their modules will adhere to the policies of the domain. In addition, dynamic download of trust modules (possibly from remote systems) ensures timely and accurate propagation of policy changes. Individual functions within the module may combine local and remote processing. This flexibility allows the module developer to implement policies based on the ability to communicate with a remote authority system. This also allows the policy implementation to be decomposed in any convenient distributed manner.

Implementing a TP module may or may not be tightly coupled with one or more CL modules and one or more DL modules. The TP embodies the semantics of the domain. The CL and the DL embody the syntax of a certificate format and operations on that format. A TP can be completely independent of certificate format, or it may be defined to operate with a small number of certificate formats. A TP implementation may invoke a CL module and/or a DL module to manipulate certificates.