Re: [xacml] The road to 3.0?

[Prateek Mishra <prateek.mishra@oracle.com>]

Erik,

Going  to a new version of  a standard is a very big deal - we need to 
be able to explain at a high-level why we need to do this and what 
benefits will obtain to customers and vendors. There is a lot of 
experimentation on-going with XACML 2.0 - many people are pointing out 
gaps and practical problems (your comments below) and I think it would 
be critical to address these before creating a new version of the standard.

Just my 2cents - I think there are techniques available to handle the 
issue of certain drafts needing to show progress in the short term 
(e,g., CD, CS) without creating a new version.

- prateek
> All,
>
> I would like to discuss how we could proceed with 3.0.
>
> As far as I can recall all the currently open issues on the core, 
> except 66, are "petty" issues just pending for me to fix in the draft. 
> I was hoping to have done that to this week, but unfortunately I've 
> had other things to do.
>
> Earlier I posted a proposal to split issue 66 into a simple fix for 
> core and then postpone the full solution to a separate profile. If the 
> TC adopts this proposal I think we are pretty much done with the 3.0 
> core.
>
> The delegation profile has no open issues, and neither do the "classic 
> 2.0 profiles", except the SAML profile which has one petty already 
> decided issue, the placement of supplied policies, and one simple open 
> issue 86.
>
> So I think we could move forward with core, delegation and the classic 
> profiles fairly soon.
>
> WS-XACML has a problem with the xpath subset which it specifies. It 
> doesn't work as intended. Also, we may want to pursue the use of 
> WS-XACML for attribute vocabulary publishing/negotiation, which is a 
> complex, fully open issue.
>
> The obligation families are still in an early shape, not ready to move 
> forward.
>
> That's those specs and profiles we are currently working on.
>
> Beyond that I think XACML is lacking some very important things which 
> I think this TC should address. The PDP/PEP/PIP/PAP architecture is 
> too high level to address real problems which adopters/customers are 
> facing. Rich has brought up many of these issues and I also have lots 
> of ideas of how to break this thing up into a more fine grained 
> architecture which will solve problems, guide implementors and 
> identify some additional protocols which need to be standardized. (For 
> instance, the attribute vocabulary issue is not visible in the current 
> very high level architecture.) However, I don't want to open up more 
> work items until we are done with those items we have now.
>
> Anyway, my question is how do we proceed?
>
> On the other hand going OASIS standard is a big step which we don't 
> want to do many times, but we also don't want to wait for some of the 
> more unfinished works in progress since if we do that always, we will 
> never close anything.
>
> Hal, you probably have a good idea of what we should do? Should we go 
> committee draft or perhaps even committee specification with 
> everything which we can finish soon and then wait in the rest?
>
> Another alternative is to go OASIS standard as soon as we can with the 
> most important profiles and core, and then reconsider what we do with 
> the remaining profiles.
>
> The whole thing is also affected by that we have to wait in the 
> implementations, so perhaps there is a natural waiting period here 
> anyway?
>
> For the obligation families is still pretty immature, so I could drop 
> it out from the 3.0 process if it's going to hold us back.
>
> WS-XACML might be more easily fixable, but there is currently no 
> champion working on it.
>
> The new items I would like to pursue are very important for XACML 
> adoption, but I am not sure they need to be an OASIS standard since 
> they would to a large degree be an architecture framework, and it 
> might a bit vague in how one conforms to it anyway. They might be more 
> informational.
>
> I think I fix all the petty issues in core and the classic profiles 
> within two weeks time.
>
> Best regards,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php