[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of XACML TC Meeting 12 June 2003
Minutes of XACML TC Meeting 12 June 2003
Present: Anne Anderson (scribe), Michiharu Kudo, Polar Humenn,
Hal Lockhart, Carlisle Adams, Simon Godik, Daniel Engovatov, Tim
Moses
This represents quorum.
1. Minutes from May 29 TC meeting:
http://lists.oasis-open.org/archives/xacml/200305/msg00054.html
APPROVED.
2. Request to put links to TC Work Item docs on first page of web
page.
o DSIG
o RBAC
o WSPL Use Cases
o XACML Webservices
o Errata
APPROVED. Web site maintainer to see what works best. For
example, may be able to have a link to "working drafts".
Current repository is a mish-mash of all types of documents,
so it is not serving the purpose.
3. New web site maintainer
Michiharu Kudo would like to be replaced. Anne volunteered,
subject to her manager's approval. Michiharu will communicate
with Anne about how to work with the web site.
4. Update on RBAC discussion from Focus Group 9 June 2003
Main points in reviewing APIs in the proposed ANSI standard at
http://csrc.nist.gov/rbac/rbac-std-ncits.pdf:
o CheckAccess is the main API that would be handled by an
XACML PDP.
o Issue with APIs that retrieve all permissions associated
with a User, Role, or Session. XACML does not define how to
do this now. WSPL work shows it is hard. Need not be an
interface to the XACML PDP. Could be done by a separate
service, such as a "policy analysis service".
o Proposed ANSI std RBAC APIs too narrow: "AddUser",
etc. would not be implemented in this form by most systems.
o "Permission" too narrow
Mouli (NIST) has action item to describe simpler proposal for
supporting hierarchical RBAC than is in current draft XACML
RBAC Profile at
http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/2405/wd-xacml-rbac-profile-01.doc
Next meeting will depend on e-mail activity. Anne will
schedule a meeting if things are slowing down.
5. Discussion of Errata Document
http://lists.oasis-open.org/archives/xacml/200306/msg00001.html
Focus Group 5 June 2003 reviewed document and made
recommendations. These recommendations were reviewed and
voted on by the TC as follows.
-3.12 <Status> element MAY: include action and environment
attributes.
APPROVED.
-3.13 <Status> element MUST NOT list action or environment
attributes.
APPROVED.
-3.14 <AttributeValue> occurrence is inconsistent.
APPROVED, along with recommendation to also remove
minOccurs="0" from line 2644 in spec to agree with schema.
-3.15 Semantics of the <AttributeDesignator> with MustBePresent
attribute set to "true" is unclear when <Attribute> does not
contain <AttributeValue>
VOTED TO DROP AS ERRATUM. Close reading of specification and
schema is consistent and as intended: every <Attribute> MUST
contain an <AttributeValue> since it is not optional, although
the <AttributeValue> may contain no data (empty value). An
empty <AttributeValue> where DataType is inconsistent with an
empty value is schema invalid. Where an empty
<AttributeValue> is consistent with the specified DataType,
then the bag will contain one member for each such "empty"
value (it will NOT be an "empty bag"), and there is no
conflict with "MustBePresent", since the Attribute is present,
even if the values are "empty values".
-3.16 MustBePresent attribute semantics for the
<AttributeSelector> element.
APPROVED, using status of "processing-error", not
"missing-attribute" in the place where a question mark occurs.
-3.17 Unclear how to convert nodes from XPath expression into
bag of attributes.
APPROVED Michiharu's proposed solution posted in
http://lists.oasis-open.org/archives/xacml/200306/msg00016.html
Solution follows:
This is the draft resolution for errata 3.17: Unclear how to
convert nodes from XPath expression into bag of
attributes. The following resolution explicitly states that we
deals with only simpler cases such as a text node and an
attribute value which are obvious how to convert those values
to literals. It does not deal with a node or a set of nodes
which is much harder to handle.
Lines 2409--2413 should be replaced with the following:
Each selected node by the specified XPath expression MUST be
either a text node, an attribute node, a processing
instruction node, or a comment node. The string representation
of the value of each selected node MUST be converted to an
attribute value of the specified data type, and the result of
the AttributeSelector is the bag of the attribute values
generated from all the selected nodes.
If the selected node is different from the node types listed
above, then the result of that policy SHALL be "Indeterminate"
with a StatusCode value of
"urn:oasis:names:tc:xacml:1.0:status:syntax-error".
DISCUSSION:
Hal: can this error be detected at policy creation time?
Michiharu: no, this will be a runtime error.
-3.7 Obligations for the policy.
VOTED TO DROP AS ERRATUM: Satoshi decided 7.11 was clear on
closer reading:
http://lists.oasis-open.org/archives/xacml/200306/msg00035.html
-3.9 <XPathVersion> element
FOCUS GROUP: Simon will look for discussion of this on the
list. No one can remember what the disposition was.
STILL OPEN.
-Several new errata reported to Michiharu by Jim Fuller, but not
put on xacml-comment. Michiharu will forward to xacml-comment.
ACTION ITEM [Simon]: add these to the errata list as potential errata for
discussion.
-Other items in the errata list have probably already been
disposed, but Simon has not yet found the relevant e-mails.
ACTION ITEM [ALL]: find any e-mails or minutes that contained
resolutions to remaining errata.
-Remaining errata to be subject of discussion at next Focus
Group.
6. 1.1 Work Item: Adding Environment to Target
DISCUSSION:
Simon: posted "Indexing hints" as an alternative to this in
http://lists.oasis-open.org/archives/xacml/200306/msg00033.html:
A simple alternative would be to provide indexing hints in the
Policy element. We can define IndexingHints element as a child
of the Policy element. It would contain a sequence of attribute
designators for indexing.
<xs:complexType name="IndexingHintsType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="xacml:SubjectAttributeDesignator"/>
<xs:element ref="xacml:ResourceAttributeDesignator"/>
<xs:element ref="xacml:ActionAttributeDesignator"/>
<xs:element ref="xacml:EnvironmentAttributeDesignator"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<Policy ...>
<IndexingHints>
<SubjectAttributeDesignator AttributeId="group" .../>
<ActionAttributeDesignator AttributeId="read" .../>
<EnvironmentAttributeDesignator AttributeId="purpose" .../>
</IndexingHints>
</Policy>
If rule contains indexable expression on an attribute specified
in the indexing hints, rule MAY be indexed. Indexing rules is
not a MUST, ie if xacml processor does not index rules it is
still compliant (but not very fast) processor.
Michiharu: privacy policy has "purpose" axis, which is
different from Subject, Resource, or Action. Would use this
in Environment, and would like to index on it. This is a
specific use case for indexing on environmental attributes.
Michiharu: Environment in Target would be optional element
for backwards compatibility.
Anne: Nice if other elements in Target were also made optional!
This item to be discussed further at Focus Group on 19 June
2003.
7. Election of new co-chair and secretary
Carlisle leaving Entrust for academic career: joining U. of
Ottawa 1 August 2003. Will probably take out individual
membership and continue contact with XACML, but will be gone
all summer.
Hal wants another co-chair.
Plan: Accept nominations by e-mail (including self-nominations),
hold vote at 26 June 2003 TC Meeting.
Secretary's main job is membership. Minutes have been handled
on a rotating basis. Hal says he can do the membership duties
if no other volunteer arises.
8. WSPL update from Tim.
Discussion of document attached to
http://lists.oasis-open.org/archives/xacml/200306/msg00030.html
(WSDL and SOAP bindings for WSPL).
3 problems to solve in WSPL
1. How to combine policies: good proposal exists.
2. How to convey policies via WSDL, SOAP, etc. Topic for
today.
3. How to convert a combined policy into instructions for
creating a conformant message. Future topic.
SOAP: consumer might have policy associated with response to
its request, so might want to include this policy in a SOAP
header.
WSDL is a description of a service, so policy information
belongs here. Relevant objects:
- Port: equivalent to an object. Concrete instance of a
class. Has name, class. Equivalent of class is "portType":
not a specific instance, but a description of a class to
which ports can conform.
- portTypes have operations (like OO methods)
- Message: parameters of a method invocation
o Input (msg that calls service)
o Output (msg response from service)
o Fault (msg you get if method you invoke did not implement
correctly)
Different types of policies seem to apply most closely to
different objects: some to ports, some to operations, or
portType message. Trust policies might apply to portType, for
example.
Frank Siebenlist originally suggested policy to be targetted
at a portType, rather than at a port. "I need instance of
this portType. Have located an instance. Need to configure
myself to use that port: do DNS lookup to get name, etc., get
policies." Policy may include subpolicies targetted to
particular messages or operations.
Frank Siebenlist now says better to associate policies with
concrete ports instead of portType. Polar says CORBA also
decided to attach policies to object instance, not interface.
CORBA also has concept of "domains", which are like WSDL
"service". No current proposal to attach policies to
"services": collection of ports that define a service. Not
grouped just because they have a common policy.
Tim wants feedback on proposal to associate policies with
concrete ports rather than with portType.
Next topic: names assigned by a consumer may be different from
names assigned by a provider. Consequence is that consumer
must use names chosen by service provider and published in
WSDL. If use same service from multiple providers, then
client policy must be modified for each to use appropriate
names.
Next point: PolicySet targetted at portType should identify
portType in its Target. Issuer of SAML assertion should be
controller of namespace for portType.
Auditing: Two types: who created the request (Tim not
concerned about), and confirming that request was processed
under appropriate policy (take time, portType submitted to,
find policy appropriate for portType at that time; should see
link to policy available from issuer of SAML assertion).
Tim really wants feedback on everything. No choices
completely obvious.
Anne: Would be helpful if Tim posted an e-mail containing
outstanding issues.
9. Simon has submitted proposal to use XML Ids instead of
Condition references, etc.
Adjourned at 11:33am.
NEXT MEETINGS:
-Focus Group on 19th: Errata list.
-TC Call on 26th.
--
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]