Policies would be handled by adding an AuthContext to the ClientContext containing the current PinId
API
authenticate(PinId,value) -> chkec if value is correct, then store in the authcontext the PinId and store required data in the volatile FS
de_auth(PinId) -> remove data from volatile FS for the PinId and also from the AuthContext (if same)
set_auth(PinId) if data for PinId in volatile FS, set it to the authContext
clear_auth(PinId) clear authcontext but not the volatile FS, so set-auth still works until a de-auth
When a pin is created it can also have a policy allowing it to be "overriden" by other PINs
For the software backend, policies are enforced by runtime checks. Keys with a policy are not specifically encrypted. The SE050 backend will provide that type of security.
Todo
What do Policies look like, for both keys and PINs
Policies would be handled by adding an
AuthContextto theClientContextcontaining the currentPinIdAPI
authenticate(PinId,value)-> chkec if value is correct, then store in the authcontext thePinIdand store required data in the volatile FSde_auth(PinId)-> remove data from volatile FS for the PinId and also from the AuthContext (if same)set_auth(PinId)if data for PinId in volatile FS, set it to the authContextclear_auth(PinId)clear authcontext but not the volatile FS, so set-auth still works until a de-authFor the software backend, policies are enforced by runtime checks. Keys with a policy are not specifically encrypted. The SE050 backend will provide that type of security.
Todo
What do Policies look like, for both keys and PINs