Recommendation on attestation

[maxhata]

A note on attestation: We recommend that most relying parties operating in the consumer (as opposed to enterprise) space not specify the attestation conveyance parameter attestation (thus defaulting to none), or instead explicitly use the value indirect. This guarantees the most streamlined user experience (platforms are likely to obtain consent from the user for other types of attestation conveyances, which likely results in a larger fraction of unsuccessful credential creations due to users canceling the creation).

The main purpose of attestation from an RP's perspective is security. Thus, this recommendation should be addressed both from security and usability perspective. The current text lacks the security perspective of attestation. If FIDO Alliance wants to recommend something on attestation, we should provide reasons and options for RPs so that they can make their own decisions that will suite their business objectives.

N.B.

Other issues: We want browser vendors to reconsider their policy to bring up a warning pop-up when attestation is requested. There are many attestations that does not reveal users to anyone and the pop-up only deteriorates UX.

[maxhata]

As specified in WebAuthN specification, no attestation means RPs cannot get AAGUID. This will make it impossible for RPs to check the metadata of the authenticators that are requesting access to the RP. There are so many consumer facing services that want to check metadata as well as FIDO certification levels.
So I agree there are some services where attestation may not be so important and be omitted for simplicity. But there are many services that do need to use attestation. Thus, FIDO Alliance cannot say:

We recommend that most relying parties operating in the consumer (as opposed to enterprise) space not specify the attestation conveyance parameter attestation ...

If you want to say anything about go or no-go for attestation, you need to explain more details by discussing pros/cons from both security and usability perspectives, so that readers can make their own decision depending on their priorities.

[maxhata]

There are five places where the same note is pasted.
Since there are many consumer service RPs who do need attestation, I think a description like the following will be adequate.

A note on attestation: Whether or not to specify the attestation conveyance parameter attestation depends on your business priorities. If attestation is not specified, you will not get the AAGUID of the authenticator and you will not know anything about the authenticator you are about to accept for registration with your services. Knowing AAGUID enables you to find out the provenance and supported features of the authenticator as well as if the authenticator is certified by FIDO Alliance from such a source like FIDO Metadata Service [https://fidoalliance.org/metadata/]. FIDO Certification assures interoperability as well as levels of security of authenticators. This will be useful information especially for security conscious RPs and applications.
If you are not interested in such information of the authenticators at all, your choice will be not to specify the attestation conveyance parameter attestation (thus defaulting to none), or instead explicitly use the value indirect. This guarantees the most streamlined user experience (platforms are likely to obtain consent from the user for other types of attestation conveyances, which likely results in a larger fraction of unsuccessful credential creations due to users canceling the creation).

Since the same text is repeated 5 times, we may consider adding it to the end of the whole document in the foot note section.

[maxhata]

Created a PR, #23