[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] [schema] updated open schema sub-committee issues
3. [Anne] Optional <Target> in Rule (since often same as Policy)
http://lists.oasis-open.org/archives/xacml/200207/msg00011.html
Options:
a. Optional <Target> in Rule (already optional in 15g):
semantics ::= "match"
b. Define <Target> to be a choice
1. urn:oasis:...:anyTarget, or
2. <Subject>...</Subject>,<Resource>...</Resource>,...
and use 1. for this case.
c. Use <Subject>urn:oasis:...:any</Subject>,
<Resource>urn:oasis:...:any</Resource> for this case.
CLOSED: it is optional in v15. Semantics are that a Rule
"inherits" the Target of the Policy that references or
includes it if the Rule has no Target of its own.
16. [Anne] Target matching syntax and semantics
http://lists.oasis-open.org/archives/xacml/200207/msg00018.html
[Michiharu response]
http://lists.oasis-open.org/archives/xacml/200207/msg00032.html
[Michiharu new response]
http://lists.oasis-open.org/archives/xacml/200207/msg00050.html
[Tim] new Target schema
http://lists.oasis-open.org/archives/xacml/200207/msg00055.html
[Michiharu]
http://lists.oasis-open.org/archives/xacml/200207/msg00061.html
[Daniel]
http://lists.oasis-open.org/archives/xacml/200207/msg00062.html
CLOSED: In a single AttributeDesignator in a Target element,
at least one returned node must match the target value. If a
Target element includes more than one AttributeDesignator,
then each AttributeDesignator must have at least one returned
node that matches its target value.
OPEN: We will study Michiharu's new response and decide on
its issues on 7/22/02.
OPEN: Look at Tim's new Target schema.
21. [Anne] {PolicySet|Policy|Rule}Designator issue
http://lists.oasis-open.org/archives/xacml/200207/msg00045.html
CLOSED: Designators are not intended to tell *how* to retrieve
the specified PolicySet, Policy, or Rule, merely to
identify *which* is to be retrieved by Id. The
PolicySetDesignator and PolicyDesignator types do need to
be a CHOICE rather than a SEQUENCE.
OPEN: How about Assertion by reference?
26. [Tim] Repeat Subject and Actions in the Response?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [1.]
Should we repeat Subject and Actions in the Response? If
there are multiple Subjects and Actions in the Request, will
it always be clear which Subject was permitted which Action?
[Daniel] I would think yes - repeat it. It also facilitates
asynchronous protocols.
[Michiharu] Both the subject and the action information in
the response context are redundant for the application which
holds the request context data. For simplicity, we don't need
those elements in the response context. Besides, it might be
useful to have some placeholder element in the response
context where each application can put any information.
OPEN:
27. [Tim] Call "Other" "Environment"?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [2.]
Should we call "Other" "Environment"? The term "Other"
doesn't convey much information to the reader.
[Daniel] Agree.
[Michiharu] I prefer "Environment".
OPEN:
28. [Tim] Purpose of Qualifier attribute in SubjectIdType
definition?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [3.]
What is the purpose of the Qualifier attribute in the
SubjectIdType definition?
[Michiharu] I thought that NameQualifier just corresponds to
SAML's NameQualifier.
OPEN:
29. [Tim] Policy uses Designator; context uses
"ResourceSpecifier"
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [4.]
In Policy.xsd we use the term "Designator" (policy, rule,
attribute). In Context.xsd we use the term
"ResourceSpecifier". Is this inconsistent?
[Michiharu] No preference.
OPEN:
30. [Tim] ResourceSpecifier ResourceId from anyURI to string?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [5.]
In ResourceSpecifier the ResourceId is of type xs:anyURI.
Should this not be xs:string? Otherwise, non-xml resource
instances cannot be named.
[Daniel] Absolutely. I feel, that in general we XACML is too
concentrated on this particular resource model.
[Michiharu] xs:string is fine with me.
OPEN:
31. [Tim] Scope needed in Response?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [6.]
The Scope element is in both the Request and the Response.
Do we need it in the Response? Will one ever want to say the
Request is permitted for children, but not for descendants,
etc.?
[Daniel] It should not, probably, be included in
Response. Response is only for the resource mentioned in the
response. If a separate response for descendants is needed,
it should be provided separately - for all resources in
scope.
If B is descendant of A, and you make a request
for A+immediate children - how would you pick the scope for
Bin response? If it is B+children - you are getting
information you did not ask for. It is inconsistent..
[Michiharu] Scope may not be needed in response.
OPEN:
32. [Michiharu] ResourceContent schema
http://lists.oasis-open.org/archives/xacml/200207/msg00059.html
I think that ResourceContent element should be the following to
allow any (element, attribute, and namespace) items below it.
<xs:element name="ResourceContent" type="ResourceContentType" />
<xs:complexType name="ResourceContentType">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"
processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents
="lax"></xs:anyAttribute>
</xs:complexType>
OPEN:
33. [Anne] ConditionType error?
http://lists.oasis-open.org/archives/xacml/200207/msg00064.html
A ConditionType is currently defined as a restriction of a
FunctionType. The ohly restriction is that DataType must be
xs:boolean.
1. Shouldn't the maxOccurs="unbounded" be changed to
maxOccurs="1"? How would you deal with a Condition comprised
of more than one Function, Attribute, or AttributeDesignator?
2. Assuming 1, can a restriction change the "maxOccurs" of a
choice?
OPEN:
34. [Michiharu] XPath Subset
http://lists.oasis-open.org/archives/xacml/200207/msg00066.html
OPEN:
35. [Anne] Advice present on Permit or Deny?
http://lists.oasis-open.org/archives/xacml/200207/msg00067.html
Can a PDP return Advice in a Decision that is Permit or Deny?
or just in a Decision that is Indeterminate?
[Bill] my understanding is there is no guarantee that it will
be acted upon (in contrast to an Obligation), but it's
existence is valid for any Result.
OPEN:
36. [Anne] attribute references and indeterminate results
http://lists.oasis-open.org/archives/xacml/200207/msg00069.html
http://lists.oasis-open.org/archives/xacml/200207/msg00071.html
On further reflection, I think the definition of the
semantics of the function being used for OR should determine
whether all attribute references must be resolved or not.
Since retrieving attributes can be very expensive, I propose
the following semantics for the two "standard" OR functions:
urn:oasis:names:tc:XACML:0.15g:operators:or
Operands may be evaluated in any order. Evaluation continues
until either one operand returns TRUE, or until all operands
have been evaluated. Once any operand has been evaluated
TRUE, no additional operands are evaluated.
If any evaluated operand returns TRUE, then the result of the
function is TRUE.
If all operands are evaluated, and none of them evaluates to
TRUE, then, if ANY operand evaluated to INDETERMINATE, the
function returns INDETERMINATE. If ALL operands evaluated to
FALSE, then the function returns FALSE.
urn:oasis:names:tc:XACML:0.15g:operators:or
Operands must be evaluated in the order specified. As long as
evaluated operands return a result of FALSE, evaluation
continues.
If an evaluated operand returns TRUE, then the function
returns TRUE and no additional operand evaluations are done.
If an evaluated operand returns INDETERMINATE, then the
function returns INDETERMINATE. In this case, additional
operands MAY be evaluated in order to provide information for
inclusion in Advice, but such additional evaluations do not
affect the result of the function.
Similarly, combining algorithms must specify any requirements
regarding the order in which rules/policies/sets are evaluated,
whether all rules/policies/sets MUST be evaluated, and the
semantics of any evaluated rule/policy/set returning
INDETERMINATE.
OPEN:
37. [Michiharu] Use of XPath with namespaces.
http://lists.oasis-open.org/archives/xacml/200207/msg00056.html
OPEN:
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC