The new advice "obligation"

[Erik Rissanen <erik@axiomatics.com>]

All,

During the call yesterday we decided to introduce a new "type of 
obligation", perhaps called <Advice>.

I have two things to say.

1. Here is a syntax which we could consider:

<Advice AdviceId="urn:...." AppliesTo="Permit">
 <AttributeAssignment>.....</>
</Advice>

Any other ideas for naming it?

2. Should it be possible to have this apply to NotApplicable as well, 
not just Permit/Deny?

I am asking since a customer of mine wanted to use obligations on 
NotApplicable to return a reason for why access was not allowed.

I haven't thought it through properly yet, but it seems like a good 
idea. Typically I would expect policies to list stuff that is allowed, 
with perhaps some exceptions which deny. In general it's a good 
principle for security design to "enumerate goodness", rather than to 
try to list everything which is bad/dangerous. If one does so, if a 
policy does not match, it would  be NotApplicable, not Deny, so it would 
not be possible to return advice about what did not match. If we don't 
allow advice on NotApplicable, then policy writers need to refactor 
their policies to return Deny instead of NotApplicable when they do not 
match.

Refactoring like that gives a fundamentally different "architecture" for 
the policies. Now we will have policies which say "Deny" on things they 
do not apply to, and policies which apply say "Permit". This forces the 
user to use a permit-overrides algorithm, which further limits how 
policies can be structured. Essentially the policy writer is forced to 
work with Permit/Deny only, and NotApplicable is not something he can 
use in his policies.

Best regards,
Erik