OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


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



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


Powered by eList eXpress LLC