2 ms·
If you check the spec [0] you will see that unlike most new web tech this one doesn't provide any DRM-adjacent functionality. There's absolutely no technical me
by fc417fc802 2y ago
If you check the spec [0] you will see that unlike most new web tech this one doesn't provide any DRM-adjacent functionality. There's absolutely no technical measure in the spec that could be leveraged to force an implementation to use a TPM. If user choice is disrespected that is squarely on the implementation (ie the browser) and has nothing to do with either the protocol or the server.
Honestly this fairly simple scheme looks a lot like what I wish webauthn could have been.
[0] https://w3c.github.io/webappsec-dbsc/ https://w3c.github.io/webappsec-dbsc/
- no_time 2y agohah you are right. They address this concern specifically in 2.1: >DBSC is not designed to give hosts any sort of guarantee about the specific device a session is registered to, or the state of this device. Nevermind then. Also makes it more or less useless as a security measure but atleast not outright harmful like the famous WEI proposal.
- fc417fc802 2y ago> makes it more or less useless as a security measure Define "security". This is incredibly useful for mitigating bearer token exfiltration which is the stated purpose. It's also the same way ssh keypairs work and those are clearly much more secure than passwords. It's only "insecure" from the perspective of a service host who wants to exert control over end users. Even webauthn leaves attestation as an optional thing. Even in the case that the service operator requires it, so long as they don't engage in vendor whitelisting you can create a snakeoil authority on the fly. The main advantage this has over webauthn is that it is so much simpler.