Re: ISSUE-26 is expecting proposal or will be postponed

Nick,

I'm not sure why the resurrection of this thread/issue.

The description for the issue reads: "Should key generation be allowed
to specify multi-origin shared access"

If you read through the related messages, you would see this
explicitly refers to a proposal similar to the more recent threads by
Mountie regarding having key generation explicitly list a set of
origins that should have access to a key.

We agreed as a WG that this is not desirable nor consistent with the
rest of the web platform. You are correct in noting that structured
clone permits inter-origin sharing. It does not permit whitelisting a
specific list of domains during keygen, however.

IF the WG had decided for such a solution (which we did not - as the
issue is closed), we would be need to be having discussions about
adding security checks to the structured clone algorithm that
performed origin checks. However, since we agreed to close the issue,
such points are moot.


On Wed, May 8, 2013 at 8:53 AM, Nick Van den Bleeken
<Nick.Van.den.Bleeken@inventivegroup.com> wrote:
> I thought that we already agreed that keys are structured clone-able across an origin boundary using postMessage.
>
> Nick
>
> On 27 Feb 2013, at 21:11, Richard Barnes <rbarnes@bbn.com> wrote:
>
>> I support closing this issue.  As I read it, the API already allows multi-origin usage of keys, because keys are clonable.
>>
>> If that's not the case, then the document should specify that if keys are cloned across an origin boundary (e.g., through postMessage), then they will not work.  But that seems like unnecessary complication.
>>
>>
>>
>> On Feb 25, 2013, at 11:38 AM, GALINDO Virginie <Virginie.GALINDO@gemalto.com> wrote:
>>
>>> Dear all,
>>>
>>> As mentioned in a previous mail, and in the spirit to progress on the Web Crypto API (Low Level), I would like to remind you that the multiple origin feature, as described in ISSUE-26 [1] is still awaiting for some proposals/contribution in the coming week. If there is no contribution, this feature will be put on hold and the ISSUE will be postponed, which means that our final deliverable might not embed any solution for it.
>>>
>>> Regards,
>>> Virginie
>>> Chair of the Web Crypto WG
>>> [1] https://www.w3.org/2012/webcrypto/track/issues/26
>>>
>>
>>
>>
>>
>
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>

Received on Wednesday, 8 May 2013 18:35:59 UTC