xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xacml] The road to 3.0?
- From: "Abbie Barbir" <abbieb@nortel.com>
- To: "Anthony Nadalin" <drsecure@us.ibm.com>, "Erik Rissanen" <erik@axiomatics.com>
- Date: Wed, 29 Oct 2008 17:39:49 -0400
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
Erik, I agree
Anthony Nadalin | Work 512.838.0085 | Cell
512.289.4122
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]