W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

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

From: Rich Tibbett <richt@opera.com>
Date: Thu, 3 Oct 2013 21:22:12 +1000
Message-ID: <CAAsrAZCWp=CVGhnLp-r+Qf+4d0QDS7h34=kPtSRZwwxkwFT8-g@mail.gmail.com>
To: Device APIs Working Group <public-device-apis@w3.org>
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).

- 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).

- 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

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

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


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
Received on Thursday, 3 October 2013 11:22:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC