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: RE: [xacml] The road to 3.0?


All
u will need to also think about updating X.1142 the ITU version 2.
Thus you will need a committee that will format version 3 in ITU compatible version for submission to the ITU
cheers


From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Wednesday, October 29, 2008 3:21 PM
To: Erik Rissanen
Cc: Prateek Mishra; XACML TC
Subject: Re: [xacml] The road to 3.0?

Erik, I agree

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for Erik Rissanen ---10/29/2008 03:53:05 AM---Prateek,Erik Rissanen ---10/29/2008 03:53:05 AM---Prateek,


From:

Erik Rissanen <erik@axiomatics.com>

To:

Prateek Mishra <prateek.mishra@oracle.com>

Cc:

XACML TC <xacml@lists.oasis-open.org>

Date:

10/29/2008 03:53 AM

Subject:

Re: [xacml] The road to 3.0?





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?

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.

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".

3. The switch to 3.0 will be more difficult, the longer we wait since
there will be more 2.0 deployments then.

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.

/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 




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