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 
acceptable. 

I do not think that is the case given how the spec is currently 
written https://github.com/w3c/webauthn/commit/2b72ddf, 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 
the 
[definition](https://www.w3.org/TR/WebCryptoAPI/#algorithm-dictionary)
 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 
algorithm](https://www.w3.org/TR/WebCryptoAPI/#algorithm-normalization)
 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 
19](https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview).

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 
https://github.com/w3c/webauthn/issues/113#issuecomment-241562506 
using your GitHub account

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