Make AuthenticatorAttestationResponseJSON.publicKeyAlgorithm optional

[zacknewman]

The motivation behind both AuthenticatorAttestationResponseJSON.publicKey and AuthenticatorAttestationResponseJSON.publicKeyAlgorithm is the same: easy access to credential data. For good reason though, AuthenticatorAttestationResponseJSON.publicKey is not required since technically such data exists in the required AuthenticatorAttestationResponseJSON.attestationObject. I believe the same should be true for AuthenticatorAttestationResponseJSON.publicKeyAlgorithm since it doesn't really serve purpose without AuthenticatorAttestationResponseJSON.publicKey also existing.

[zacknewman]

As stated in the now closed PR, I think a better approach would be to define a dictionary that requires authenticatorData, publicKey, and publicKeyAlgorithm; and an instance of this dictionary would be optional in AuthenticatorAttestationResponseJSON. It seems that it should be an all-or-nothing affair; since as soon as publicKey does not exist, an RP has no choice but to parse the COSE key which defeats the purpose of those fields.

While it would be ideal if one could model the actual requirements in pure IDL, I don't think that is possible here; and frankly much of the spec puts additional requirements on top of the IDL already. In fact in Easily accessing credential data, remarks are made on why one cannot actually require this information: user agents may not understand the public key algorithm. It does require that Ed25519, P-256, and RSASSA-PKCS1-v1_5 with SHA-256 algorithms be supported though. I think that can be improved so that in addition to requiring user agents to support those three algorithms, a user agent MUST provide publicKey when it does understand the public key algorithm. This is the closest way I think one can achieve the desired goal: providing the much more compatible SubjectPublicKeyInfo when possible (i.e., publicKey is populated iff the user agent understands the algorithm).

Of course a problem with this is an RP has two choices: implement a COSE parser as a fallback mechanism when the user agent is not able to provide publicKey or fail anytime publicKey does not exist. The former does not benefit at all from the intended purpose of these fields since the RP is implementing a COSE parser regardless. The latter suffers from the problem that certain user agents will work for users and some won't which has its own problems.