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

On Thu, Oct 3, 2013 at 10:04 PM, Jean-Claude Dufourd <
jean-claude.dufourd@telecom-paristech.fr> wrote:

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

Please read the full thread and provided references in
http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0029.html

In case you have done that, would you care to explain your position? Are
you speaking on behalf of all device implementers here? (honest question).


>
>
>  - 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 ?
>

So you are suggesting no change to the specification?

Please fully read the background to this thread. I believe the proposed
changes are inevitable in light of implementer feedback.

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
>
>
>
> --
>   [image: 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
>
> [image: Site web] <http://www.telecom-paristech.fr>[image: Twitter]<https://twitter.com/TelecomPTech>[image:
> Facebook] <https://www.facebook.com/TelecomParisTech>[image: Google+]<https://plus.google.com/111525064771175271294>[image:
> Blog] <http://jcdufourd.wp.mines-telecom.fr>
>