RE: NSD API security

Hi Giuseppe,

> I'm wondering if we should try to bring all interested people on this list so
> that we have this discussion in one place. Maybe I should drop a link to this
> thread on those lists?

Seems like a good idea to me.

> The whitelisting was defined in order to support legacy devices. If people
> believe that supporting legacy devices (in normal conditions) is too risky
> anyway, we can probably drop the whitelisting feature and go for CORS. In
> other words, if you need to change your service in order to opt-in for being
> exposed, you can also change it to support CORS.

Right.

> What I personally think it could make sense is to try and define a "secure"
> version of the full spec, that "loose" the requirement for supporting legacy
> devices and instead assume that discovery protocols and services need to be
> (slightly) changed to opt-in for this feature.

The same NSD API should be usable in more than one environment: web pages, packaged apps, privileged web apps...
How access is granted in each environment can be defined in separate sections/specs with proper security guidelines for each case.

> From there it should be easy to imagine an extension that people can use in
> other scenarios where they want to support also legacy protocols and they
> are able to secure the user home network via some other means).
 
Right, the NSD API will discover legacy devices anyway.
We should (and hopefully can) provide access to legacy devices under certain additional conditions.

 y

Received on Friday, 20 September 2013 08:53:03 UTC