- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 4 Feb 2013 13:45:11 -0800
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: public-webcrypto@w3.org
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 Monday, 4 February 2013 21:45:37 UTC