AlgorithmIdentifier in encrypt/decrypt/sign/verify operations

This may be related to ISSUE-12 and apologies again if this has been
discussed before - it is coming up now frequently in implementation
discussions.

In the encrypt/decrypt/sign/verify operations, two AlgorithmIdentifier
objects are provided as input, one as an explicit parameter and one which
is associated with the Key object (and appears as the Key.algorithm
attribute). Presumably it is an error if the "name" member of the
dictionary does not match (after normalization), though I am not sure if
this is clearly specified.

In some cases, it is specified that the params member will have different
types in these two places (I'm assuming that the Key.algorithm attribute
takes the value that was provided to generateKey). For example for AES-CTR,
the params in Key.algorithm contains the key length and params in
encrypt/decrypt contains the IV.

But for other cases things are very unclear. For example, for HMAC, the
same AlgorithmParameters type is used, containing the hash algorithm. In
this case it seems completely redundant to provide the same object twice to
the sign/verify call (once in the method parameters and again in the
Key.algorithm attribute).

Am I missing something ? Does anyone else find this confusing ?

I think the confusion could be resolved by
(i) replacing the AlgorithmIdentifier argument to
sign/verify/encrypt/decrypt with AlgorithmParameters.
(ii) for HMAC, the params provided to sign/verify must be null, as the hash
algorithm should have been provided when the Key was
created/imported/unwrapped

As a side note, I believe that to generate a HMAC key we need to specify
the key length. At least according to FIPS 198-1 the key, K, can be of any
length. So, either we require in WebCrypto that it is a particular length
(say, the same size as the hash function), or we need a length parameter to
generateKey for HMAC.

...Mark