Add acceptable trust anchors to AuthenticatorSelectionCriteria

[jyasskin]

In order to accept a created credential, Relying Parties are told in Registering a new credential to:

12. Assess the attestation trustworthiness using the outputs of the verification procedure in step 10, as follows:
    • If self-attestation was used, check if self-attestation is acceptable under Relying Party policy.
    • If ECDAA was used, verify that the identifier of the ECDAA-Issuer public key used is included in the set of acceptable trust anchors obtained in step 11.
    • Otherwise, use the X.509 certificates returned by the verification procedure to verify that the attestation public key correctly chains up to an acceptable root certificate.

However, without an addition to the AuthenticatorSelectionCriteria, the user can't get any indication from their Client about which authenticators will be attested by an acceptable trust anchor.

@gmandyam's issues #445, #446, and #447 all depend on this, since the RP can't trust any of those protection claims without a trusted attestation.

[AngeloKai]

Assigning this to @gmandyam because @gmandyam's PRs all depend on it. Add WD-06 milestone because related PRs are for WD-06.

[AngeloKai]

@gmandyam can you please help with this issue here? It does appear that the PRs depend on this.

[gmandyam]

@AngeloKai

Will take a look and create PR.

[jyasskin]

FWIW, @balfanz argued that we have two classes of users, neither of who needs this support in V1:

1. Public-facing sites like Facebook, Twitter, etc.: These sites are likely to accept any trust anchor, since it's better than a password.
2. Enterprises, maybe banks, etc.: These sites can tell their users "use exactly the authenticator I give you", and it's ok if the UX for the user presenting a different authenticator only fails after the authenticator is presented.

I find that reasonably convincing and would be ok with this whole set of selection APIs being postponed until V2.

[equalsJeffH]

WRT the orig post (OP) #461 (comment): note that preceding Step 11 of Registering a new credential says:

...obtain a list of acceptable trust anchors (attestation root certificates or ECDAA-Issuer public keys) for that attestation type and attestation statement format fmt, from a trusted source or from policy. For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to obtain such information, using the AAGUID in the attestation data contained in authData.

Which means an RP in (2) above will likely have such information on-hand.

Though, having a means for the RP to indicate to the client which authnrs are acceptable when invoking the [Create] method is advantageous from various UX perspectives. This is the crux of the OP, yes?

There currently is the Authenticator Selection extension for this, as well as PR #479 (which obviates the former extension).

[AngeloKai]

Given that the related issues are all tagged as CR, moving this issue to milestone CR.

[gmandyam]

@AngeloKai

Based on discussion in weekly conf. call on 06-14-2017, it does not seem like declaring preferred trust path in the API is the method that group participants want to use to address this problem. The preference would be to accept all trust paths, but have the RP communicate back with the user that the selected authenticator is not acceptable if the selected authenticator's trust path is not compliant with RP policy.

Recommendation: close this issue or mark it as V2.

[AngeloKai]

Close as requested.