Variable reference issue in DPK processing rules

[sbweeden]

Proposed Change

See: https://github.com/w3c/webauthn/blob/main/index.bs#L7107

This is related to DPK processing rules for the create and get operations.

It says:

Let attObjForDevicePublicKey be the value of the [devicePubKey](https://w3c.github.io/webauthn/#dom-authenticationextensionsclientoutputs-devicepubkey) member of clientExtensionResults.

I am fairly sure that this is not correct, insofar as attObjForDevicePublicKey is not a member of clientExtensionResults - instead it is authenticator extension data (i.e. part of the extensions of the authData variable).

The same issue is relevant to section 10.2.2.3.2 (Authentication processing rules) step 1.

I think these should say something like:

Let attObjForDevicePublicKey be the value of the [devicePubKey](https://w3c.github.io/webauthn/#dom-authenticationextensionsclientoutputs-devicepubkey) member of the extensions in authData.

[sbweeden]

@agl - FYI - can you please confirm this issue is valid?

[agl]

Let attObjForDevicePublicKey be the value of the devicePubKey member of clientExtensionResults.

Well, the DPK output is in clientExtensionResults too, although it's in the authenticatorOutput member now that the signature has been moved out of it. So I should have updated that. But one could take it from the authenticator data too. That version is signed over by the primary credential, although whether that matters to RPs who care about DPK, I'm not sure.

I'll craft a PR to mention the move to authenticatorOutput, but do you, as an RP, want to read it from the authData?

[sbweeden]

As an RP, I would prefer to read it from the authenticator-attested field rather than the unsigned client extensions output. If it's an exact copy in the authenticatorOutput unsigned client extension, then shouldn't part of the verification be making sure these are the same value?

[sbweeden]

For that matter - is there any particular reason a redundant copy of the authenticator extension information also appears in the client extension output?

[agl]

If it's an exact copy in the authenticatorOutput unsigned client extension, then shouldn't part of the verification be making sure these are the same value?
is there any particular reason a redundant copy of the authenticator extension information also appears in the client extension output?

As a pattern, authenticator outputs are duplicated into the client outputs. Mike Jones has always insisted on it.

I don't believe that we have instructions for verifying the concordance of extension outputs elsewhere, thus we don't here either. I don't mind either way.

[sbweeden]

Let's discuss in next regular WebAuthn call. Personally I can't understand why an RP would ever use the client extension output as authoritative for this data given its not signed, whereas the copy within the authData is signed.

[emlun]

Related discussion: #1663 (comment)

[sbweeden]

POV from @selfissued requested.

[Kieun]

Relate issue: #1258

[nadalin]

@selfissued Please review