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



> -----Original Message-----
> From: ext Igarashi, Tatsuya [mailto:Tatsuya.Igarashi@jp.sony.com]
> Sent: Monday, October 07, 2013 8:41 AM
> To: Rich Tibbett; FABLET Youenn
> Cc: Device APIs Working Group
> Subject: 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.

Agreed that the primary purpose of the preflight request should be to determine if CORS is supported. As a bonus, if the result comes back as a wild-card, the UA knows that any web app would be allowed to talk to that service (upon user permission).

But using an empty origin might cause the UA to incorrectly interpret a server that supports CORS but allows only a specific list of origins as not supporting CORS. An alternative is to use the target service's own origin instead in the preflight request. The result would be one of the following:
1. The request fails -> the target service does not support CORS. In this case, the UA must not include this service in its list of services.
2. The request succeeds with "Access-Control-Allow-Origin: *" -> the target service supports CORS and accepts requests from any origin. In this case, the UA includes this service in its list of services. The service will be presented to the user as is.
3. The request succeeds with "Access-Control-Allow-Origin: target service's origin" -> the target service supports CORS but only accepts requests from certain origins (such as its own). In this case, the UA still records this service in its list of services, but marks it as "conditional". Upon receiving a getNetworkServices request from a web page (where this service matches a requested type), the UA issues another preflight request with the web page's origin to determine whether that web page would be allowed access, and use the result to decide whether the service can be presented to the user. The UA may also store this information for future use (until expiration). 

- Cathy.

> 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 21:56:14 UTC