RE: XACML Proposal

["Eve L. Maler" <eve.maler@east.sun.com>]

OASIS itself is agnostic on whether its TCs come up with compatible or 
incompatible specifications.  However, TCs can choose to coordinate closely 
if they wish, and David, it sounds to me like you might want what OASIS 
calls joint committees.  See section (o) of:

   http://www.oasis-open.org/committees/process.shtml#official

I think it's potentially a great idea to ensure that the XACML work 
proceeds on the same technical assumptions the SSTC does (terminology, 
possibly use cases, etc.), to the extent that it matters for XACML's scope 
and design.  A JC could help figure this out.  Or we could achieve the same 
thing by informal liaison.

         Eve

At 02:41 PM 3/29/01 -0500, Orchard, David wrote:
>I added another option
>
>[X]Agree with the proposal with non-minor changes as noted prior to the 
>submission to OASIS for TC formation.
>
>XACML should only be chartered if the charter requires it to make 
>normative references to SAML domain model, glossary, terminology and 
>relevent use cases and requirements sections or documents.
>
>Rationale
>Assuming the XACML becomes an OASIS TC, there will be 2 security 
>committees before the security community regarding security.  As there is 
>a great potential for overlap in terminology, requirements, use-cases and 
>confusion in the market, it is my belief that the XACML committee should 
>not be chartered without an explicit relationship between and mandatory 
>sharing of certain deliverables with the Security Services 
>committee.  Intention to work closely is worthy but not sufficient, it 
>must be explicitly chartered.  The particular deliverables that should be 
>jointly adopted by XACML and SAML include, but are not limited to: Domain 
>Model,  Glossary, Terminology.  In addition, the Use Cases/Requirements 
>documents/sections should share content that is common.  Effectively, 
>these documents and/or sections should be normative references in XACML.
>
>The concern is that these documents could diverge, which should not be 
>permitted in the first 2 security works at OASIS.  It is crucial that any 
>additional works of OASIS on security should be based upon or closely 
>co-operate with SAML.
>
>I realize that it may be difficult for a close coupling to be achieved - 
>SAML may be slowed down to ensure XACML items are clearly expressed - and 
>XACML may not have the freedom to move as quickly as it might 
>like.  Integration and coherency is paramount and any potential slippage 
>in schedule is far better than any divergence.
>
>However, given that SAML will be roughly 5 months ahead of the first XACML 
>meeting (45 days after charter), this should not prove onerous as SAML 
>should be stable in these elements.  In addition, many potential members 
>of XACML are on SAML, who can individually or as a group ensure the 
>relevent SAML sections are extensible for XACML.
>
>Cheers,
>
>Dave Orchard
>XML Architect
>Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
>p: 408.864.5118     m: 604.908.8425    f: 408.725.4310
>
>www.jamcracker.com - Sounds like a job for Jamcracker.

--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com