You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey folks, in the current draft of DBSC, there seems to be explicit callouts that this credential should be created and bound to a TPM, but the credential could also be capable of being made and managed by a credential manager or software-defined authenticator. I'd like to explicitly call that out in the proposed work, because I think it will not only help in scenarios such as when a TPM is not present but allow users to manage session credentials, which could be an extremely helpful feature.
One could imagine a use-case of this for users would be that they no longer wish to associate with a certain device. If there are existing sessions backed by a DBSC token on that device, they could inform the credential manager to remove the DBSC tokens on the device, potentially ending the sessions that were using the tokens stored in that manager. This way, if the device has a new user, they would be unable to re-authenticate (assuming the credential manager is locked) and more importantly, they wouldn't have access to pre-existing user sessions backed by DBSC.
The text was updated successfully, but these errors were encountered:
Hey folks, in the current draft of DBSC, there seems to be explicit callouts that this credential should be created and bound to a TPM, but the credential could also be capable of being made and managed by a credential manager or software-defined authenticator. I'd like to explicitly call that out in the proposed work, because I think it will not only help in scenarios such as when a TPM is not present but allow users to manage session credentials, which could be an extremely helpful feature.
One could imagine a use-case of this for users would be that they no longer wish to associate with a certain device. If there are existing sessions backed by a DBSC token on that device, they could inform the credential manager to remove the DBSC tokens on the device, potentially ending the sessions that were using the tokens stored in that manager. This way, if the device has a new user, they would be unable to re-authenticate (assuming the credential manager is locked) and more importantly, they wouldn't have access to pre-existing user sessions backed by DBSC.
The text was updated successfully, but these errors were encountered: