Re: [discovery] Adding CORS to NSD API - proposal and issues

Le 3/10/13 13:22 , Rich Tibbett a écrit :
> Hi folks,
>
> I'm in the process of adding tentative CORS support to the NSD API
> spec as we have been discussing in [1]. This email is a technical
> summary of the current thinking around this and a discussion of the
> current issues we are facing with this approach.
>
> ---
>
> Current Proposal:
>
> To provide access only to CORS-enabled networked services it would be
> good to have a way to detect CORS support during network service
> discovery processes themselves; before those networked services are
> offered up to users and before they are shared with web pages. A
> networked service that does not provide cross-site request
> communication would be relatively useless and is a situation we are
> trying to avoid.
>
> The NSD API spec currently details the network service discovery
> processes for three mechanisms: SSDP (UPnP), mDNS+DNS-SD and DIAL and
> the method for each of these mechanisms to indicate a networked
> service supports CORS could be as follows:
>
> - For SSDP, a <service> node contained within a UPnP Device Descriptor
> File must provide a <corsEnabled> sub-element whose value must be set
> to '1', 'yes', 'y' or 'true'. Otherwise, the <service> is said not to
> support CORS and is therefore not accessible to web pages (except if
> the service type is whitelisted by the user or user agent).
JCD: Does this proposal amount to mandating an NSD-specific extension of 
SSDP ?
It sounds like it and if so, no go.
NSD must fully support legacy SSDP devices/services.

>
> - For DNS-SD, a developer must add a 'corsEnabled' key to their DNS-SD
> SRV record's corresponding DNS TXT record. This key would be
> case-insensitive in line with the DNS-SD spec itself [2]. Otherwise,
> the DNS-SD service is said not to support CORS and is therefore not
> accessible to web pages (except if the service type is whitelisted by
> the user or user agent).
JCD: same question for Bonjour...


>
> - For DIAL, the discovery message response must contain a
> 'Access-Control-Allow-Origin' HTTP header and the value of this header
> must be '*'. Otherwise, the DIAL service is said not to support CORS
> and is therefore not accessible to web pages (except if the DIAL
> service type is whitelisted by the user or user agent).
>
> Each of the above mechanisms is currently a tentative proposal and
> each warrants further discussion both on this list and in their
> respective standardization groups.
>
> We should also offer an override mechanism for users and/or user
> agents to create a network services whitelist - enabling access to
> non-CORS-enabled networked services also. Implementation of such a
> network services whitelist remains at an implementer's discretion.
>
> In case any of the conditions above occur, a network service could be
> accessed from web pages via the the Network Service Discovery API
> (subject to all the conditions therein). Web page themselves are not
> privy to the CORS-detection procedures outlined above since the CORS
> opt-in process is abstracted away from the API itself to the
> respective discovery processes.
>
> ---
>
> Current Proposal Issues:
>
> The main problem with this approach is that dissonance has now been
> introduced between a.) the indicating of support for CORS during the
> discovery process and b.) _actual_ support for CORS in subsequent
> service interactions. i.e. If a networked service indicates it
> supports CORS during the discovery process and then subsequently fails
> to provide 'Access-Control-Allow-Origin: *' in all subsequent HTTP
> responses or the networked service doesn't implement the ability to
> respond to CORS preflight requests correctly (among other potential
> CORS-related pitfalls) then the process of communicating with a
> networked service fails and the service is broken for all meaningful
> purposes (I can't communicate with a discovered process from a web
> page).
>
> One solution to this issue may be to require networked services to
> opt-in to cross-site requests during their discovery processes (as
> proposed above) but then for the user agent to 'simulate' CORS support
> for that networked service's URL endpoint. This is similar to the way
> the API is currently drafted, by adding service URLs to a URL
> whitelist that requires the user agent to treat service URLs as if
> they supported CORS without the service itself needing to support CORS
> directly.
JCD: I would apply this method of simulating CORS support on a device 
whitelist, with the CORS whitelisting being done by the client as part 
of the security check UI.
If the user accepts that this web app has the right to discuss with e.g. 
this UPnP ContentDirectory, then CORS support could be simulated on this 
legacy ContentDirectory service.
However, the CORS simulation would need to happen during a later 
exchange with the service, after discovery, so outside of the scope of 
NSD, no ?
Best regards
JC
>
> The new part in this process is that networked services need to opt-in
> to cross-site requests during discovery (via the mechanisms above)
> rather than the user agent providing that access for all networked
> services by default (as per the previously specced approach). That
> seems to meet the objectives of this exercise without introducing any
> potential dissonance between the service discovery process and the
> service communication process.
>
> Minor point: If we do agree to go with this idea instead then it may
> make more sense to rename 'corsEnabled' to 'xsEnabled' in the
> discovery processes above.
>
> So the process essentially becomes CORS-like (where services need to
> opt-in to cross-site sharing) but the result is 'simulated CORS'
> (where the user agent acts as if CORS is enabled for URLS belonging to
> shared networked services).
>
> -------
>
> Alternative Proposal:
>
> During the current drafting an alternative proposal came up and it may
> be worth mentioning here.
>
> Instead of introducing the dissonance discussed above we could instead
> rely on issuing tentative preflight requests [3] to networked service
> endpoint URLs once the network service discovery process has been
> completed as normal (without services needing to opt-in at the
> discovery stage). This approach has the benefit of actually ensuring
> CORS is properly supported since we are feature-detecting CORS
> directly on actual network service URLs rather than trusting a
> corsEnabled directive during discovery that assues us that CORS is
> supported on any corresponding network service URLs.
>
> ---
>
> Alternative Proposal Issues:
>
> The major problem with adopting this alternative approach is that the
> root of a networked service endpoint URL is not always configured to
> return 200 OK responses (some networked services may provide access
> only in sub-directories or non-standard root locations which can
> differ per network service type). CORS preflight requests abort if the
> HTTP response is not 200 OK, in which case this approach would fail to
> capture legitimate CORS-enabled networked services during this
> process.
>
> ---
>
> So it seems there are a few things we need to think about further here
> and all feedback is welcome on the best way for us to proceed.
>
> br/ Rich
>
> ---
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0040.html
>
> [2] http://tools.ietf.org/html/rfc6763#section-6
>
> [3] http://www.w3.org/TR/cors/#preflight-request
>


-- 
Télécom ParisTech <http://www.telecom-paristech.fr>  *Jean-Claude 
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : +33 1 45 81 77 33  37-39 rue Dareau
75014 Paris, France

Site web <http://www.telecom-paristech.fr>Twitter 
<https://twitter.com/TelecomPTech>Facebook 
<https://www.facebook.com/TelecomParisTech>Google+ 
<https://plus.google.com/111525064771175271294>Blog 
<http://jcdufourd.wp.mines-telecom.fr>