OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Going through the issues list


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)

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

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. :-)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]