RE: [discovery-api] CORS support added to NSD API Editor's Draft

Hi,

About the source origin value of pre-flight, the empty should be used just to determine if the device support CORS. The result of pre-flight at discovery should not be used to determine if the device provide access. In other words, XHR requests with a real source origin of web page may fail with discovered services.

I do not think that device should always response with the wildcard CORS support i.e. 'Access-Control-Allow-Origin: *'. Depending on type of services, e.g. high privacy, service on device will provide access to specific web page.  After service on device is discovered via NSD, the full CORS aspects should be applied, since the CORS is the baseline of cross-origin site access in the open web platform.

In my understanding, the benefits of CORS for NSD is not only to prevent to access other arbitrary networked services on the local network, but also to make a local networked service to provide access only to specific web services on the Internet. For example, a UPnP Router provided by network operator provide access via web page of the network operator. This prevent an malicious web page making a security hole.

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com)
Section 1, Standard Technology Development Dept.
Information Technology Development Div, R&D Platform
Sony Corporation


> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: Monday, October 07, 2013 5:53 PM
> To: FABLET Youenn
> Cc: Device APIs Working Group
> Subject: Re: [discovery-api] CORS support added to NSD API Editor's Draft
> 
> Hi Youenn,
> 
> On Mon, Oct 7, 2013 at 7:34 PM, FABLET Youenn <Youenn.Fablet@crf.canon.fr>
> wrote:
> > Two questions after scheming through the CORS preflight check:
> > 1. Why setting the source origin to the public IP address of the current
> machine and not to the script origin?
> 
> It is because the timing of service discovery can occur in the background
> and therefore a CORS preflight check as defined in the spec would not have
> a specific script origin at that time.
> 
> The reason public IP address of the current machine is used is because it
> is highly unlikely that a network service will provide access to specific
> hosts in what is a highly dynamic, NAT-based home environment. Therefore,
> the choice of source origin selection is actually intentionally arbitrary.
> What we are really looking for is wildcard CORS support i.e.
> 'Access-Control-Allow-Origin: *'. That therefore doesn't really allow for
> granular CORS support in network services but is a trade-off with the
> flexibility available to implementers in service discovery mechanism timing.
> Perhaps it depends on which consideration is more important to have (flexible
> network discovery timing or granular CORS support for services).
> 
> >
> > 2. Which HTTP methods should actually be checked in advance? GET only?
> POST? More?
> > Depending on the particular service implementation of CORS, this initial
> check may not always be sufficient.
> > Web apps may anyway need to discover what is authorized by itself.
> 
> It would be the default method, GET, that is checked since this method is
> the most likely to succeed. The response would contain all the HTTP methods
> on which CORS is enabled (in the 'Access-Control-Allow-Methods' response
> header). That is the current design given the implied constraints of checking
> for CORS support without knowing all of the method(s) required during service
> interaction up-front.
> 
> Best regards,
> 
> Rich
> 
> >
> > Regards,
> >         Youenn
> >
> >> -----Original Message-----
> >> From: Rich Tibbett [mailto:richt@opera.com]
> >> Sent: lundi 7 octobre 2013 05:19
> >> To: Device APIs Working Group
> >> Subject: [discovery-api] CORS support added to NSD API Editor's Draft
> >>
> >> I have added an initial version of CORS support to the Editor's Draft
> >> of the Network Service Discovery API spec.
> >>
> >> The ED version of the spec is in the usual place:
> >>
> >> https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html

> >>
> >> A diff is available with all CORS-related updates is at:
> >>
> >> https://dvcs.w3.org/hg/dap/diff/f3ea6558ffe1/discovery-

> >> api/Overview.src.html
> >>
> >> This update is as per the 'alternative' CORS proposal previously
> >> introduced and discussed in [1] (including the resolved issues in
> >> that thread). I believe we still need to review and update the
> >> Security and Privacy Considerations Section further related to
> >> security concerns that have been raised elsewhere on the mailing list
> [2].
> >>
> >> Best regards,
> >>
> >> Rich
> >>
> >> [1] http://lists.w3.org/Archives/Public/public-device-

> >> apis/2013Oct/0014.html
> >>
> >> [2] http://lists.w3.org/Archives/Public/public-device-

> >> apis/2013Oct/0033.html
> >> (in reply to: http://lists.w3.org/Archives/Public/public-device-

> >> apis/2013Oct/0010.html)
> >
>

Received on Monday, 7 October 2013 12:41:37 UTC