- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 22 Aug 2012 21:00:53 +0000
- To: David Dahl <ddahl@mozilla.com>
- CC: Web Cryptography Working Group <public-webcrypto@w3.org>
On Aug 22, 2012, at 1:07 PM, David Dahl wrote: > I think at first the single-origin concept for this API was short-sighted as we will not have the ability to build decentralized, non-walled-garden applications. > > On the question of whether an approved-origin for a specific key can approve further origins: This operation is perhaps better and more securely handled by the browser implementation. I can imagine an implementation prompting the user for approval when an attempt to use a key is initiated x-domain for the first time, with the browser updating the key origin access list with "remember this choice" checked, etc… As we currently have things, the (local) key id is origin-specific. So origin A asking for key XYZ means a different key from origin B asking for key XYZ. Different origins can get access to the same key if the user grants it and the browser supports it but they will not know it is the same key or refer to it by the same id. …Mark > > Cheers, > > David > > ----- Original Message ----- >> From: "Web Cryptography Working Group Issue Tracker" <sysbot+tracker@w3.org> >> To: public-webcrypto@w3.org >> Sent: Wednesday, August 22, 2012 2:43:00 PM >> Subject: crypto-ISSUE-26 (multi-origin access): Should key generation be allowed to specify multi-origin shared >> access [Web Cryptography API] >> >> crypto-ISSUE-26 (multi-origin access): Should key generation be >> allowed to specify multi-origin shared access [Web Cryptography API] >> >> http://www.w3.org/2012/webcrypto/track/issues/26 >> >> Raised by: Ryan Sleevi >> On product: Web Cryptography API >> >> The charter defines as "out of scope" as "access-control mechanisms >> beyond the enforcement of the same-origin policy" >> >> However, it was initially proposed by David Dahl, that during key >> generation, an application may be permitted to specify alternative >> origins be allowed to access the same key material. For example, it >> might include a DOMString[] of authorized origins, for which, if the >> key is generated, they're permitted to access. >> >> Additionally, there's outstanding question as to whether an origin, >> with access to a key, may be able to grant access to other origins >> proactively. >> >> >> >> >> > >
Received on Wednesday, 22 August 2012 21:01:22 UTC