RE: NSD API security

At AT&T side, we support Rich and Dom's proposal of supporting both CORS as the primary mode and whitelisting for legacy devices.

While CORS approach will be good for implementers to start with from now on, current legacy devices on market cannot be ignored. If we don't support legacy devices, I am not sure if market eventually will adopt NSD with CORS only approach, or the market will be fragmented.

Thus CORS + whitelisting approach is more reasonable to keep the market support.

Thanks
Bin

-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Friday, September 20, 2013 3:44 AM
To: Dominique Hazael-Massieux
Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org; public-web-and-tv
Subject: Re: NSD API security

On Fri, Sep 20, 2013 at 6:18 PM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> Le vendredi 20 septembre 2013 à 17:28 +1000, Rich Tibbett a écrit :
>> So there are a number of directions we could take this in:
>>
>> 1. Focus the specification around a CORS-only solution. CORS is an
>> accepted mechanism to allow cross-origin communication on the web and
>> could work well in the local network environment also. The problem
>> with adopting a CORS-only approach is we have zero devices currently
>> ready to step in to this brave new world with us. A specification that
>> allows you to connect with precisely zero network services will not be
>> useful.
>
> I think that no matter what, the spec should support a CORS-based
> approach.

A CORS approach only? As I said, there are no services I'm aware of
that would work with that today so we would also have to see if device
vendors are interested in releasing CORS-based devices and services. I
know we have a few device vendors on this list so it would be good to
hear their opinions at this point.

>
>> 2. Support whitelisting of specific local network services in the user
>> agent, at the user's request to enable communication with those
>> services. Even if we went with a CORS-only approach (see (1.) above),
>> this could be a practical fallback to support existing/legacy network
>> services. This would provide non-CORS-enabled services with the same
>> privileges as CORS-enabled services from the user agent without the
>> service itself needing to support CORS implicitly (as also proposed in
>> the current NSD API specification).
>
> I support the idea (at least in theory — it would remain to be seen
> whether any user agent would feel confident to support such a
> whitelist); but given that this is an exception mechanism, I'm not even
> sure it needs to be specified —  since the user agent is ultimately
> responsible for managing the same origin policy, user-specified
> exceptions to that policy (which such a whitelist would be) seem beyond
> what we need to define for interoperability. Or did you have in mind
> some specific aspects that would need to be spec-d here?

It may warrant a note in the spec to say that a user agent MAY
whitelist non-CORS-enabled network services and that if it does so it
MUST pass through XHR/WebSocket messages to the network service
endpoints as if they were CORS enabled.

Other than that, I don't anticipate any other issues with interoperability.

>
> Dom
>

Received on Thursday, 26 September 2013 22:29:10 UTC