Hi Darren, Thanks for the detailed feedback. It is much appreciated. Tokens must support synchronous sessions. We wanted to be clear that tokens must continue to support the current way of doing things and not switch to only supporting async sessions. The input to C_AsyncComplete is CK_ASYNC_DATA_PTR so C_AsyncComplete can update any of the fields in the structure without them needing to be pointers. That being said, by the same logic, CK_OBJECT_HANDLE_PTR should just be CK_OBJECT_HANDLE. I ll update. The original buffer refers to the buffer supplied to whatever function was called. I think it s always a buffer input to a function to contain the output value (i.e., from C_SignFinal, C_Encrypt, etc.). I view this as a buffer input to the function, but you re seeing it as a buffer to contain output. I m happy to call it whatever makes it clearer to everyone. The values in CK_ASYNC_DATA are not input values. They are exclusively output values to be filled in by the C_AsyncComplete function. ulValue and pValue are for the caller s convenience so that the caller does not have to keep track of the buffer. If C_AsyncComplete returns CKR_PENDING what happens to the CK_ASYNC_DATA structure is undefined. If anyone has language that would help improve the clarify of this I ll add it in. The intent of the red text is to cover a reboot or restart of the calling application. To enable an application to start an operation, quit, and then check on it later. We did not have a discussion around authentication requirements and it s up to the module as to what restrictions to place on the session trying to join. We have left the meaning of the ID up to the particular module. My goal was to specify it to the point where it was possible to implement the functionality and leave the details to the implementers. Indeed. I ll fix. pData and ulData are input to C_AsyncJoin so that they can be returned in the future C_AsyncComplete call. They can be NULL if the original function, say C_GenerateKey pair (which is what got me into this mess in the first place), doesn t take a buffer. Something stating that implementer s should carefully consider whether or not to use the supplied buffers as the caller may quit on them seems reasonable to me. Anyone care to suggest some language? As in 6, pData and ulData are input to C_AsyncJoin so that they can be returned in the future C_AsyncComplete call. The big thing that was confusing to me at first is the whole C_AsyncComplete NOT taking input values. My first example had C_AsyncComplete returning CKR_BUFFER_TOO_SMALL and then being called again with a properly sized buffer, but that s not how it would work (thank you Dieter for explaining my own proposal to me). If C_AsyncComplete returns CKR_BUFFER_TOO_SMALL, the application needs to call the original function again with a properly sized buffer (C_SignFinal then C_AsyncComplete then C_SignFinal again with proper buffer then C_AsyncComplete). I ll update the doc with changes for 2 and 5 above and with any changes arising from the next email on the subject