Re: [xacml] The road to 3.0?

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

Comments are inline -
> Prateek,
>
> I don't understand what you mean by "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". Could you clarify what you suggest?
>
[PM]

I am suggesting that individual drafts can be voted to CD and eventually 
to CS status, if there is a need for showing that progress is being 
made. This is a much smaller step than voting in a new standard and with 
much less collateral damage to on-going efforts to advance XACML deployment.

[\PM]
> Personally, I think we need to get out the new 3.0 core as soon as 
> possible for several reasons:
>
> 1. Having it around in an unfinished state creates confusion about 
> where the standard will be going, thus hindering adoption.
[PM] I dont follow the logic here. What is the problem with XACML 2.0 
that is hindering adoption? Can you point to some public sources where these
problems are described?  I understand this is your opinion but it would 
be good to understand the basis behind it.

In my experience, - which is based on my XACML presentation at RSA 2007, 
the workshop organized by Burton/Concordia at Catalyst 2008 (San Diego) 
and the Concordia mailing list,  as well as the Catalyst 2007 interop, - 
not a single person has mentioned to me that lack of XACML 3.0 as an 
issue hindering adoption.

Now people have mentioned many, many other issues with XACML and reasons 
why its uptake has been modest. Most of these have to do with gaps in 
the standard, missing profiles, deployment issues, lack of guidance and 
best practices, lack of tooling and so on.

[\PM]
>
> 2. Currently the core is taking up the effort of the TC. Closing the 
> 3.0 core frees up the TC to address the "practical issues".
[PM] I would be comfortable with voting the core to CD and, after 
suitable review, to CS at a later point in time. [\PM]
>
> 3. The switch to 3.0 will be more difficult, the longer we wait since 
> there will be more 2.0 deployments then.
[PM] Hmmmmm,...I dont get the logic here - if XACML 3.0 does not have 
any compelling value and strengths over XACML 2.0, if people are
not convinced that they should upgrade, then the problem lies with XACML 
3.0.  If  so, then we should reopen the question of why we are planning 
a major release of a standard that is still finding its place in the 
security world.
[\PM]
>
> 4. The 3.0 core is a better core (even without delegation) than the 
> 2.0 core. There are many small improvement fixing bugs and making 
> higher performance possible.
>
[PM] Again, frankly, I havent heard a single customer or analyst mention 
this issue to me. This kind of marginal improvement doesnt merit 
creation of a major new version of a standard.
[\PM]
> /Erik
>
>
> Prateek Mishra wrote:
>> 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
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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