[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Going through the issues list
All, I had a look at the issues list and I have set some due dates for issues with me as champion. I have also some opinions on what we should do with some of the open issues. 4. PDP references in policies This is an issue with Frank as champion. Does anyone have any ideas for how to do this? Could someone propose a syntax for it? 5. Policy statements in the request context It seems to me that this is done, so we should change it to pending review. 8. Alternate Owner-Policy-Statement to determine sentinel Another one with Frank as champion. Do we want to implement this? I had an idea for how to do it in that case. (See the issues list for (some) details.) 12. More general conclusions This is an issue with Bill as champion. I think this is very useful and I think the work Bill and Michiharu have done is good and the work which Ja'far did at SICS complements their work. I think this is something we can do something good on for 3.0. Can we set an estimate for completion? What about the end of February? 13. “What are my permissions?” I think this is an issue we should drop for 3.0. It is fairly complex and would delay 3.0. Also, I am not sure it affects the standard. It is really about how to best analyze and present policies to users, so it does not need any additional specification. It's just a matter for implementations to do something clever with the policy formats we already have. Perhaps we would like to standardize interfaces to call these kinds of functions in the future, but for now it seems to not to be very relevant for the standards work. 22. Right to revoke This is another issue I think we should drop for 3.0. It is either trivial or very complex, depending on how you want to do it. I think it would be fine for implementers to define their own revocation models until we have more experience on what are good solutions, and for now we should just write that a PDP can disregard policies it thinks are revoked. We can always do a 3.1. 24. Mixed administrative/access target The current draft which uses the DelegatedResource approach does not do anthing for this as a special case. Depending on how we choose to put the categories in the new schema, it may be done just with the Disjunctive/Conjunctive matches. If we choose the category placement such that we get something equivalent to the old schema, it cannot be done. It is not entirely clear to me how useful this would be. The benefit would be that you could, for instance, collect both delegation and access policies of a given resource in one policy set. If we allow for a more flexible approach, some people have expressed concerns for that indexing would be more complicated. (Could someone explain to me why indexing becomes more complicated?) Anyway, if we make up our mind, this is a quick one. I could go either way, so, could someone who feels strongly about this argue for their view. :-) 25. Nested policy sets and enforcement of delegation constraints This is an issue with me as champion. It is just writing some more text. I have set a date: 1st January. 33. How to match any delegate This is solved by the new core schema, so we should close this. 39. SAML Profile: allow return of policy and policy set id references? This is the issue of returning very large results. We discussed this a lot. Did we reach a conclusion, or is the issue still open waiting for Kamalindu? 41. Flag to force evaluation of all applicable policies This is with Hal as champion. This is really an alternative for solving issue 13, so as such, I think we should drop it for 3.0. See my comments on issue 13 above. 43. SAML profile: Inheritance between additional attributes For simplicity, I suggest that we do not require inheritance between provided attributes (should we also disallow it?). If we go with this, I just need to clarify the text, which I can do by Jan 1st. 44. SAML profile: Do we add attributes to the access request? For this, I think we agreed that we do apply them. If, this was indeed the case, we should change the issue to pending review. 46. SAML profile: multiple holders of attributes I have no strong opinion on this issue, though I prefer it as it is now, that is we allow multiple holders of attributes. If no one has any strong feelings, can we change this to pending review? 48. SAML Profile: Pass SAML Attributes in addition to XACML Attributes as extra attributes in Request? We discussed this a bit, although I think the text in the issues list doesn't describe the issue entirely correctly. The issue was whether the SAML AuthzRequest should allow extra attributes in the form of SAML attributes or assertions. I (and Anne and Bill I think) favor that we do allow only XACML attributes and that the PEP has to translate them from any native format. Could we make a decision on this? If we do not allow it, the draft is already right, so we can change to pending review. 49, 50, 51, 52. Delegation with attribute categories These are is now incorporated in the current draft, so we should change them to pending review. 53. Computational complexity of delegation We need to make up our mind here. I have promised to explain the proof and I will try to do so before the next meeting. There are more issues open with others as champions. I have not commented on all of them, but it would be nice if everyone would have a look and estimate when they can deliver something. :-) For instance, Daniel, could you provide an estimate for when you could be done with issue 3 (and 40), the generalization of the schema, and update the core doc? This is one of the major remaining issues and it is going to block other work if it is not done. Also, during the meeting yesterday, it was recognized that there is no editor for the core spec. I could do that if no one else wants to and you have trust in me. :-) Regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]