The default value of attestation member in PublicKeyCredentialRequestOptions should be null or must not have default value

[Kieun]

Proposed Change

In section 5.5, PublicKeyCredentialRequestOptions dictionary is defined.
Although asking attestation in the assertions is optional, the default value of attestation member is none attestation conveyance preference.
It means that if the relying party does not set any attestation conveyance preference (do not ask attestation in assertion), the browser (webauthn client) will set the value of attestation member as default value none, which will eventually might return attestationObject with none attestation statement format.

I'm thinking that attestation in assertion is optional and if there is no explicit request, the attestation conveyance preference must be interpreted as I don't need any attestation for assertion which is not identical to the the none attestation.

So, the value of attestation member should not be defaulting to none, and the absence should be treated as I don't need any attestation for assertion and give me conventional assertion for credential get operation.

[Kieun]

While prototyping this feature, I found that there are some of procedures defined in the spec (step 15).

The attestationFormat is not none then create an attestation object for the new credential using the procedure specified in § 6.5.5 Generating an Attestation Object, the attestation statement format attestationFormat, and the values authenticatorData and hash, as well as taking into account the value of enterpriseAttestationPossible. For more details on attestation, see § 6.5 Attestation.

If the attestationFormats of the inputs from the webauthn client, which is based on the relying party input (attestation, attestationFormats), the authenticator would fallback to the none which is not the none attestation format, but assertion without attestation.

So, the authenticator and the webauthn client might not return attestationObject in the assertion response.
But, as a RP, when implementing the webauthn server API, we refer the IDL. In addition, attestation defaulting to none in assertion would make some confusions, because the attestation in creation would return none attestation statement in the response in such cases, while the attestation in authentication does not return any attestation statement for the same case.

[nicksteele]

We discussed this on the call yesterday and there was broad support for changing this, although it may also require some changes to the CTAP draft in order to account for it and @ve7jtb should be informed/included on any PRs. I'm happy to help you draft a PR for this @Kieun or happy to review one.

[ve7jtb]

In our authenticator prototyping we are interpreting none at the ctap2.2 level the same as not requesting an attestation, or the same as CTAP2.1.
For makecredential the attestation would be fmt: "none".

If we need to return fmt: "none" for getAssertion we should sort that out quickly.

The server has no idea what generation of authenticator or Browser is being used so will always need to deal with the case where there is no attestation returned even if the conveyance preference is none.

[Kieun]

@nicksteele I'm happy to create a draft PR and well noted.
@ve7jtb As a RP, it is better not to return any attestation (attestationObject) if the RP does not explicitly request (does not set any attestation value in the assertion options).
If we return attestationObject (with none attestation statement), some of current RP implementations would be broken since we've already introduced sort of helper methods like toJSON() which might be directly used to submit the response to RP server API. So, if the RP does have strict validation logic for the inputs, it would return bad request or similar errors if the RP does not understand attestationObject in assertion response.

So, for RPs, there are following cases for the assertion options.

1. Does not set any value for attestation: meaning is that I'm not interested in attestation and please do not return attestationObject.
2. Set attestation as none: meaning is that I don't have any interests to verify the attestation, but if the authenticator could return self attestation (self-signed), it would be better than nothing.
3. Set attestation as indirect, direct, or enterprise: meaning is that at least RP would like to verify attestation, give me attestation if supported

For the first case, the attestationObject must not be included in the response. For the second and third cases, the attestationObject might be included if the client and authenticator supports attestation in assertions features.

I'm thinking that CTAP needs to have a way to support such cases.

[emlun]

This issue is made obsolete by the now merged PR #1997.