[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of 26 February XACML Focus Group
[Note: we reviewed all the 2.0 work items that have not been
explicitly dropped, and their status in indicated below. We did
not discuss all the items that have been targetted for
specifications other than XACML 2.0, such as various profiles.]
Minutes from the 26 February 2004 XACML Focus Group
Present:
Anne Anderson,
Tim Moses,
Mike McIntosh
Agenda: Continuing discussing XACML 2.0 work items
Action item: Tim will publish a draft 6 with all the stable work
items agreed to so far.
WI#7. ConditionReference
Need final consensus proposal from the proponents.
WI#9. Policies referring to hierarchical resources
Open issue on handling things like "read" in a file system
requiring "execute" permission on all elements higher in the
hierarchy. Anne will look at WS-ResourceFramework.
WI#10. Parameters for Combining Algorithms
Seems to be close to consensus here. Tim will see if enough
information to include in next draft.
WI#11. XACML Extension Points
Feb. 12 meeting suggested not having any general extension
points, but accepting specific extensions where justified.
WI#12. Environment Element in Target
Already in 2.0 draft.
WI#13. Optional Target Elements
Already in 2.0 draft.
WI#18. Obligations in Rules
http://lists.oasis-open.org/archives/xacml/200305/msg00011.html
http://lists.oasis-open.org/archives/xacml/200401/msg00062.html [Polar issues]
http://lists.oasis-open.org/archives/xacml/200402/msg00013.html [Michiharu use case]
Waiting for Polar's alternative.
WI#22. time-in-range function
Already in 2.0 draft.
WI#23. Use XQuery comparison functions for date, time, dateTime
Need update from Seth on whether progress is being made. How
long are we prepared to delay 2.0 for this?
WI#27. Version number element or attribute in an XACML policy.
Already in 2.0 draft.
WI#28. Define "current time/date/dateTime" during policy evaluation
Already in 2.0 draft.
WI#29. Policy Authority Delegation
For F2F.
WI#31. Attribute Issuer as Subject
For F2F.
WI#32. Standardize naming to specify rules for requestor's authz policy
Waiting for Frank to discuss his use case verbally.
WI#36. Check for requester authorized to ask for authz decision
For F2F.
WI#37. Multiple <AttributeValue> elements for single <Attribute> in Request
We looked these over, and agreed Rebekah has found
inconsistencies. Since they are editorial, Tim will correct
them in the next draft, and Rebekah can review the fixes.
1) ResourceAttributeDesignator (lines 2318 - 2327),
ActionAttributeDesignator( 2343 - 2352) and EnvironmentAttributeDesignator
(lines 2369 - 2378) all refer to "a bag containing all the (resource,
action, environment) attribute values that are matched by the named
(resource, action, environment) attribute.
a) I presume this text corresponds to the description of the returned bag
for an AttributeSelector as described in line 2448 - 2454?
Tim will look into this. The results for an AttributeSelector
and for an AttributeDesignator should be the same type.
b) In the section for SubjectAttributeDesignator (lines 2268 - 2310), there
is no mention of a bag returned containing the values even for a categorized
subject. Does this imply a different processing requirement for
SubjectAttributeDesignators?
No. Text should be made consistent. Tim will do.
2) Can an element be defined directly with the type AttributeDesignatorType
or was the intention that this complex type definition serve only as the
root of a type hierarchy?
Intention was only the root. AttributeDesignatorType maybe
should be made abstract. Tim will look into this.
3) Lines 2445 - 2454 define processing rules that relate to the
MustBePresent attribute of an AttributeSelector, including the required
status code. No such constraint on the required status code is listed in
lines 2264 - 2266 for AttributeDesignators. Should there mandatory status
codes specified?
Yes. The results obtained form an AttributeSelector and from
AttributeDesignators should be consistent. We should copy the
text from AttributeSelector into the text rfor AttributeDesignator.
4) Line 2707 indicates that the data type of the AttributeValue MAY be
specified by using the DataType attribute of the parent Attribute element.
However, line 2683 indicates that DataType xml attribute of an Attribute
element is mandatory. Is this a contradiction?
Line 2707 should be changed to say MUST, not may.
5) AttributeValueType. Lines 2456 - 2469 indicate that a DataType URI is a
required xml attribute required for the complex type in the xacml namespace.
Lines 2696 - 2708 indicate do not define such a required xml attribute for
the AttributeValueType in the xacml-context namespace. Lines 3448 - 2469 of
the Appendix state that an XACML <AttributeValue> element MAY contain an
instance of a structured XML data type. Lines 3524 - 3525 says "The
<AttributeValue> element SHALL represent an explict value of a primitive
type. The example shows the use of an Attribute value element as the child
of the <Apply> element. Lines 3534 - 3535 states "The
<AttributeDesignator> and <AttributeSelector> elements SHALL evaluate to a
bag of a specific primitive type. Do these different characterizations
contradict?
Note that we have two different definitions for AttributeValue;
the one in the Request Context does not have its own DataType -
it uses the the Attribute DataType element. The AttributeValue
in a Policy does have its own DataType xml attribute.
Lines 2456 - 2469 apply to AttributeValue in a Policy.
Lines 3534 - 3535 are in the appendix describing standard
functions and datatypes, so that is why A.7 says the type must be
primitive type.
6) Is it reasonable to state that a named attribute appears in the context
of Policy syntax but not Context syntax?
Tim will resolve.
7) Is the string equality requirement listed on line 2999 the string
equality function defined at line 3643?
Tim will resolve.
WI#38. Policies for the Administration of XACML Policies
For the F2F.
WI#39. Make Status in the XACML Response optional
Already in 2.0 draft.
WI#40. Define a SAML PolicyQuery and PolicyStatement
Anne has published a working draft for the SAML Profile.
WI#42. Requests asking for access to multiple elements in a hierarchical resource
This is actually different from #9. #9 needs to say how, in a
policy, a condition can be made to apply to an entire subtree
in a hierarchy, rather than having to spell out
WI#43. Examine interactions between approved work items
Open.
WI#45. Fix AttributeAssignment example in Section 4.2.4.3 (Rule 3)
Already in 2.0 draft.
WI#46. Status detail for missing attributes
Waiting for Seth to produce schema for specifying a missing
attribute.
WI#47. New SAML Authorization Decision Query/Response using XACML
Being dealt with in the SAML Profile document.
WI#48. PAP Interface to a PDP/PRP
For XACML Interface Definitions Specification. Tim will get
to this soon.
WI#50. Fix obligations erratum: fulfilled by PDP
Already in 2.0 draft. CLOSED.
WI#51. Clarify obligations: "fulfill" vs. "understand"
Already in 2.0 draft.
WI#52. New section explaining not backwards compatible and listing changes
Needs to wait for all changes to be made.
WI#53. Drop <Function> element
Will this change with the new reference proposals? Tim has
not yet clarified the explanation in the current draft.
WI#54. Is resource-id required?
Needs to be incorporated into the next draft. This has been
resolved by a vote on 8 Jan to make resource-id optional.
WI#55. Converge SAML and XACML Attribute schema definitions
Some of this is going into the XACML Profile; rest depends on
continued conversation with SAML people.
WI#56. Should Request Context be optional (non-normative)
Hal's detailed text was accepted 8 Jan 2004. This is in Tim's
draft of Draft 6.
WI#58. Standard hierarchy schemas
Anne still working on this. Can be in a separate profile, so
2.0 need not wait for this.
WI#59. Define standard "role" subject attribute
12 Feb 2004 FG recommended including in next draft.
26 Feb 2004 FG recommends putting this into the next version
of the RBAC profile.
WI#60. Define standard "purpose" attributes
Tim has published a draft Privacy Profile as a contribution.
The TC needs to agree to make this a Working Draft.
--
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] | [List Home]