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

I don't think 1 is really a value add over the WebIDL, because we
still have to define "What to do with the DOMString".

Either the DOMString is a compact serialization (which only exists for
JWE, AIUI, not JWK), or the DOMString is something that has to be run
through JSON.parse.

If it has to be run through JSON.parse, then there's some expected
form on the output. Simply saying "It should be JWK/JWE" isn't really
sufficient, because those specs don't describe a parsing alg - let
alone handling type incompatibilities (eg: what to do if JSON.parse
returns an Array type, rather than a String).

So we still end up duplicating the JW* bits into a canonical WebIDL,
so that we can leverage defined type conversions and behaviours for
parsing.

That's why I see the DOMString as a non-starter: It creates ambiguity
in the case of the compact serialization, and it doesn't save any
hassle in the spec of needing to define parsing/handling rules. The
WebIDL interface at least lets us do well-defined rules for handling
the objects.

On Mon, Jul 8, 2013 at 11:43 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> So I'm glad I provoked this discussion with a strawperson for CryptoOperationData :-)
>
> On Jul 8, 2013, at 2:27 PM, Richard Barnes wrote:
>
>> Ah.  I had missed the second part of your message.  Not being a WebIDL wizard, the idea of having IDL for JW* seems not entirely unreasonable, but I would be wary of maintenance and incompatibilities creeping in.
>>
>> In any case, it seems like there are two routes here, both of which require splitting off KeyOperationData:
>>
>> 1. Handle JOSE objects as text (in serialized form) and add DOMString to KeyOperationData
>
>
> This option is a non-starter with Ryan, correct?  Given that Ryan thinks that DOMString is the wrong answer, period?
>
>
>> 2. Handle JOSE objects as real objects and add those types to KeyOperationData
>>
>
> This option works for me, but I'm not sure what to do with the compact-form variant other than disallow it.
>
> -- A*
>

Received on Monday, 8 July 2013 18:49:32 UTC