RE: XACML Proposal

[Krishna Sankar <ksankar@cisco.com>]

Hi all,

	There would definitely be members who are on both initiatices. We could
formalize a JC with those common members.
cheers

|-----Original Message-----
|From: Karl Best [mailto:karl.best@oasis-open.org]
|Sent: Thursday, March 29, 2001 2:36 PM
|To: Eve L. Maler; Orchard, David
|Cc: Simon Y. Blackwell; Security-Services (E-mail); 'Xacml-Discuss
|(E-mail)
|Subject: RE: XACML Proposal
|
|
|What Eve says is correct: The OASIS TC process does not require that TCs
|coordinate. We do, however, strongly encourage the coordination of
|technical
|work among various committees. In time this may become policy; for now I
|will simply push hard :-)
|
|The Security Services TC already has a history of coordination; it was born
|out of two competing efforts. I would like to see this healthy attitude
|continue.
|
|</karl>
|=================================================================
|Karl F. Best
|OASIS - Director, Technical Operations
|978.667.5115 x206
|karl.best@oasis-open.org  http://www.oasis-open.org
|
|
|> -----Original Message-----
|> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
|> Sent: Thursday, March 29, 2001 3:58 PM
|> To: Orchard, David
|> Cc: Simon Y. Blackwell; Security-Services (E-mail); 'Xacml-Discuss
|> (E-mail)
|> Subject: RE: XACML Proposal
|>
|>
|> 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
|>
|>
|
|
|------------------------------------------------------------------
|To unsubscribe from this elist send a message with the single word
|"unsubscribe" in the body to:
|security-services-request@lists.oasis-open.org
|