anchor.diff:  include::{sourcetestdir}/eu/europa/esig/dss/cookbook/example/snippets/OCSPSourceSnippet.java[tags=demo-online]
   ----
   
  +=== Other implementations of CRL and OCSP Sources
   
  -=== Other implementations of CRL and OCSP Sources
  -Such sources find the status of a certificate either from a list stored locally or using the information contained in the advanced signature or online way. Here is the list of sources already implemented in the DSS framework:
  +Other revocation sources find the status of a certificate either from a list stored locally or using the information contained in the advanced signature or online way. Here is the list of sources already implemented in the DSS framework:
   
   * CRL sources
   ** `OfflineCRLSource` : This class implements the `OfflineRevocationSource` and retrieves the revocation data from extracted information. The code is common for all signature formats and CRL contents are injected by its sub-classes :
  
positive.code: ** `OnlineOCSPSource` : Retrieves OCSP responses from online source.
  ** `JdbcCacheOcspSource` : Implementation of the `JdbcRevocationSource`. This implementation allows storage of valid OCSP entries to a defined `DataSource` and retrieve them locally.
  
  
  
  === Check OCSP or CRL first
  Since version 5.9+, DSS allows the use of a RevocationDataLoadingStrategy. The latter defines logic for loading OCSP or CRL data. Two strategies are available:
  
  * OCSPFirstRevocationDataLoadingStrategy: loads OCSP first, if not available or the response is invalid, then tries to load CRL and returns the first succeeded result. This strategy is used by default for revocation retrieving.
  * CRLFirstRevocationDataLoadingStrategy: fetches firstly CRL response, if not available, tries OCSP and returns the first succeeded result.
  
  See section <<certificateVerifier>> for an example of how to use a RevocationDataLoadingStrategy.
  
  Using an OCSP first has some advantages. A first one is that there is a potential gain of freshness compared to using CRLs. In case the OSCP sends queries to a database that is updated in real time or every x hours, the information fetched by the OCSP is more recent (thisUpdate field) than the information contained in the CRL, given that the CRL is built from that database. In the worst case the OCSP uses the data contained in the CRL and they both have the same thisUpdate field. The information fetched by an OCSP will never be older than the one obtained from a CRL.
  
  A second advantage is that the certificate that signed the OCSP response might contain an OCSPNoCheck extension. This extension indicates that the revocation data of the certificate that contains the public key linked to the private key that was used to sign the OCSP response does not need to be checked.
  
  WARNING: When the OCSPNoCheck extension is used and the OCSP responder's key is comprised, it is as if the key used by the CA to sign the CRL was compromised. The whole hierarchy falls down. To lower the risk, the CA might decide to issue certificates of OCSP responders with a very short lifetime and decide to renew them frequently.
  
  A third advantage of OCSPs is that getting the response takes less time than with CRLs. CRLs can take a long time to be downloaded. There is also no obligation to sort CRLs according to serial number which means that the whole list needs to be browsed until finding the searched serial number.
negative.code: include::{sourcetestdir}/eu/europa/esig/dss/cookbook/example/snippets/CRLSourceSnippet.java[tags=demo]
  ----
  
  The interface `OCSPSource` defines the method which returns `OCSPToken` for the given certificate/issuer certificate couple:
  
  [source,java,indent=0]
  .OCSPSource usage
  