I'm working on writing a TokenD for a device with two applets on it. The share the same PIN, however there is an oddity that I'm trying to manage inside the TokenD. Applets A and B Select A, Verify PIN Authenticated to A until reset (even if select B) Select B, Verify PIN Authenticated to B until reset, or select anything else, including A I've tried using 2 PIN slots in the TokenD and assigning the relevant Records and KeyHandles to use slot 1 for applet A's items and slot 2 for applet B's items... and it seems to "get it" when it needs to authenticate for using applet B's items the first time... however when it goes and checks for pinStatus the second time around after it had authenticated once to B, it looks for the pinStatus on slot 1... not the slot 2 that is assigned as the owner and the necessary ACL authorizer for decrypt/sign... Is there some other place that needs to be setup to deal with 2 PIN slots properly? the Token class adds the PWSubject and PromptPWSubject to its list of pin types for both slot 1 and 2. the Record and KeyHandle objects put the PinSubject entries for sign/decrypt to slot 1 and 2 for the right handles/etc... the Record and KeyHandle objects also return that the owner is the relevant PinSubject (this wasn't required to get the 1st authorization to use the right slot, but as added in an attempt to get it working for subsequent auth) I've also tried to use the PromptPWSubject, and that brings up a prompt box, but passes an empty PIN back for authentication...... not so useful. Is there anything else I need to do? I've heard that Securityd does tons of caching.. but if requests for pinStatus multiple times for each authentication, so I'd expect that it should use the associated pin number when trying to authenticate for key usage... -- Thomas Harning Jr.