OASIS eXtensible Access Control Markup Language (XACML) TC

All,

I would like to finish XACML 3.0. :-)

So, what do we still have to do?

There is the issues list of course. More on that below. I need to update 
the docs to the new OASIS templates as well. But besides that, what more 
is there to do?

The delegation draft lacks a conformance section. I can make one. The 
core has one already since the doc is really just an updated 2.0 doc. 
Have there been any changes to the requirements on the conformance 
requirements section from the side of OASIS?

It might be a good idea if someone who is a native English speaker 
proofreads the docs, but we can wait with that until the end.

The profiles also need to be updated, but I suspect that it is mostly 
just updating to the new schema.

Below you can find the the issues list with some proposals. Could we 
discuss the issues at the next meeting? I also propose that we move any 
post 3.0 issues to a separate wiki page so we can focus on wrapping up 3.0.

Issue 12, more general conclusions: Bill and I posted a working draft 
about generalized obligations. We have not received much feedback on 
this. I propose that we defer this to post 3.0.

Related to this is the issue about the timing attribute for obligations 
which was proposed by David Chadwick. I put this as a feature in the 
obligation draft. If we defer the obligation draft, do we want to 
include the timing attribute in the 3.0 core? In my opinion this depends 
on what we expect will happen with the obligation work. My preference is 
that we after 3.0 core is done quickly complete the obligation work, in 
which case the timing should go there, not in the core now. But if the 
obligation profile will never happen, then we should include the timing 
attribute in the core now.

Issue 23, access permitted: This is waiting for Hal to update the 
proposal to the new core schema. Also, there are concerns about how this 
could affect the complexity of evaluation. Hal, what is you take on this?

Issue 36, PDP metadata: I suggest that we wait with this issue until 
last in the 3.0 work and see what meta date we need.

Issue 62, policy provisioning interface. I think this is post 3.0. It 
doesn't affect the core directly and this work is very early yet.

Issue 63 is just waiting for me to update the docs. Will do soon. :)

Issue 66, missing attributes may be underspecified. I propose that we 
defer this to post 3.0. It is early work and might be better suited for 
a profile for a PDP <-> PEP protocol.

Issue 67, XPath 2.0. There is a proposal in the docs, but someone who 
knows xpath better than me needs to review it. If no one wants to review 
it, I propose that we go with as it is and make errata later if needed. :-)

Issue 71, different categories as different entities: I propose that we 
defer this post 3.0. It is a major change from XACML 2.0 and there is no 
concrete proposal. I am also concerned with computational complexity 
since this is related to the complexity issue we got with distinct 
indirect delegates.

Issue 72, placement of supplied policies is open needs to be done for 
3.0. I will think up a proposal.

Issue 73, start of administrative requests in nested policy sets. I 
think we don't need to change anything as things are now, but I will 
think more about it. I will write an explanation of whatever result I reach.

Issue 75, PEP <-> PDP interface. Defer this to a post 3.0 profile.

Issue 76, multiple conditions. I'm not sure about this one. Seems like 
partly a duplicate of issue 71. I also wonder whether it is not possible 
to implement the xpath part of this issue using clever xpaths and bag 
functions in the policy.

Issues 82, 83 and 85 seem straightforward to fix.

On Aug 24, 2007, at 4:11 AM, Erik Rissanen wrote:

> It might be a good idea if someone who is a native English speaker  
> proofreads the docs, but we can wait with that until the end.

I can do this.

> Issue 12, more general conclusions: Bill and I posted a working  
> draft about generalized obligations. We have not received much  
> feedback on this. I propose that we defer this to post 3.0.

I think this is a good idea. Once delegation is behind us perhaps  
their will be greater interest in pursuing this.

> Related to this is the issue about the timing attribute for  
> obligations which was proposed by David Chadwick. I put this as a  
> feature in the obligation draft. If we defer the obligation draft,  
> do we want to include the timing attribute in the 3.0 core? In my  
> opinion this depends on what we expect will happen with the  
> obligation work. My preference is that we after 3.0 core is done  
> quickly complete the obligation work, in which case the timing  
> should go there, not in the core now. But if the obligation profile  
> will never happen, then we should include the timing attribute in  
> the core now.

