MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xacml] Summary of the discussion on Function model
This is a summary of the discussion among Daniel, Polar and me. I could not
list all the issues we discussed.
Daniel and Polar: please correct me if I misunderstood.
============================================
A. Changes of the latest function draft v0.9 from v0.8
- Higher-order sequence function is added
B. Problems of the previous function draft v0.8)
- Sequence but unordered set
- The semantics of function:string-equal in MatchId corresponds to the
semantics of function:string-member-of
- Comparison on multiple data (sequence or set) is limited to string data
type
C. Three ideas on comparison on sequences
Daniel: Sequence handled by each function
Polar: Sequence handled by higher-order function
Michiharu: Sequence is handled in a way used by XPath 2.0 data model
D. Issues of draft v0.8
0042: In ver 0.8, string comparison (set against a value) is differently
specified in MatchId from in Apply
0043: Should we support ordered set (sequence) type or unordered set?
0044: Should we distinguish sequence of data from singleton data?
0045: Should we support higher-order function?
0046: Should we support basic sequence comparison model?
E. Position
====
0042: In ver 0.8, string comparison (set against a value) is differently
specified in MatchId from Apply
Attribute selector returns a sequence (e.g. "aaa" and "bbb"). In
ResourceMatch, function:string-equal is used
<ResourceMatch MatchId="function:string-equal">
<AttributeSelector RequestContextPath="/a/b/c/text()">
<AttributeValue>bbb</AttributeValue>
</ResourceMatch>
In Apply, function:string-member-of is used
<Apply FunctionId="function:string-member-of">
<AttributeValue>bbb</AttributeValue>
<AttributeSelector RequestContextPath="/a/b/c/text()">
</Apply>
ver0.9: - ???
Daniel: - ???
Polar: - Higher-order function introduced in ver 0.9 will resolve this
inconsistency.
??? for <ResourceMatch>
<Apply FunctionId="function:any-of-each">
<Function FunctionId="function:string-equal"/>
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</Apply>
Michiharu:
- Comparison model on sequence data will resolve this inconsistency.
<ResourceMatch MatchId="function:string-equal">
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</ResourceMatch>
<Apply FunctionId="function:string-equal" ComparisonBase="Each">
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</Apply>
====
0043: Should we support ordered set (sequence) type or unordered set?
ver0.9: - Sequence is supported but it is unordered (?)
- Some value may be repeated
Daniel: - unordered set because it is a subset of ordered set
- small coverage is good for initial mandatory data model
Polar: - sequence
Michiharu:
-sequence because it is a superset of unordered set
-unordered set is supported as a subset of ordered set
-XML document (XACML Request Context) supports sequence
-application that uses unordered set of data is also supported using
function that is not sensitive on sequence.
====
0044: Should we distinguish sequence of data from singleton data?
ver 0.9: - ???
Daniel: - Singleton data should be handled as a sequence which length
is one.
Polar: - Singleton data should be distinguished from singleton data
Michiharu:
- Singleton data should be handled as a sequence which length is one.
====
0045: Should we support higher-order function?
ver 0.9: - Supported
Daniel: - Should not be supported
Polar: - Can be supported if the idea of comparison base is introduced
Michiharu:
- Generic higher-order function is not necessary
- XPath 2.0-based comparison should be supported
(http://lists.oasis-open.org/archives/xacml/200209/msg00071.html)
====
0046: Should we support basic sequence comparison model?
ver 0.9: - Supported using higher-order function
Daniel: - It can be supported using model of ver 0.8
Polar: - Sequence handling in ver 0.8 is not consistent
Michiharu:
- Should be supported but more limited way (XPath 2.0 model) would be
desirable
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC