3 ms·
Shouldn't webauthn can do this already? why a separate proposal to do this again?
by mmis1000 1y ago
Shouldn't webauthn can do this already? why a separate proposal to do this again?
- agl 1y agoWebAuthn protects the sign in, but malware can still steal the resulting cookies. DBSC protects the sign in _session_. (It should stand for Don’t Bother Stealing Cookies.)
- mmis1000 1y agoIf you read the proposal carefully. this api is used to refresh/revalidate extremely short lived cookie. not replace cookie itself. Which you can already do with webauthn
- nicce 1y agoMaybe there is an assumption that this is easier to push through for masses because the UX is better. (no phone, no physical key required)
- ximm 1y agoWebauthn always requires a user presence check though.
- mmis1000 1y agoSeems the whole proposal exists solely because they are unwilling to add a "silence" option to webauthn. I am confused about the decision though. https://github.com/w3c/webauthn/issues/199#issuecomment-2669744016 https://github.com/w3c/webauthn/issues/199#issuecomment-2669...
- fc417fc802 1y agoWebauthn is significantly more complicated and conceptually structured around the use of authenticators. DBSC is a rather simple challenge-response scheme that can be bolted on to things that already exist in order to mitigate bearer token exfiltration. Even though they both use public keys the two things solve (slightly) different problems. Importantly, the presence of attestation in webauthn could potentially compromise privacy or user choice in certain cases. DBSC has zero support for that. You could certainly use a webauthn credential to establish a DBSC session though.