I believe that it should be incorporated into the Obligations draft,  
adding it to the current (highly implementation dependent)  
Obligations model doesn't buy much I think.

b

Colleagues,

I would like to voice my concern about this movement towards a 3.0 
release. Creating a new version of a standard is a major step and it 
could easily create confusion in the marketplace and even hinder ongoing 
XACML 2.0 implementation.

Its not clear to me why we need this release and to what extent it is 
based on needs of the industry. Is there adequate implementation, 
deployment and understanding of XACML 2.0  in the industry and the 
community?

Working collaboratively, the TC managed to pull off a major milestone in 
XACML 2.0's development - the interop at Catalyst 2007. The interop 
document and discussions around it have generated a wealth of open 
issues and concerns that need to be answered if XACML is to mature and 
receive substantial implementation. I am deeply concerned that so far we 
havent addressed almost any of these issues and concerns.

I have separately published a list of issues relevant to enterprises 
based on a presentation I gave at RSA2007. This presentation was warmly 
received and many industry professionals remarked to me that gaps of the 
type I captured were of interest to them.

We would be happy to invest effort in capturing all of these issues.  
Rich  Levinson and I will commit to publishing a draft in the next 
month. I hope we will be able to engage around these issues within the 
TC and respond to these requirements that have been derived from real 
deployments and scenarios.

Thanks,

prateek mishra


> All,
>
> I would like to finish XACML 3.0. :-)
>
> So, what do we still have to do?
>
> There is the issues list of course. More on that below. I need to 
> update the docs to the new OASIS templates as well. But besides that, 
> what more is there to do?
>
> The delegation draft lacks a conformance section. I can make one. The 
> core has one already since the doc is really just an updated 2.0 doc. 
> Have there been any changes to the requirements on the conformance 
> requirements section from the side of OASIS?
>
> It might be a good idea if someone who is a native English speaker 
> proofreads the docs, but we can wait with that until the end.
>
> The profiles also need to be updated, but I suspect that it is mostly 
> just updating to the new schema.
>
> Below you can find the the issues list with some proposals. Could we 
> discuss the issues at the next meeting? I also propose that we move 
> any post 3.0 issues to a separate wiki page so we can focus on 
> wrapping up 3.0.
>
> Issue 12, more general conclusions: Bill and I posted a working draft 
> about generalized obligations. We have not received much feedback on 
> this. I propose that we defer this to post 3.0.
>
> Related to this is the issue about the timing attribute for 
> obligations which was proposed by David Chadwick. I put this as a 
> feature in the obligation draft. If we defer the obligation draft, do 
> we want to include the timing attribute in the 3.0 core? In my opinion 
> this depends on what we expect will happen with the obligation work. 
> My preference is that we after 3.0 core is done quickly complete the 
> obligation work, in which case the timing should go there, not in the 
> core now. But if the obligation profile will never happen, then we 
> should include the timing attribute in the core now.
>
> Issue 23, access permitted: This is waiting for Hal to update the 
> proposal to the new core schema. Also, there are concerns about how 
> this could affect the complexity of evaluation. Hal, what is you take 
> on this?
>
> Issue 36, PDP metadata: I suggest that we wait with this issue until 
> last in the 3.0 work and see what meta date we need.
>
> Issue 62, policy provisioning interface. I think this is post 3.0. It 
> doesn't affect the core directly and this work is very early yet.
>
> Issue 63 is just waiting for me to update the docs. Will do soon. :)
>
> Issue 66, missing attributes may be underspecified. I propose that we 
> defer this to post 3.0. It is early work and might be better suited 
> for a profile for a PDP <-> PEP protocol.
>
> Issue 67, XPath 2.0. There is a proposal in the docs, but someone who 
> knows xpath better than me needs to review it. If no one wants to 
> review it, I propose that we go with as it is and make errata later if 
> needed. :-)
>
> Issue 71, different categories as different entities: I propose that 
> we defer this post 3.0. It is a major change from XACML 2.0 and there 
> is no concrete proposal. I am also concerned with computational 
> complexity since this is related to the complexity issue we got with 
> distinct indirect delegates.
>
> Issue 72, placement of supplied policies is open needs to be done for 
> 3.0. I will think up a proposal.
>
> Issue 73, start of administrative requests in nested policy sets. I 
> think we don't need to change anything as things are now, but I will 
> think more about it. I will write an explanation of whatever result I 
> reach.
>
> Issue 75, PEP <-> PDP interface. Defer this to a post 3.0 profile.
>
> Issue 76, multiple conditions. I'm not sure about this one. Seems like 
> partly a duplicate of issue 71. I also wonder whether it is not 
> possible to implement the xpath part of this issue using clever xpaths 
> and bag functions in the policy.
>
> Issues 82, 83 and 85 seem straightforward to fix.
>
>
>

During the last call I asked people to identify the issues or new
features we intend to complete for version 3.0. I agree than many of
your suggestions would be quite valuable additions to the next version
of XACML.

On the other, I don't think XACML 3.0 should be arbitrarily held up just
because people are beginning to implement 2.0. A lot of time and effort
has been put into Admin policies for example and that functionality is
frequently requested. Also I expect some of the 3.0 work, such as the
SAML Profile, WS-XACML profile and the Provisioning Protocol will be
useful in conjunction with XACML 2.0.

I think the PR aspect of this can be dealt with by careful handling. For
one thing it will be legal to support only "3.0 without Admin policies".
This should be an easy step for current 2.0 implementations.

We should discuss this on the call.

Hal

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
> Sent: Wednesday, September 05, 2007 1:25 PM
> To: Erik Rissanen
> Cc: XACML TC
> Subject: Re: [xacml] Moving ahead with 3.0
> 
> Colleagues,
> 
> I would like to voice my concern about this movement towards a 3.0
> release. Creating a new version of a standard is a major step and it
> could easily create confusion in the marketplace and even hinder
ongoing
> XACML 2.0 implementation.
> 
> Its not clear to me why we need this release and to what extent it is
> based on needs of the industry. Is there adequate implementation,
> deployment and understanding of XACML 2.0  in the industry and the
> community?
> 
> Working collaboratively, the TC managed to pull off a major milestone
in
> XACML 2.0's development - the interop at Catalyst 2007. The interop
> document and discussions around it have generated a wealth of open
> issues and concerns that need to be answered if XACML is to mature and
> receive substantial implementation. I am deeply concerned that so far
we
> havent addressed almost any of these issues and concerns.
> 
> I have separately published a list of issues relevant to enterprises
> based on a presentation I gave at RSA2007. This presentation was
warmly
> received and many industry professionals remarked to me that gaps of
the
> type I captured were of interest to them.
> 
> We would be happy to invest effort in capturing all of these issues.
> Rich  Levinson and I will commit to publishing a draft in the next
> month. I hope we will be able to engage around these issues within the
> TC and respond to these requirements that have been derived from real
> deployments and scenarios.
> 
> Thanks,
> 
> prateek mishra
> 
> 
> > All,
> >
> > I would like to finish XACML 3.0. :-)
> >
> > So, what do we still have to do?
> >
> > There is the issues list of course. More on that below. I need to
> > update the docs to the new OASIS templates as well. But besides
that,
> > what more is there to do?
> >
> > The delegation draft lacks a conformance section. I can make one.
The
> > core has one already since the doc is really just an updated 2.0
doc.
> > Have there been any changes to the requirements on the conformance
> > requirements section from the side of OASIS?
> >
> > It might be a good idea if someone who is a native English speaker
> > proofreads the docs, but we can wait with that until the end.
> >
> > The profiles also need to be updated, but I suspect that it is
mostly
> > just updating to the new schema.
> >
> > Below you can find the the issues list with some proposals. Could we
> > discuss the issues at the next meeting? I also propose that we move
> > any post 3.0 issues to a separate wiki page so we can focus on
> > wrapping up 3.0.
> >
> > Issue 12, more general conclusions: Bill and I posted a working
draft
> > about generalized obligations. We have not received much feedback on
> > this. I propose that we defer this to post 3.0.
> >
> > Related to this is the issue about the timing attribute for
> > obligations which was proposed by David Chadwick. I put this as a
> > feature in the obligation draft. If we defer the obligation draft,
do
> > we want to include the timing attribute in the 3.0 core? In my
opinion
> > this depends on what we expect will happen with the obligation work.
> > My preference is that we after 3.0 core is done quickly complete the
> > obligation work, in which case the timing should go there, not in
the
> > core now. But if the obligation profile will never happen, then we
> > should include the timing attribute in the core now.
> >
> > Issue 23, access permitted: This is waiting for Hal to update the
> > proposal to the new core schema. Also, there are concerns about how
> > this could affect the complexity of evaluation. Hal, what is you
take
> > on this?
> >
> > Issue 36, PDP metadata: I suggest that we wait with this issue until
> > last in the 3.0 work and see what meta date we need.
> >
> > Issue 62, policy provisioning interface. I think this is post 3.0.
It
> > doesn't affect the core directly and this work is very early yet.
> >
> > Issue 63 is just waiting for me to update the docs. Will do soon. :)
> >
> > Issue 66, missing attributes may be underspecified. I propose that
we
> > defer this to post 3.0. It is early work and might be better suited
> > for a profile for a PDP <-> PEP protocol.
> >
> > Issue 67, XPath 2.0. There is a proposal in the docs, but someone
who
> > knows xpath better than me needs to review it. If no one wants to
> > review it, I propose that we go with as it is and make errata later
if
> > needed. :-)
> >
> > Issue 71, different categories as different entities: I propose that
> > we defer this post 3.0. It is a major change from XACML 2.0 and
there
> > is no concrete proposal. I am also concerned with computational
> > complexity since this is related to the complexity issue we got with
> > distinct indirect delegates.
> >
> > Issue 72, placement of supplied policies is open needs to be done
for
> > 3.0. I will think up a proposal.
> >
> > Issue 73, start of administrative requests in nested policy sets. I
> > think we don't need to change anything as things are now, but I will
> > think more about it. I will write an explanation of whatever result
I
> > reach.
> >
> > Issue 75, PEP <-> PDP interface. Defer this to a post 3.0 profile.
> >
> > Issue 76, multiple conditions. I'm not sure about this one. Seems
like
> > partly a duplicate of issue 71. I also wonder whether it is not
> > possible to implement the xpath part of this issue using clever
xpaths
> > and bag functions in the policy.
> >
> > Issues 82, 83 and 85 seem straightforward to fix.
> >
> >
> >

  


Hi Hal,


I appreciate what you are saying about the work that has been done,

and, in particular, the admin and WS-XACML stuff needs to be moved

along rapidly. However, I am concerned after briefly looking over the
changes

to XACML core, that while I can see the motivation for removing the

Subject, Resource, Action, and Environment and replacing them with

a generic Attribute, I question the trade-off here between what is a
real

customer need and what is being done just to "clean-up" the protocol vs

the price we will pay for disrupting the interoperability. i.e. if the
same

functionality is actually available in 2.0, albeit in a less clean
manner, I am

concerned that the price of  "clean-up" is to risk all kinds of negative

press about how "unstable" the protocol appears to be. I'd be curious

what some of the Burton people would have to say about this.


It seems to me, although I haven't gotten to all the details yet, that
a lot

of what you say is valuable about admin and WS-XACML could be

had building as profiles and adjuncts to 2.0. Is there a reason why
these

core changes are tied to those items?


    Thanks,

    Rich



Hal Lockhart wrote:
2E22E42D2E71B845B67F093A02B962DBF4459E@repbex01.amer.bea.com" type="cite">
  
During the last call I asked people to identify the issues or new
features we intend to complete for version 3.0. I agree than many of
your suggestions would be quite valuable additions to the next version
of XACML.

On the other, I don't think XACML 3.0 should be arbitrarily held up just
because people are beginning to implement 2.0. A lot of time and effort
has been put into Admin policies for example and that functionality is
frequently requested. Also I expect some of the 3.0 work, such as the
SAML Profile, WS-XACML profile and the Provisioning Protocol will be
useful in conjunction with XACML 2.0.

I think the PR aspect of this can be dealt with by careful handling. For
one thing it will be legal to support only "3.0 without Admin policies".
This should be an easy step for current 2.0 implementations.

We should discuss this on the call.

Hal

  
  

    


                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
Sent: Wednesday, September 05, 2007 1:25 PM
To: Erik Rissanen
Cc: XACML TC
Subject: Re: [xacml] Moving ahead with 3.0

Colleagues,

I would like to voice my concern about this movement towards a 3.0
release. Creating a new version of a standard is a major step and it
could easily create confusion in the marketplace and even hinder
    
  
  
ongoing
  
  

    
XACML 2.0 implementation.

Its not clear to me why we need this release and to what extent it is
based on needs of the industry. Is there adequate implementation,
deployment and understanding of XACML 2.0  in the industry and the
community?

Working collaboratively, the TC managed to pull off a major milestone
    
  
  
in
  
  

    
XACML 2.0's development - the interop at Catalyst 2007. The interop
document and discussions around it have generated a wealth of open
issues and concerns that need to be answered if XACML is to mature and
receive substantial implementation. I am deeply concerned that so far
    
  
  
we
  
  

    
havent addressed almost any of these issues and concerns.

I have separately published a list of issues relevant to enterprises
based on a presentation I gave at RSA2007. This presentation was
    
  
  
warmly
  
  

    
received and many industry professionals remarked to me that gaps of
    
  
  
the
  
  

    
type I captured were of interest to them.

We would be happy to invest effort in capturing all of these issues.
Rich  Levinson and I will commit to publishing a draft in the next
month. I hope we will be able to engage around these issues within the
TC and respond to these requirements that have been derived from real
deployments and scenarios.

Thanks,

prateek mishra


    
    

      
All,

I would like to finish XACML 3.0. :-)

So, what do we still have to do?

There is the issues list of course. More on that below. I need to
update the docs to the new OASIS templates as well. But besides
      
    
  
  
that,
  
  

    

      
what more is there to do?

The delegation draft lacks a conformance section. I can make one.
      
    
  
  
The
  
  

    

      
core has one already since the doc is really just an updated 2.0
      
    
  
  
doc.
  
  

    

      
Have there been any changes to the requirements on the conformance
requirements section from the side of OASIS?

It might be a good idea if someone who is a native English speaker
proofreads the docs, but we can wait with that until the end.

The profiles also need to be updated, but I suspect that it is
      
    
  
  
mostly
  
  

    

      
just updating to the new schema.

Below you can find the the issues list with some proposals. Could we
discuss the issues at the next meeting? I also propose that we move
any post 3.0 issues to a separate wiki page so we can focus on
wrapping up 3.0.

Issue 12, more general conclusions: Bill and I posted a working
      
    
  
  
draft
  
  

    

      
about generalized obligations. We have not received much feedback on
this. I propose that we defer this to post 3.0.

Related to this is the issue about the timing attribute for
obligations which was proposed by David Chadwick. I put this as a
feature in the obligation draft. If we defer the obligation draft,
      
    
  
  
do
  
  

    

      
we want to include the timing attribute in the 3.0 core? In my
      
    
  
  
opinion
  
  

    

      
this depends on what we expect will happen with the obligation work.
My preference is that we after 3.0 core is done quickly complete the
obligation work, in which case the timing should go there, not in
      
    
  
  
the
  
  

    

      
core now. But if the obligation profile will never happen, then we
should include the timing attribute in the core now.

