- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Aug 2021 09:48:06 +0000
- To: public-webauthn@w3.org
In reply to @emlun's [technical comment above](https://github.com/w3c/webauthn/issues/1658#issuecomment-895473466) (thanks for your thoughts!)... > So if I understand this correctly, a `packed` format `AttObjForDevicePublicKey` would be constructed like this? yes, I think so (without having grovelled thru specs). > I feel like the custom signing procedure might be a bit too confusing, being _almost_ the same as usual but not quite. It looks like this is going to require custom verification logic either way, so maybe we can move the difference around a bit? For example, here's one idea: > > Instead of modifying the signing procedure arguments, run the signing procedure as usual and store the resulting attestation object and client data. In subsequent re-runs, send all of it back to the RP. ... It _is_ different and for very specific reasons. The `AttObjForDevicePublicKey` (aka "DPK attestation [object]", "DPK" means "device public key") needs to _attest the DPK_, i.e., convey the result of the authnr's attestation private key signing over the DPK. Additionally, this DPK attestation needs to attest to at least the authnr type it is emitted by, hence signing over the AAGUID. Note that due to credential syncing (issue #1637), for a _given existing cred_ that has been synced to a different-to-the-RP device, _there will not be a registration (aka attestation) response_ from that device. I.e., _on the first **authn operation**_ for that device-cum-authnr, it needs to mint the DPK and attest to it (i.e., sign over the DPK using the authnr's attestation private key). This `attStmt` value will be the same for all subsequent authn operations with this device-cum-authnr-cum-synced-cred and can be cached by the authnr and returned as-is. The re-formulation above does not accomplish this, because it seems it is anticipating that there was a registration operation involving the new device for that cred, given that it is suggesting that there is an "... attestation object for the ceremony when dpk was created". There might have been, in the case where the user is registering this authnr for the first time with a given RP account, and/or there is no cred syncing (but not always, if there is cred syncing, as noted above). Note that this device public key feature is arguably not terribly useful in a world where there is no cred syncing. See also https://github.com/w3c/webauthn/issues/1658#issuecomment-895619435 (below) for a use case example of how an RP could weave the DPK signal into their risk analysis. -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1658#issuecomment-895889250 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 09:48:08 UTC