[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XACML Proposal
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC