Re: [webauthn] clarify content of algorithm member of ScopedCredentialParameters

> The words "desired" and "best effort" led me to believe that 
`cryptoParameters` was just a guide, and that if no match in 
`cryptoParameters` was found then any alternative credential would be 

I do not think that is the case given how the spec is currently 
written, specifically 
in section {#makeCredential}

>I would suggest clarifying that if no match is found in 
`cryptoParameters` an error is returned.

yes, it seems that one could complete step 5 in {#makeCredential} 
having a zero-length `normalizedParameters` sequence. E.g., if the 
caller specified incorrect, mangled, or malformed 
`cryptoParameters.algorithm`.   Presently, it appears the overall 
{#makeCredential} process will pass a zero-length 
`normalizedParameters` sequence to all the authnrs on the platform (in
 step 8), and it is tacitly up to the authnrs (in step 9) to either 
time out or return an error status.  This could be overall made 
explicit for the zero-length `normalizedParameters` sequence case, 
though seems to me to be a medium- or low-priority. 

>Returning to your question about how much detail an RP App should 
provide in specifying a credential, isn't this already addressed by 
 of `AlgorithmIdentifier` which may be either a string or an object? 
The object can contain all the details you want and if it's a string 
like "RSASSA-PKCS1-v1_5", then the [normalizing 
 will fill in the details?

yes, that is understood, though it is tough (at least it was for me) 
to parse out of the WebCrypto spec and we may wish to include some 
sort of example or guidance in the WebAuthn spec.  In any case, I 
believe the "algorithm member" language cited at the beginning of the 
issue merits polishing. 

>PS - Hopefully it's obvious, but we may want to specify that the 
`algorithm` must be one that supports the `sign` and `verify` methods,
 as described in [WebCrypto Section 

Agreed, I had noticed that also. Additionally they need to support key
 `generateKey` (in terms of public-private key pair gen) it would 
seem.  fwiw, there appears to be only three algs supporting  all 
three: RSASSA-PKCS1-v1_5, RSA-PSS, and ECDSA.

GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at 
using your GitHub account

Received on Monday, 22 August 2016 21:51:13 UTC