ISSUE-93 More Rationale

[ashok malhotra <ashok.malhotra@oracle.com>]

http://www.osoa.org/jira/browse/POLICY-93  Allow External Attachment for 
Intents
Here is further rationale in addition to what was presented in
http://lists.oasis-open.org/archives/sca-policy-comment/200906/msg00007.html 


Our developers are now convinced that intents are a good thing and serve 
as useful
abstractions for policy requirements.  They are using intents, however, 
in a manner that is a bit
different from what was originally envisaged when intents were 
invented.  Here are some
issues/requirements.  These reflect our continuing emphasis on 
separating policy artifacts from
implementation code and are drawn from real situations

1. Security intents are not attached by the developer.  There are 
special, separate, security experts
who attach intents after the developer has done his job.  So, it should 
be possible to attach security intents
as a separate step after the code is written and it is better if the 
security expert does not need to muck
with the code.

2. In some cases the customer can change intents.  Oracle products are 
shipped "secure by default"
The customer may think this is unnecessary and/or too expensive and may 
want to lower the bar.
Again. you don't want him changing the code.  If intents are attached 
externally he changes just the intents file.

3.  And, of course, corporate policies change.  External attachment just 
makes changing intents or attaching additional
intents much easier.

4. Developers cannot be trusted.  In the case of "secure by default" we 
have special scripts that go through the code
and check if the right intents have been attached.  This would much 
simpler if intents were attached externally.

PROPOSAL:
Add an "attachTo"  attribute to intents.   It's a simple addition.  You 
don't have to use it if you don't want to.
-- 
All the best, Ashok