[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] [schema] Schema Subcommittee Minutes 8 July 2002
Quick question: Do we want to address the issue of defining legal type conversions as part of the standard/policy? Or just leave it open - so that any PDP can decide for itself if it can convert between particular data types?
(So is that you can declare that RU:Boolean, expressed as "??"/"???", can be used as an argument of OR(Boolean/Boolean), and that the PDP that does not provide this conversion, does not enforce the policy..)
-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: Monday, July 08, 2002 9:19 AM
To: XACML TC
Subject: [xacml] [schema] Schema Subcommittee Minutes 8 July 2002
Minutes of XACML TC Schema Subcommittee Meeting 8 July 2002
Present: Michiharu, Carlisle, Tim, Anne, Daniel, Hal
RECOMMENDATIONS:
1. Functions are declared in tables, which specify types of
arguments and return values. Data types are specified via
URI.
2. In the future, we intend to define an XML interchange format
for function declarations. Interchange format will not be
part of XACML 1.0 (although draft may be available). When an
interchange format is available, we will define a mapping
from the information in our tables to the interchange
format.
3. Functions are referenced in a policy as follows:
<function FunctionName="<functionURI"/>
(at least for v15).
4. Custom functions need to be spelled out in similar tables
and assigned URIs by which they are referenced.
5. Legal rules must return a xs:Boolean.
(v15 proposal: Current "Predicate" replaced by "Function"
with facet fixed to return "xs:Boolean".)
6. For our standard functions, we will define XACML URIs that
correspond to a subset of the XPATH 2.0 draft URIs. We will
retain the XPATH 2.0 data type URIs for the arguments and
return values of these functions.
7. Michiharu will propose this subset.
DELIVERABLES:
12 July 2002: updated schema
19 July 2002: updated document
? : Michiharu proposes subset of XPATH 2.0 operators.
DETAILED MINUTES
================
Daniel: reviewed his proposal
(http://lists.oasis-open.org/archives/xacml/200206/msg00116.html)
for "Constraint language data types and operations"
Tim: summed up as define some dozens of declarations in XML
documents that are exchanged along with the policy. The
policy itself does not include the declarations. PAP and PDP
must agree on the declarations used.
Version 14 captured some of this information in
plain-language tables. Daniel proposes capturing some of
this in XML documents.
Carlisle: Do we need to capture the declarations in an XML document, an
XML schema extension, or just in text tables?
Anne:
Standard operations: can be defined in text.
Non-standard operations: XML declaration of some type
required to do type validation of the policy.
Daniel: As long as allowing for non-standard declarations,
might as well define standard ones that way also. Allows
versioning of declarations.
Tim: Why is XML preferable to XML-schema for this declaration?
Daniel: Ease of implementation. See Item 4c in proposal.
Tim: Tables just provide model, not validatable policy. XML
declaration requires writing an XACML policy validator,
but then allows validation against a declaration. XML
schema extension does not provide any help in validation,
other than that tags match.
Tim: Assuming we will use large numbers of non-standard
functions right off the bat is a change from what we have
been assuming.
Anne: J2SE policies will require these.
AGREEMENT: for any operator, knowing the return type and the
expected input types is very important.
Daniel: XML document enforces providing the required
information about valid conversions and types.
Tim: no strong objection to defining functions in XML format.
Objections: verbose. Strong objection to having a
separate name for each type combination.
Daniel: problem with multiple argument types in case where an
input value could be converted to more than one valid
argument type.
Michiharu: XPATH 2.0 defines generic operators, but they are
data-type dependent. Mapping table between each operator
and types and conversions. We are trying to define such a
mapping table. What we are trying to do overlaps with
what XPATH 2.0 is doing in their Appendix B.2.
http://www.w3.org/TR/xpath20/
Recommendation: incorporate XPATH 2.0 functions in XACML.
Does not imply have to incorporate all of XPATH 2.0.
We would incorporate a subset, but that would be in
line with XPATH 2.0.
Daniel: how do you define extensions to this table, e.g. to
use GPS time?
Michiharu: don't know whether 2.0 supports user-defined
operations.
Michiharu: time-frame for XPATH 2.0 unfortunately not in line
with XACML 1.0. Desirable to allow XACML 1.0 to
incorporate XPATH 2.0 in the future.
Anne: proposal: define XACML 1.0 operators to be in line with
subset of current
Tim: interchange format for function definitions
a. Is it in our scope?
b. If so, define XML schema for this interchange format
c. Can have a table in English language and description of
how to map our descriptions into the interchange
format.
Anne: interchange format can be defined independently of our
XACML 1.0 work. XACML 1.0 can use a table. In future, we
can define mapping from the table to the interchange
format.
Tim: choose all the XPATH 2.0 types except for the last 10-12
that use node types.
Michiharu: too many for first version. Duration is
difficult, so also omit durations.
Anne: omit all "?", "(missing)", "node" types, durations.
Anne Anderson, scribe
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC