Differentiate when devicePubKey unsupported vs. failed? about webauthn

[emlun]

...and as I wrote this out I realized I'm going to immediately argue against myself (hey, that's what discussions are for!):

Essentially, a false output would indicate that the extension might succeed on that device if the RP retries the request at a later time, while an absent output would indicate the extension is unlikely to succeed if retried.

On further thought this doesn't quite hold up: an absent output could also just mean the client is not recent enough, while the authenticator is perfectly capable of the required operations. So the false proposed above might actually not add any information?

So perhaps the meaning of false should be the other way around, at least on the client output level - if the client understands the extension, and knows that the authenticator will never support it, then return some variant of "~false" to indicate the RP can stop retrying on this machine. If that is in combination with an authenticator output of false, then it means the extension is supported but failed; if the client output is "~false" and the authenticator output is absent, that means the authenticator will never support it.

As noted above, I suppose empty object ({}) would be the natural way to express a "~false" client output without complicating the WebIDL types. But then: this adds a bit of complexity in processing the output values. Is the information gained worth that added complexity?

[agl]

Picking at the language in the spec:

Similarly, any extension that requires authenticator processing MUST return an authenticator extension output to let the Relying Party know that the extension was honored by the authenticator.

If the authenticator refused / failed to create a DPK then the extension wasn't honored by the authenticator.

If an extension does not otherwise require any result values, it SHOULD be defined as returning a JSON Boolean client extension output result, set to true to signify that the extension was understood and processed.

DPK does require result values. (And in the case in question, the extension was not processed.)

Likewise, any authenticator extension that does not otherwise require any result values MUST return a value and SHOULD return a CBOR Boolean authenticator extension output result, set to true to signify that the extension was understood and processed.

DPK does require result values. (And in the case in question, the extension was not processed.)

So I don't think any of those apply here?

In practice, I don't believe that the authenticator failing to create a DPK is a useful signal for sites. It "shouldn't" happen. Of course, weird corruption does happen on a tiny handful of devices that can cause all sorts of weirdness, but that argues too much: if any sort of weird behaviour is in scope then we would have no end of error conditions to explicitly handle.

[emlun]

Agreed, I don't think the difference (if any) is actually useful to the RP. An RP that wants to use devicePubKey should always request the extension anyway. The case where a supporting authenticator randomly fails, but would succeed if the request is immediately retried, should be rare enough that it's not worth these complications. Thanks for your thoughts!