New drafts uploaded

[Erik Rissanen <mirty@sics.se>]

All,

I have uploaded the first draft of 3.0 core and an updated delegation
profile draft.

There are still issues pending as I have posted on the list, but I
wanted to make it available for all so you can start reading them and
providing comments. Also, particularly the core document, I have
probably missed many small things. Here are some highlights of the
changes and issues remaining:

The problem with the generalized target and backwards compatibility of
subject categories remains in this draft.

The id is still there in the AttributeSelector, although it should
probably be removed.

I updated the reduction table according to the simpler reduction model I
explained at the last meeting. Treatment of indeterminate is still not
defined.

In line with this, I removed references of combination happening during
reduction. Since we don't support negative administrative rights, there
is no need to combine during reduction.

I have tried to simplify the descriptive text as well. In particular I
removed the talk about "policy values" being reduced which didn't help
the description much. Now it's just policies which are reduced.

Thanks to all the simplifications and the generalized core, the
delegation processing model is only about three pages now. :-)

Note that there is a corner case in the simplified delegation model with
regard to nested policy sets. When an administrative request enters a
nested policy set, if there are any policies with non-trusted issuers,
they will be reduced even if they say deny on the administrative
request. Deny results during reduction still have no effect though, as
intended. (What we don't want is that one policy says yes and another no
during reduction.)

It is also possible to write a nested policy set which contains trusted
policies, where the trusted policies may override each other with deny
even if they are administrative policies. This is a good thing since it
allows writing policy sets based on a broad permit and exceptions in the
form of deny, even in the case of administrative policies. Again, deny
administrative policies are ignored during reduction.

Could someone who knows, check that I chose the right version of the
legal boilerplate?

I removed the last paragraph from use case 1 in section 3.1.1 in the
delegation profile. It used to say: 'It is also desirable to support
multiple levels of indirection, so it should be possible to say things
like "Jack can create policies that let Mary create policies about the
Financial Servers."' This is not possible without indirect delegates,
which make delegation NP-complete. (Let it be known if you think this
use case is important enough to make delegation NP-complete.)

Maximum delegation depth is still the same as in the previous draft,
with the problems I explained on the list.

There are some issues with the Access Permitted feature. I am explaining
those in a separate email so the issues are not lost in this email.

Best regards,
Erik