- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Aug 2021 17:05:58 +0000
- To: public-webauthn@w3.org
@timcappalli @agl Ah, I see, thanks for explaining. So what I missed is that `dpk` is not dependent on `synced cred` alone, but on `synced cred + context` - and that `context` may fluctuate in strength over time, so `dpk` can be a more reliable alternative to `synced cred + context`. @equalsJeffH I wasn't actually thinking that a `navigator.credentials.create()` operation would be necessary for generating `AttObjForDevicePublicKey` - I reckon the authenticator could just as well construct that object during a `navigator.credentials.get()` operation. And the AAGUID is already included in the [attested credential data](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#attested-credential-data), so that would also be signed over in every attestation statement format. But on that note, I suppose one complication with my suggestion is that `AttObjForDevicePublicKey.attObj.authData` would probably just be a copy of the top-level authenticator data for the "dpk registration" ceremony? Which was likely a `get()` - meaning you'd have a `get()` authenticator data with an `AT=1` flag and including attested credential data, which might end up breaking implementations more than the polymorphic verification procedure would. Unless the `AttObjForDevicePublicKey` gets its own, separate `authData` so that the top-level authenticator data can remain unchanged. But yeah, this idea might end up being a net increase in complexity. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1658#issuecomment-896158311 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 August 2021 17:06:00 UTC