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

I'm not entirely sure that your argument is relevant to the issue.

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.

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.


On Jan 31, 2013, at 2:06 PM, Ryan Sleevi <> wrote:

> 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 Monday, 4 February 2013 19:51:21 UTC