Re: about high-level or low-level API (ISSUE-17)

On 16/6/11 02:04 , Russell Berkoff wrote:
> 1.Allowing a UA to send arbitrary messages on the HomeNetwork creates 
> a security exposure.
JCD: I am not sure about that. I believe the security exposure comes 
from the UA presenting an application that sends messages.
The UA itself will not send any message unless it is on behalf of an 
application.
That side of security needs to be addressed by either:
- a static declaration of all messages that an application will use, as 
part of its manifest, so that the UA can evaluate the security risk
- digital signature of the application by a trusted party or whitelisting
- or the implementation of a security policy enforcer which would filter 
unauthorized messages
This is addressed by the section "HN access allowed only to Trusted 
applications" of the security document.

> In order to "enforce" some kind of security model the UA needs to know 
> what kind of device its talking to. A UPnP framework would need to 
> enforce this by doing partial discovery (only basic type information 
> about a device) unless the webpage provides the UA a password to 
> access that device.
JCD: This is addressed by the section "Device Pairing" of the security 
document.


> This requires some predefined knowledge of the HN protocols being used.
JCD: I am not sure about that. Could you elaborate which knowledge ?

> 2.How does the HN specific code get installed on a UA. Is it built in?
>
JCD: This is an implementation issue.


> How does a web-page determine what (built-in) HN Technologies a 
> particular UA supports?
>
JCD: This is a conformance issue. We are only discussing conformant 
(complete) implementations of a future standard.


> Is a UA allowed to dynamically load "plugin-like" HN access code? How 
> is this done in a browser neutral way?
>
JCD: This is an implementation issue.


> 3.In terms of access to UA platform functions, I was talking about 
> something that converts a UA into a HN server (rather than a client). 
> An example would be a webpage that allows a UA to expose some part of 
> its underlying file-system to other UAs.
>
JCD: Actually, the web page is the ONLY way within HNTF scope.

> This would typically be done by running a webserver and supplying the 
> necessary PHPs. However,  I think we are looking for an all-in-the-box 
> solution that allows a UA to do this without installing a webserver 
> and PHPware.
>
JCD: In our widgets+UPnP implementation, the UA is also a webserver (has 
to be, as any UPnP provider of a service).

> 4.Is there a requirement for a "sandbox" mode where a suspect webpage 
> could be restricted in its access to HN protocols. This would again 
> require some knowledge of what the webpage was trying to do on the HN 
> rather than allowing generic access.
>
JCD: This is why I advocate for the need of a manifest for any HNTF 
application, declaring statically all messages that it will use. The 
manifest can then be checked before presenting the application, and any 
message sent can be checked by a security enforcer module within the UA.
Best regards
JC
-- 

JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144