- From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jan 2022 17:38:09 +0000
- To: public-webauthn@w3.org
@maxhata > https://docs.google.com/presentation/d/14WXRLDcOOf-3cdnAEBXh2Z_bA8LtLb7FbZE4vNmuPnM/edit?usp=sharing This assumes that if RP is not using dpk, then it is less secure. Which is not a correct assumption. Also, as of today, authenticators don't provide dpk and we have to acknowledge and preserve the behavior for backwords compatibility. For example, there will be multiple versions of Windows for years to come which will never give you dpk and does not support sync/backup capability. My point here is if there are authenticators that does not support sync/backup capability as of now (which most of them currently are) and are code locked, there is no dpk for them. And as an RP, you can't forget about them and assume that dpk is always provided. I think I agree with you that if someone is implementing backup/sync like multi-device passkeys, then they should provide dpk for security conscious RPs for risk analysis. But in WebAuthn, all the extensions are optional and we can't mandate an extension in WebAuthn spec. I am against changing the status quo in WebAuthn regarding extensions. Correct place to discuss this is in FIDO (TWG or SPWG). dpk, as per current definition in the PR is that it is just another key which is device bound. It does not tell whether primary credential is device bound or not. I think we require another signal for an RP who cares to determine whether credential created is device bound or not and whether backup/sync has happened or not for an RP to go ahead with deletion of passwords from the account. The original proposal in https://github.com/w3c/webauthn/issues/1637#issue-935187400 around this is `durables` flag. But I think we need either more flags or another extension because it has more states than just two to support user journeys/choices around backup. Windows current thinking is that if and when we implement multi-device backup, user will be given a choice of whether they want these credentials to be backed-up or not at registration time. User may also have ability to choose sync/backup state in the future depending on various factors like access to sync/backup fabric etc and it's properties. Which means that backup state of the credential can change over time. And RP should be able to determine what is happening from the authenticator responses. I was thinking about extension with more detailed state, but two flags can also work as proposed by @ve7jtb. I have opened an issue for this - https://github.com/w3c/webauthn/issues/1692 -- GitHub Notification of comment by akshayku Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1021442625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 25 January 2022 17:38:11 UTC