[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New drafts uploaded
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]