There are two ways of doing smartcard client authentication on the web: standard TLS/SSL or custom plugins for the browser. I assume you're talking about standard web browsers (IE/FF/Safari) and SSL authentication.
There are two things that matter for PIN prompts:
- SSL session and SSL session cache of
the browser
- on-card authentication state of the related private key
- the way middleware is implemented.
In the end, from security perspective, it is the card that knows when to "ask for” a PIN - some cards and keys require a PIN for every operation with the key, some cards are OK to get a PIN once and leave the keys in authenticated state until it is removed from the reader or reset by an application.
If the session in the cache of the browser can not be re-used or when the connection is being established, smart card middleware (PKCS#11 on Linux, CryptoAPI/BaseCSP module on Windows or Tokend on OSX) needs to talk to the keys on the card. If the authentication state on the card requires a PIN to be entered, a callback is usually triggered by the browser. Or if the middleware knows it will need the PIN, it will ask it before talking to the card.
There is no 1:1 relation between entering a PIN and actually re-authenticating access rights to the private key and re-authenticating the SSL session.
With standard SSL, you depend on the way SSL is implemented in browsers and can not have a 100% reliable "re-authenticate by entering PIN" on the client side.
If you are using Linux, then with OpenSC (which, AFAIK can use CAC cards) you can set "transaction_reset" in opensc.conf to true, which results in the card being reset after every transaction (every SSL session negotiation) and this way you can be sure that whenever you open a new SSL session, user has to enter the PIN again. This is a client side configuration though, not a server-initiated feature.