RE: XACML Proposal

[Karl Best <karl.best@oasis-open.org>]

OASIS agrees with this position. The two committees must explicitly work
together to produce coordinated results.

From a political/publicity perspective, we must be able to explain to the
public why there are two groups and how they work together. But more
importantly, from a technical perspective the specifications must work
together. We're working on two pieces of a larger puzzle; if the pieces we
are working on don't even fit together how can we expect any of the other
pieces to fit?

</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: Orchard, David [mailto:dorchard@jamcracker.com]
Sent: Thursday, March 29, 2001 2:41 PM
To: Simon Y. Blackwell; Security-Services (E-mail)
Cc: 'Xacml-Discuss (E-mail)
Subject: RE: XACML Proposal


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.
-----Original Message-----
From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
Sent: Wednesday, March 28, 2001 1:42 PM
To: Security-Services (E-mail)
Cc: 'Xacml-Discuss (E-mail)
Subject: XACML Proposal


After some preliminary discussion with Eve L. Maler I am posting this ballot
to the Security Services list. Members of the XACML discussion list need not
respond since they have already responded to an internal ballot. The results
of the internal ballot so far are 10 in favor of the submission as written,
1 with an inconsequential change that is reflected below. 8 people favor a
separate TC, 2 prefer a subcommittee, and 1 has no preference.
The XACML discussion list is about to propose formation of a TC to OASIS.
Per previous agreement by the XACML list organizers with the members of
Security Services TC the Security Services list is being informed beforehand
in order to help determine if the proposed activity should properly be a
sub-group within Security Services. Please reply to the poster of this
e-mail with you comments by April 1st so that it can be discussed on the
April 3rd teleconference.
[ ] Agree with the proposal as written for submission to OASIS for TC
formation
[ ] Agree with the proposal with minor or inconsequential changes as noted
prior to submission to OASIS for TC formation
[ ] Agree with the proposal as written for creation of a subcommittee within
Security Services
[ ] Agree with the proposal with minor or inconsequential changes for
creation of a subcommittee within Security Services
[ ] Proposal should not be submitted and work should be suspended
[ ] More extensive discussion is required prior to a decision
[ ] Please make me a member of the TC or subcommittee mailing list if one is
formed.
Name of TC: XACML
Statement of purpose: The purpose of the XACML TC is to define a core schema
and corresponding namespace for the expression of authorization policies in
XML against objects that themselves are identified in XML. The schema will
be capable of representing the functionality of most policy representation
mechanisms available at the time of adoption. It is also intended that the
schema be extensible in order to address that functionality not included,
custom application requirements, or features not yet envisioned. Issues to
be addressed include, but are not limited to: fine grained control, the
nature of the requestor, the protocol over which the request is made,
content introspection, the types of activities authorized. The group intends
to work closely with security services (SAML) to ensure work is not
duplicated and adoption is as simple as possible.
List of deliverables: statement of scope (what's in and what's out),
glossary, bibliography (including references to other XML initiatives, e.g.
SAML), joint statement with SAML about the intersections of work, use cases,
detailed requirements, proposed standard, model examples for "native" and
non-native XML targets of control, reference implementation executables.
Simon Y. Blackwell
CTO
Psoom, Inc.
Voice & Fax: 415-762-9787