[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] [schema] notes from sub-committee meeting 22 July 02
Attached are my notes in the form of an annotated XACML schema issues list. I will remove CLOSED items after this mailing (I keep them in a separate file, in case we need to refer to them). Anne -- 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
Title: XACML schema issues
Author: Anne Anderson
Version: 1.14, 02/07/22 (yy/mm/dd)
Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.SchemaIssues.txt
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.
CLOSED: Look at Tim's new Target schema. Specified set of
matching rules. Match is between an AttributeDesignator
(into relevant area of the context) and an Attribute[Value].
Create an alternate choice in MatchType for "universal
matches".
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.
CLOSED: Add a policy assertion or policyset assertion
reference to the schema.
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.
Options:
a) Handle matching outside of the Request/Response
b) Require Request context to include a unique ID that is
also included in the Response
c) SAML response includes elements needed; handled by SAML
response constructor.
CLOSED: SAML wrapper (or other wrapper) can package Request
with Response or supply unique IDs as needed.
CLOSED: Only one resource per XACML request. If that
resource is hierarchical, then the portion of the
hierarchy for which a request is made is specified through
a "Scope" attribute.
CLOSED: One action per XACML request. No xs:list allowed.
OPEN: Anne to specify semantics for multiple subjects in a
request.
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".
CLOSED: Yes. Environment it is.
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.
[Tim] What about a federated chain of identities?
NameQualifier seems a half-hearted attempt to handle
this.
CLOSED: XACML NameQualifier corresponds to SAML
NameQualifier.
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.
CLOSED: Use ResourceDesignator.
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.
CLOSED: xs:string it is. Format is more than DataType: it
disambiguates the ResourceId.
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.
CLOSED: Not needed. Redundant, since specified in the
Request.
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>
CLOSED: use Michiharu's schema (already included in 15i).
processContents="lax" means, if have schema then validate
it; if don't have schema, then don't worry about it.
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?
CLOSED: maxOccurs=1.
34. [Michiharu] XPath Subset
http://lists.oasis-open.org/archives/xacml/200207/msg00066.html
OPEN: Complexity, especially when namespace must be
specified. For simple XPATH, context schema must be
flattened. How to limit XPATH if using a general-purpose
library. Check in policy authoring tool. Context can use
any XPATH expression, but policy is limited. Could XPATH
evaluation be done on the requester side, with just the
extracted elements be handed to the PDP? Should context
be designed without any attributes, in order to make XPATH
simpler (just element /)?
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.
CLOSED: Remove Advice from XACML. Simon will propose an
Error element schema by 7/25/02.
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:orderedOr
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: Anne to respecify the OR semantics such that only TRUE
or FALSE is returned. Daniel will also propose a
solution.
37. [Michiharu] Use of XPath with namespaces.
http://lists.oasis-open.org/archives/xacml/200207/msg00056.html
Namespace URI functions and Global Name functions. Another
option: namespace prefix in the XPATH expression, but this
needs some assumptions on the target document.
OPEN:
38. [Daniel] Split non-null-set-intersection function
http://lists.oasis-open.org/archives/xacml/200207/msg00076.html [1)]
[Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00077.html
Split non-null-set-intersection into intersection(list, list)
- returning xs:list and non_null(list), returning boolean.
OPEN:
39. [Daniel] Add floor(decimal)
http://lists.oasis-open.org/archives/xacml/200207/msg00076.html [2)]
[Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00077.html
In addition to round(decimal), floor(decimal) is probably
necessary
[Tim] "function:integer" was intended to serve as floor(decimal).
OPEN:
40. [Anne] Change XACML "Request" to "Query"?
http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [1.]
[Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00079.html
[Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html
Eve Maler suggests we change the name of "Request" to "Query"
to conform to SAML usage.
OPEN:
41. [Anne] Is a "notional" XML document for Request a good idea?
http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [2.]
[Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html
OPEN:
42. [Anne] ConditionType and ConditionIdType
http://lists.oasis-open.org/archives/xacml/200207/msg00081.html
What should we use for ConditionIdType when the ConditionType
is an Attribute or AttributeDesignator?
Should we define a new ConditionIdType that is
"function:boolean-attribute-value"?
Tim proposes "function:true" as wrapper for an Attribute or
AttributeDesignator. This conflicts with use of
"function:true" to ALWAYS return TRUE for "any" matches in
Target.
OPEN:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC