[security] describing trust domain requirements for policy requirements draft

One apparent difference of the BONDI [1], [2]  and Nokia [3]  
submissions to the DAP WG is the handling of trust domains.

The Nokia input, given in the position paper, has trust domain  
handling explicit, with a "trust manager" determining the trust domain  
based on various inputs, in particular origin, and possibly signatures/ 
certificates. Access control policy may then be based on trust domain,  
with different decisions based on the (named) trust domain.

I'd suggest the BONDI security model also requires trust domain  
handling, with inputs in the "subject attribute" in section 5.4,  
Logical Model [2], e.g. origin, signatures/certificates etc. In this  
case a trust domain is not named, but is implicit in the subject +  
subject attribute information which drives access decisions. Another  
way of saying this is that for the two classes ("widget" and  
"website") there are various combinations of attributes noted in BONDI  
Security Appendix B, and a number of these combinations could  
correspond to the same policy decisions, and be named as  "trust  
domains". It doesn't look like that many - untrusted, widget/website  
signed (by author,  distributor, both)?

I'm not sure I understand in practice how many variants based on the  
attributes listed in Appendix B are really unique, in other words how  
many distinct trust domains are likely in BONDI? Is it possible to  
make a simple table/list?

I think  it would be useful to explicitly include trust in the DAP  
policy requirements document [4], in particular the classes,  
attributes and logical trust domains. The reason is that the trust  
domain (implicit or explicit) drives subsequent decisions. Naming  
trust domains does not seem inconsistent with BONDI and offers value  
in reducing duplication of policy and making purpose clearer, but  
regardless it would be helpful to understand the list corresponding to  
expected use cases.

What do you think?

regards, Frederick

Frederick Hirsch
Nokia

[1] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf

[2] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_Appendices_v1_01.pdf

[3] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-0012/SecurityPolicy_09.pdf

[4] http://dev.w3.org/2009/dap/policy-reqs/

Received on Tuesday, 8 December 2009 20:47:38 UTC