A digital certificate is the binding of some identification to a public key in a particular domain. When a trust domain authority issues (creates and signs) a certificate to a subject, it binds the subject's public key to the identity. This binding obviously can be verified through the signature verification process. 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 Trust Policy (TP) governing the usage domain of the certificate. A digital certificate is a subject's credential in cyberspace that cannot be forged.

The use of digital certificates is the basic premise of OCSF design. The OCSF assumes the concept of digital certificates in its broadest sense. Applications use digital certificates as credential for:

• Identification
• Authentication
• Authorization.

The applications interpret and manipulate the contents of certificates to achieve these ends based on the real-world trust model they chose as their model for trust and security. The primary purpose of a TP module is to answer the question, "Is this certificate trusted for this action"? The OCSF TP application programming interface (API) determines 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 following:

• Application domain
• Trust model
• Policy statement for a domain
• Certificate type
• Real-world operation the user is trying to perform within the application domain.

The trust model is expressed as an executable policy that is used 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 complete extensibility of certificate-based trust on every platform hosting OCSF.

Different TPs define different actions that an application may request. Some of these actions are common to every TP, and are operations on objects that all trust models use. The objects common to all trust models are certificates and Certificate Revocation Lists (CRLs). The basic operations on these objects are sign, verify, and revoke.

OCSF defines a set of API calls that should be implemented by TP modules. These calls allow an application to perform basic operations such as verify, sign-on certificates, and CRLs. More extensible operations can be embedded in the implementation of these APIs.

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 needs only to build in a list of the authorities and certificate issuers it uses.

Trust domain authorities also benefit from an infrastructure that supports TP modules. Trust domain authorities are ensured that applications using their modules adhere to the policies of the domain. 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 Certificate Library (CL) modules or one or more Data Storage Library (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 one or a small number of certificate formats. A TP implementation may invoke a CL module and/or a DL module to manipulate certificates.