Issue 23, access permitted: This is waiting for Hal to update the
proposal to the new core schema. Also, there are concerns about how
this could affect the complexity of evaluation. Hal, what is you
      
    
  
  
take
  
  

    

      
on this?

Issue 36, PDP metadata: I suggest that we wait with this issue until
last in the 3.0 work and see what meta date we need.

Issue 62, policy provisioning interface. I think this is post 3.0.
      
    
  
  
It
  
  

    

      
doesn't affect the core directly and this work is very early yet.

Issue 63 is just waiting for me to update the docs. Will do soon. :)

Issue 66, missing attributes may be underspecified. I propose that
      
    
  
  
we
  
  

    

      
defer this to post 3.0. It is early work and might be better suited
for a profile for a PDP <-> PEP protocol.

Issue 67, XPath 2.0. There is a proposal in the docs, but someone
      
    
  
  
who
  
  

    

      
knows xpath better than me needs to review it. If no one wants to
review it, I propose that we go with as it is and make errata later
      
    
  
  
if
  
  

    

      
needed. :-)

Issue 71, different categories as different entities: I propose that
we defer this post 3.0. It is a major change from XACML 2.0 and
      
    
  
  
there
  
  

    

      
is no concrete proposal. I am also concerned with computational
complexity since this is related to the complexity issue we got with
distinct indirect delegates.

Issue 72, placement of supplied policies is open needs to be done
      
    
  
  
for
  
  

    

      
3.0. I will think up a proposal.

Issue 73, start of administrative requests in nested policy sets. I
think we don't need to change anything as things are now, but I will
think more about it. I will write an explanation of whatever result
      
    
  
  
I
  
  

    

      
reach.

Issue 75, PEP <-> PDP interface. Defer this to a post 3.0 profile.

Issue 76, multiple conditions. I'm not sure about this one. Seems
      
    
  
  
like
  
  

    

      
partly a duplicate of issue 71. I also wonder whether it is not
possible to implement the xpath part of this issue using clever
      
    
  
  
xpaths
  
  

    

      
and bag functions in the policy.

Issues 82, 83 and 85 seem straightforward to fix.



      
    
  
  

  

Rich Levinson wrote:
>
> It seems to me, although I haven't gotten to all the details yet, that 
> a lot
> of what you say is valuable about admin and WS-XACML could be
> had building as profiles and adjuncts to 2.0. Is there a reason why these
> core changes are tied to those items?

The  admin policies (aka delegation) were initially designed on top of 
the old 2.0 schema with subject/resource/etc. We decided to generalize 
the schema to attribute categories because of three reasons:

1. In our discussions someone, I don't remember who, said that there had 
been requests from users who did not like to be tied to the fixed 
existing categories. They felt their applications mapped better to other 
categories.

2. Delegation requires a new category for attributes, the Delegate. We 
also had an IndirectDelegate at the time, but this was removed because 
of computational complexity issues in the delegation model. It was felt 
that since we need to introduce a couple of new categories now, we might 
as well go ahead and move the categories from the XML schema into URIs 
so we could ad more categories in the future if needed by yet unknown 
features.

3. The initial implementation of delegation on top of the 2.0 schema 
lead to some technical difficulties regarding the distinction between 
administrative policies and access policies. Since both used the same 
attribute categories we needed to differentiate between the two types of 
policies by other means, such as the presence of a Delegate category in 
the target. This lead to problems since it was not possible to write 
targets matching any delegate, unless additional special constructs were 
introduced in the target. All these issues were solved by putting 
administrative requests in their own attribute categories, as permitted 
by the generalized schema. In other words, delegation is easier to 
implement on top of the general schema.

As it happened, 1 and 2 preceded 3 in the discussion and technical work. 
(We didn't realize that delegation became easier until after we moved to 
general categories.)

I think now is a better time to make this change rather than later. The 
more 2.0 deployments there are, the harder it will be to do the change 
in the future. The general categories allow for considerable flexibility 
for the future without the need of schema breaking changes.

Best regards,
Erik