- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 25 Feb 2013 17:00:06 -0800
- To: Mountie Lee <mountie.lee@mw2.or.kr>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
CORS are for resource requests, not for scriptable objects. So no, it's entirely inappropriate for CORS. Just reading the CORS spec should highlight this - the requirement to pre-flight resource requests shows that there's absolutely no way to express a request for a scriptable object via a Request. On Mon, Feb 25, 2013 at 4:55 PM, Mountie Lee <mountie.lee@mw2.or.kr> wrote: > Hi. > if Key A generated by the script loaded from origin-A, > will be the Key-A accessable from origin-B with CORS headers? > > if CORS controls are deployed to generated Key resource, > we found improvement. > > > On Thu, Feb 7, 2013 at 11:25 PM, GALINDO Virginie > <Virginie.GALINDO@gemalto.com> wrote: >> >> Hi Mountie, Ryand, and all, >> >> >> >> About the certificate management. >> >> This is a discussion I wanted to have during our last call : how to >> address the secondary features. It seems to me that if this topic if of >> importance for you, you should start considering creating a draft >> specification to address it. >> >> As I have mentioned several time, the WG welcomes contributions, even on >> secondary features. If there is a contribution, you will get some time to >> present it, and discuss it, with a low priority in the agenda compared to >> primary features, but at least, it will allow the group to understand why it >> is important and how it is feasible to manage certificates. >> >> >> >> About the multiple-origin. >> >> I would suggest that if there are some interested parties, they come >> together with a proposal to the editors, as I recommend for the ISSUE-19. >> >> >> >> Regards, >> >> Virginie >> >> >> >> >> >> >> >> From: mountie@paygate.net [mailto:mountie@paygate.net] On Behalf Of >> Mountie Lee >> Sent: samedi 2 février 2013 05:34 >> To: Ryan Sleevi >> Cc: public-webcrypto@w3.org >> Subject: Re: PROPOSAL: Close ISSUE-26 - Should key generation be allowed >> to specify multi-origin shared access >> >> >> >> there are many discuss threads for multi-origin issues. >> >> and I feel the solution was narrowed to certificate association. >> >> >> >> but the certificate related issues were postponed because it was not in >> primary features. >> >> >> >> my main concern is that >> >> closing this issue will cause final decision of dropping multi-origin >> allowness. >> >> >> >> I will still research and review the alternatives like CORS or script-src. >> >> but I feel still we need to handle multi-origin and certificate both. >> >> >> >> regards >> >> mountie. >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2013 at 10:24 AM, Ryan Sleevi <sleevi@google.com> wrote: >> >> On Thu, Jan 31, 2013 at 5:19 PM, Mountie Lee <mountie@paygate.net> wrote: >> > from the previous discussions >> > >> > I remember we have two proposals for this issue. >> >> There were not proposals. There were use cases, but no proposals on >> how to satisfy those use cases. >> >> >> > >> > one is allowing multi-origin shared acces for certificate associated >> > case. >> > second is allowing multi-origin shared access by user consent >> > >> > the reason why this issue is important is >> > >> > in the online banking usecases. >> > users generate keypair at CA website and get certificate. >> > and the certificate-private key pair should be used at other bank sites >> > for >> > signing document or verifying signature. >> > >> > as compared to TLS certificate usecases, >> > it is also common sense. >> > generating and getting certificate from CA site >> > and using it at different site >> >> And in that thread, solutions were explored on how that use case can be >> met. >> >> That said, we're talking more generally about credential enrollment, >> as you just described, which is clearly placed in our secondary use >> cases. >> >> I think that, absent any concrete proposals, and based on the >> timelines set out, this should not be seen as an ISSUE for the current >> spec. The WG has (by charter) agreed to look at this, but at a later >> point (the non-normative "roadmap" document). >> >> I'm proposing that, based on the lack of concrete proposals, and based >> on the timeline set forward, that we should consider this "not >> implemented due to time constraints". >> >> >> > >> > >> > On Fri, Feb 1, 2013 at 4:18 AM, Ryan Sleevi <sleevi@google.com> wrote: >> >> >> >> http://www.w3.org/2012/webcrypto/track/issues/26 >> >> >> >> I would like to propose that we CLOSE Issue-26. >> >> >> >> There have been no proposals put forward on how to securely address >> >> multi-origin shared access. Further, such provisioning opens up a host >> >> of security concerns that the use cases used to justify such access >> >> are not compatible with. >> >> >> >> In the current specification, multi-origin applications may make use >> >> of secure messaging exchanges, such as postMessage, to transition >> >> across security domains, without requiring the granting of a single >> >> origin full access to either plaintext or to keying material. >> >> >> >> As such, absent both concrete use cases and proposals, I propose that >> >> this issue be closed. >> >> >> > >> > >> > >> > -- >> > Mountie Lee >> > >> > PayGate >> > CTO, CISSP >> > Tel : +82 2 2140 2700 >> > E-Mail : mountie@paygate.net >> > >> >> > ======================================= >> > PayGate Inc. >> > THE STANDARD FOR ONLINE PAYMENT >> > for Korea, Japan, China, and the World >> > >> >> >> >> >> >> -- >> Mountie Lee >> >> PayGate >> >> CTO, CISSP >> Tel : +82 2 2140 2700 >> E-Mail : mountie@paygate.net >> >> ======================================= >> >> PayGate Inc. >> >> THE STANDARD FOR ONLINE PAYMENT >> >> for Korea, Japan, China, and the World >> >> > > > > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World >
Received on Tuesday, 26 February 2013 01:00:38 UTC