Re: PROPOSAL: Close ISSUE-17 - Define the scope and API for custom key attributes

Ok, that's the taxonomy I was looking for.  

That said, I'm not sure that I would call all of the current parameters "functional".  To me, that word implies that the parameters would tell the API whether a key can be used for a given operation.  So, "functional" would encompass things like "algorithm" and "size", but not things like "keyUsage" or "exportable", which are about whether a key *MAY* be used, not whether it *CAN*.  It's in that policy space where I thought I was hearing some desire for extensibility.

Obviously, only some of these would be interpreted and used by the API, and these would have to be standardized.  But it doesn't seem like there's any harm in allowing the application to set other attributes that the API would just keep from being changed.

In a related vein, the "algorithm" field seems over-specific from a functional perspective.  You can use the same RSA key pair for encryption and signing, but "algorithm" only gives you one.  If the group feels strongly that this level of policy constraint is necessary, then I guess I could go along with that.  My preference would be to look at adding some higher-level identifiers ("RSA", "AES").





On Feb 4, 2013, at 4:45 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Mon, Feb 4, 2013 at 11:50 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>> I'm not entirely sure that your argument is relevant to the issue.
> 
> I'm sorry, why do you see that?
> 
> Using Vijay's ontology of functional, advisory/supplementary, and
> scope, this sets out to only expose functional attributes via the API.
> 
> Advisory/supplementary and scope attributes are not exposed.
> 
> This is consistent with the spirit of our Lyon consensus, which was
> that we should not be inventing yet-another web storage mechanism.
> 
>> 
>> As I understand it, the benefit of custom attributes is that they would be managed by the API, in the sense that, say the API enforces the immutability of the 'exportable' attribute today.  That sort of thing would not be possible through custom key storage.
> 
> Correct.
> 
>> 
>> More generally, it seems to me that unless we define a distinction between certain classes of attributes (such as the above), then we should either have fully customizable attributes or no attributes, not the immutable partial list we have now.
>> 
>> --Richard
> 
> So you're also arguing that we should not expose algorithm or size? I
> don't understand the rationale for your argument here, in that it
> seems to present a false dichotomy of all/nothing, rather than the
> proposal, which is functional-only.
> 
>> 
>> 
>> 
>> On Jan 31, 2013, at 2:06 PM, Ryan Sleevi <sleevi@google.com> wrote:
>> 
>>> http://www.w3.org/2012/webcrypto/track/issues/17
>>> 
>>> I would like to propose that ISSUE-17 be closed. The definition of
>>> custom key attributes has been removed from the specification, on the
>>> basis that this specification is not attempting to define a new web
>>> storage mechanism. Attributes may instead be associated via the
>>> storage mechanisms associated with Keys themselves (eg: IndexedDB).
>>> 
>>> The use of custom attributes, such as the Named Key discovery API, has
>>> been addressed through separate specifications. As such, I believe we
>>> have resolved this ISSUE.
>>> 
>>

Received on Tuesday, 5 February 2013 14:34:31 UTC