Re: DOMString for import/export (was Re: ACTION-92 | JOSE Use Case)

Richard,

Yes, that's the obvious answer - but only if we first address the
other aspects I raised.

That is, to be clear, having CryptoOperationData take a DOMString
seems very much incorrect. The question is still on handling JWK and
JWE, and I'm not convinced that DOMString is at all the right answer,
'period'.

On Mon, Jul 8, 2013 at 11:10 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>
> On Jul 8, 2013, at 1:44 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Mon, Jul 8, 2013 at 6:56 AM, Arun Ranganathan <arun@mozilla.com> wrote:
>> <snip>
>>> 2. I think the WebCrypto API's CryptoOperationData should include the possibility of JWK as JSON.  Maybe:
>>>
>>> typedef (ArrayBuffer or ArrayBufferView or DOMString) CryptoOperationData;
>>>
>>> But we should restrict it to be used only for import/export.
>> <snip>
>>
>> This has been something that's been discussed in the past, under ACTION-22.
>>
>> My fear is that it opens up a slippery slope. Presumably wrap/unwrap
>> would also desire to be able to use JWE serializations (should it
>> permit both compact and JSON? How should it be distinguished?
>> Additional types?)
>>
>> Another thought would be to specify parallel WebIDL interfaces for
>> JWE/JWK, then allow the caller to either call JSON.parse (optionally
>> with a custom reviver) or to handle formatting the JWE into the JSON
>> form (eg: not accepting the compact serialization at all).
>>
>> Importing with JWK would *only* take these interfaces then. That is,
>> solving the problem a different way, by not allowing
>> ArrayBuffer/ArrayBufferView (which then requires conversion into code
>> units, into a string, into something that can be JSON.parsed).
>
>
> I can see the point that CryptoOperationData is not a good place to add DOMString as an option.  CryptoOperationData is used to represent things that really are unformatted octet strings.
>
> On the other hand, the data that's passed into importKey/exportKey/etc is explicitly formatted.  And a lot of those formats have a natural representation as a DOMString.  The need to make an ABV has been a point of confusion for developers I've worked with.  ("Yes, just take the string and encode it as UTF-16.")  JWK for now, but I could imagine also PEM if we ever wanted to support that (might be nice for interop).  So how about if we split this off from CryptoOperationData?
>
> typedef (ArrayBuffer or ArrayBufferView or DOMString) KeyOperationData;
> Promise<any> importKey(KeyFormat format,
>                        KeyOperationData keyData,
>                        ... )
>
> That seems like it would allow string-based key formats to be in a more natural form, while still scoping things to just formatted keys.
>
> --Richard
>
>
>
>

Received on Monday, 8 July 2013 18:17:42 UTC