[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Committee Specification vote/Updated Change Requests
The current list of Voting Members from the XACML TC Web Page,
along with current indications of whether people plan to attend
are:
Voting Members
=======================================
Y Ken Yagen, Crosslogix
Y Daniel Engovatov, Crosslogix
Hal Lockhart, Entegrity
Y Carlisle Adams, Entrust
Y Tim Moses, Entrust
Y Don Flinn, Hitachi
Y Konstantin Beznosov, Hitachi
Y Michiharu Kudoh, IBM
Steve Anderson, OpenNetwork
Simon Godik, Overxeer
Y Bill Parducci, Overxeer
Y Polar Humenn, Self
Suresh Damodaran, Sterling Commerce
Y Anne Anderson, Sun Microsystems
N/A Piras Vilandai Thiyatarajan, Sun Microsystems
Y Gerald Brose, Xtradyne
Piras resigned, so he should not be counted. Simon and Hal
probably just have not had a chance to respond yet - I can't
imagine they would not be on this call :-)
But, even without Simon and Hal, we have 11 out of 15 members who
have positively indicated that they WILL be present. So unless
we get some unexpected NO votes, I think we could vote for
Committee Specification on 7 November as long as we can resolve
the remaining issues in time for Simon and Tim to issue the
"Final Draft" by close of business on Wednesday.
Attached is a new Change Requests list, containing only the
unresolved Change Requests. A couple of these we probably don't
have to resolve before public review. But I want everyone to be
aware of what remains.
In particular, could people respond to the two proposed
resolutions to "0162: [Polar] [Schema/Text Change] Subjects",
since that is the immediate sticking point.
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: Change Requests Set 5
Author: Anne Anderson
Version: 1.2, 02/11/05 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests5.txt
This file contains all Change Requests not fully resolved as of 5
November 2002. See
http://lists.oasis-open.org/archives/xacml/200210/msg00214.html
and
http://lists.oasis-open.org/archives/xacml/200211/msg00029.html
for previous Change Requests against v0.18c.doc that have been
resolved.
Includes e-mail up through
http://lists.oasis-open.org/archives/xacml/200211/msg00067.html
=============================================================
CHANGE REQUESTS
1.SUMMARY
=========
1.1 ACTION ITEMS
================
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
ACTION ITEM: [Polar] Update RESOLUTION text based on resolution to CR#0146
1.2 UNRESOLVED
==============
Note: 92, 156, 154, and 162 are inter-twined.
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
STATUS: UNRESOLVED. Waiting for CR#0146(11/4) See RESOLUTION.
0146: [Polar] CR 144: function "present" needs to be fixed.
STATUS: UNRESOLVED (11/4). Need semantics in QualifiedSubjectAttributeDesignator.
0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere
STATUS: UNRESOLVED. See partial RESOLUTION and OPEN ISSUE (NQ 11/4)
0156: [Seth Proctor] ObligationType
STATUS: UNRESOLVED
0157: [Steve Hanna] Glitch in moving from decimal to double
STATUS: UNRESOLVED
0162: [Polar] [Schema/Text Change] Subjects
STATUS: UNRESOLVED.
1.3 RESOLVED IN SUBCOMMITTEE, BUT NEED QUORUM VOTE
==================================================
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). See RESOLUTION.
0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). Use xs:string" in both places.
0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See RESOLUTION.
0158: [Simon] [Schema Change] Redefine <AttributeValueType>
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4)
0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn"
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
1.4 RESOLVED
============
None
=========================================================================
2. DETAILS
=========================================================================
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
ACTION ITEM: [Polar] Update RESOLUTION text based on resolution to CR#0146
STATUS: UNRESOLVED. Waiting for CR#0146(11/4) See RESOLUTION.
SEE ALSO: CR#0146
RESOLUTION:
This draft resolution was accepted in general (Q 10/31), but it
needs to be updated based on the resolution to CR#0146:
- Impact of MustBePresent XML attribute
- Impact of missing attributes in a given <Subject> block in
evaluating QualifiedSubjectAttributeDesignator.
TEXT LOCATION: Section 7.9 "Attributes" (v0.18e.doc)
TEXT CHANGE: Replace current 7.9 with following:
[I have updated following with section#'s from v0.18e.doc. Tim
has already incorporated much of this. -Anne]
7.9 Attributes
Attributes are specified in the request context and are
referred to in the policy by the subject, resource, action,
and environment attribute designators or selectors. Each
context attribute specifies an AttributeId and a DataType.
Each attribute desigator specifies an AttributeId and
DataType. Attribute designators SHALL match attributes by
using string equality on both the AttributeId and DataType
values. Each attribute selector specifies a DataType and an
XPath expression. Attribute selectors SHALL match attributes
by using the XPath expression and string equality on the
DataType values.
7.9.1 Attribute Retrieval
The PDP SHALL retrieve the values of attributes that match
the particular attribute designator or attribute selector and
form them into a bag of values with the specified
DataType. If no attributes from the request context match,
the attribute shall be considered missing, and an empty bag
is said to be retrieved.
7.9.2 Missing Attributes
The PDP SHALL consider an attribute as missing if it
evaluates an expression that requires at least one value to
be present from an attribute designator or selector. In this
case, the expression evaluates to "indeterminate". The PDP
may carry the missing attribute upward in its indeterminate
value in accordance with the XACML evaluation strategy of the
encompassing expressions, rules, policies, and policy
sets. If the PDP evaluates its policy or policy set to
Indeterminate with a missing attribute, the PDP MAY list the
AttributeId and DataType of that attribute in the result as
described in Section 7.10 "Authorization decision". However,
the PDP MAY choose not to issue such information due to
security concerns.
DISCUSSION:
[Seth]
Given the original text quoted above, an AD/AS will always
return a bag, which is always an error to most of the standard
functions, unless a bag with only one element is considered to
be the same as a single instance of just the element inside the
bag. The text change clarifies this.
Long discussion questioning rejection of resolution#2. Simon
clarified intent of the TC as follows:
1) Must wrap an AttributeDesignator with *-one-and-only
function to convert a bag into a single value, or else must
use AnyOf higher-order function.
2) Yes, the TC considered the "simplicity" of "implicit" type
conversion, but felt type consistency was more important.
There may be a performance overhead, but implementations
must deal with this.
3) if new type is defined every type-* function must be
defined as well
Polar provided following example of use "anyOf":
<Apply FunctionId="function:AnyOf">
<Function FunctionId="function:string-equal">
<AttributeValue Datatype="....#string">Hello World</AttributeValue>
<AttributeDesignator ....../>
</Apply>
This structure explictly states that if indeed the
AttributeDesignator returns more than one value, it is your
*explicit intent* that the boolean is true for any of the
returned values.
[Polar, responding to Daniel]
> In this particular example, *-is-in can be used as well.
The any-of must take a function that has the type: (a -> a ->
Boolean)
The type of *-is-in is ( a -> [a] -> Boolean), where a is a
primitive type, such as the type of function:string-is-in is:
(String -> [String] -> Boolean).
An application of string-is-in would be:
<Apply FunctionId="function:string-is-in">
<AttributeValue DataType="....#string">Hello World<AttributeValue>
<AttributeDesignator ....../>
</Apply>
[Polar, responding to Simon]
> functions that do not take attribute bags as arguments do not
> care about empty bags.
Untrue. An or function, for instance, is supposed to go through
a list of inputs until it finds a true value. If one of those
inputs fails to find any values, and the MustBePresent
attribute is false, then an empty bag is returned. This is done
precisely so that the function may skip over that input and
continue on (whereas it might choose to do something different
in an error case). Functions that do not take attribute bags as
arguments may still need to recognize the special case of an
empty bag.
[Seth, responding to Polar] Yes, I understand how anyOf is
used, but it means that you can't nest Apply blocks that have
functions that expect single values. Ie, in the example you
give
> <Apply FunctionId="function:AnyOf">
> <Function FunctionId="function:string-equal">
> <AttributeValue Datatype="....#string">Hello World</AttributeValue>
> <AttributeDesignator ....../>
> </Apply>
I know that there was one match to the value "Hello World" but
I don't get back that value, I get a boolean value instead. If
I have an add function that is inside of a floor function (for
instance), I can't use anyOf to somehow make sure that bags
with only one value get handled correctly by the functions,
since I want to need to have the add function return a number,
not a boolean. The comment in the change request was that anyOf
can somehow be used to solve this, and my point is that it
cannot.
[Polar, responding to Seth] For the capability you allude to
below you use the map function;
<Apply FunctionId="function:map">
<Function FunctionId="function:double-floor">
<AttributeDesignator DataType="....#double" ....../>
</Apply>
===================================================================
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). See RESOLUTION.
SEE ALSO: CR#0150
RESOLUTION: Each "standard attribute" should have a "standard
datatype", since we proposed them for interoperability in the
first place. See
http://lists.oasis-open.org/archives/xacml/200210/msg00290.html
for attachment containing XACML_identifiers.doc, which is
Simon's proposed list. Simon has revised this to reflect all
e-mail comments received, and sent the revised version to Tim
for inclusion in v0.18f.doc
CHANGE REQUEST:
10.3.6 (Identifiers) doesn't list the type of any these
attributes, nor does it give the required uses for them that it
says implementors must follow. I realize this is transparent to
a lot of the code, and only one of these is required to
support, but it would still be helpful to know what type
they're supposed to be (if there is a certain expected
type). Later in the spec they're explained in a little more
detail, but not enough to make the strong language in this
section about correct implemention make sense.
DISCUSSION:
[Anne] Comments on Simon's proposed DataTypes:
- subject-category:codebase: this should be anyURI (it is usually a URL)
- subject-category:requesting-machine
o we should have two requesting machine categories:
requesting-machine-ip-address
requesting-machine-dns-name
o then both can be xsi:string
- subject:subject-id: we can't say the "default is xsi:string" since
DataType is required.
- subject:subject-category: should be anyURI (see list in B.2 - they are
all URNs)
- subject:subject-id-qualifier: SAML says type not specified. I suggest
we let DataType specify the type or else say anyURI
- subject:authentication-method: SAML uses anyURI, I suggest same
- resource:resource-id: description says "This identifier
indicates the entire URI of the resource." I believe this
should say "This identifier indicates the name of the
resource." I think we need to let DataType determine the type
(it might be a string, it might be a URL, it might be a URN,
etc.)
- action:actionNamespace: should be anyURI to fit with SAML's use
==================================================================
0146: [Polar] CR 144: function "present" needs to be fixed.
e-mail sent 22 Oct 2002 12:25:52 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00247.html
http://lists.oasis-open.org/archives/xacml/200211/msg00032.html
STATUS: UNRESOLVED (11/4). Need semantics in QualifiedSubjectAttributeDesignator.
SEE ALSO: CR#0092,CR#0154
RESOLUTION: Make new XML elements in schema. Remove them from
Appendix A, put them in text description. New proposal removes
all the -must-be-present functions, since new XML attribute on
attribute designator can do that.
SPECIFIC RESOLUTION: See revised text in
http://lists.oasis-open.org/archives/xacml/200210/msg00313.html
(MSWord) or
http://lists.oasis-open.org/archives/xacml/200210/msg00314.html
(pdf)
CHANGE REQUEST:
The function "present" as we discussed yesterday in spec 18d is
vague in whether it returns "false" or raises an
"indeterminate" if the attribute is not present.
DISCUSSION:
.... (outdated discussion removed)
My conclusion: Since attributes are retrieved by different
schema elements, it seems most logical to make their
"is-present" counterparts schema elements as well, using much
of the same machinery already in place. It would be easy to add
these as element of the AttributeDeignator/Selector/Type
complex types we ALREADY have defined:
So, I think a better approach would be to add the following
elements to the schema with the semantics I proposed in the
previous iterations.
These elements would be element instances of the
<AttributeDesignatorType>:
ActionAttributeIsPresent ActionAttributeMustBePresent
ResourceAttributeIsPresent ResourceAttributeMustBePresent
EnvironmentAttributeIsPresent EnvironmentAttributeMustBePresent
These elements would be element instances of the
<SubjectAttributeDesignatorType>:
SubjectAttributeIsPresent SubjectAttributeMustBePresent
These elements would be element instances of the
<SubjectAttributeDesignatorWhereType>:
These elements can be element instances of the
<AttributeSelectorType>:
AttributeIsPresent AttributeMustBePresent
[Simon] I think that <AttributeDesignator> and
<AttributeSelector> elements with mustBePresent attribute will
cover all cases:
[Polar, responding to Simon]
No, it won't. Thas is because I will not be able to write
predicates about their presence, and only be able to get an
"indeterminate" on requesting one.
And also, again, in the Target, where these things appear, that
attribute's semantics would complicate the idexing and
retriveal of policies and rules etc etc etc.
=================================================================
0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy
e-mail sent 29 Oct 2002 13:26:55 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00293.html
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). Use xs:string" in both places.
CHANGE REQUEST:
The Issuer is an "xs:string" in the context, and "xs:anyURI" in
the policy. (I am looking at 16j)
=================================================================
0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere
e-mail sent 30 Oct 2002 15:22:32 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00305.html
STATUS: UNRESOLVED. See partial RESOLUTION and OPEN ISSUE (NQ 11/4)
SEE ALSO: CR#0092, CR#0146, CR#0152
OPEN ISSUE:
1) How to deal with missing attributes when evaluating
a QualifiedSubjectAttributeDesignator. If
MustBePresent="true" on SubjectAttributeDesignator inside
the new <SubjectQualifier> element, does this mean that
every single <Subject> MUST contain an instance of that
Attribute or else the QualifiedSubjectAttributeDesignator
returns Indeterminate? This is the same issue being
addressed in CR#0092.
2) If multiple <Subject> blocks match the
QualifiedSubjectAttributeDesignator, then how does Policy
know which returned attributes go with which <Subject>?
RESOLUTION:
On 11/4, we agreed on the following changes to
address the original Change Request.
1) Replace all existing policy schema references to
"SubjectAttributeDesignator" with "CategorizedSubjectAttributeDesignator"
2) After doing 1), add the following fragment to the policy
schema:
<xs:element name="SubjectAttributeDesignator"
type="xacml:AttributeDesignatorType"/>
3) After doing 2), replace following policy schema fragment:
<xs:element name="SubjectAttributeDesignatorWhere" type="xacml:SubjectAttributeDesignatorWhereType"/>
<xs:complexType name="SubjectAttributeDesignatorWhereType">
<xs:complexContent>
<xs:extension base="xacml:AttributeDesignatorType">
<xs:sequence>
<xs:element ref="xacml:SubjectMatch" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
with
<xs:element name="QualifiedSubjectAttributeDesignator"
type="xacml:QualifiedSubjectAttributeDesignatorType"/>
<xs:complexType name="QualifiedSubjectAttributeDesignatorType">
<xs:complexContent>
<xs:extension base="xacml:AttributeDesignatorType">
<xs:sequence>
<xs:element ref="xacml:SubjectQualifier"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="SubjectQualifier
type="xacml:SubjectQualifierType"/>
<xs:complexType name="SubjectQualifierType">
<xs:sequence>
<xs:choice>
<xs:element ref="xacml:SubjectAttributeDesignator"/>
<xs:element ref="xacml:AttributeSelector"/>
<xs:choice>
<xs:element ref="xacml:AttributeValue"/>
</xs:sequence>
<xs:attribute name="MatchId" type="xs:QName" use="required"/>
</xs:complexType>
CHANGE REQUEST:
I think there's a problem with the schema involving the
SubjectAttributeDesignatorWhere (or the proposed name
SubjectQualifier, which I like more). It used to extend
SubjectAttributeDesignatorType, but with the addition of the
category element, it now only extends
AttributeDesignatorType. It still contains, however, a list of
SubjectMatchType, which in turn use
SubjectAttributeDesignatorType as their designator.
Shouldn't the match elements also extend
AttributeDesignatorType and not SubjectAttributeDesignatorType
in the SubjectQualifier? I think this needs a new match type
that uses AttributeDesignator but is specified in the spec to
look in the subject section of the request for all attributes.
DISCUSSION:
[Polar] In writing the stuff for the subjects, I've encountered
a problem for the QualifiedSubjectAttributeDesignator. I think
Seth was onto something in 0154 and 0155, but perhaps missed it
a bit.
The SubjectAttributeDesignator takes AttributeId, DataType,
MustBePresent, and SubjectCategory. It restricts the lookup of
the named subject attributes to the <Subject> matching the
SubjectCategory.
The QualifiedSubjectAttributeDesignator performs no such
category restriction. It just takes AttributeId, DataType,
MustBePresent, plus a bunch of <SubjectMatch>. The
<SubjectMatch>s are supposed to be restricted to one subject.
The only problem is that each SubjectMatch has an
SubjectAttributeDesignator in it, which *ALREADY* restricts the
look up to a particular subject matching the subject category.
So, as a result, a QualifiedSubjectAttributeDesignator must
have SubjectMatches all with the SAME subject category, or it
wont retrieve anything. Also, having one SubjectMatch restricts
it already to one Subject just by virtue of the category, which
I think is not the case we want.
[Polar] I suggest that we change the current
SubjectAttributeDesignatorType to
CategorizedSubjectAttributeDesignatorType
and have
CategorizedSubjectAttributeDesignator
and keep the SubjectAttributeDesignator a simple instantiation
of AttributeDesignatorType as it was before we added the
SubjectCategory attribute.
[Seth, responding to Polar] Is the intent to add a new AD type
to those allowed in an Apply, and therefore also create a new
MatchType? This might be overkill, though it could be useful.
=================================================================
0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere
e-mail sent 30 Oct 2002 15:28:10 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00306.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See RESOLUTION.
SEE ALSO: CR#0154
RESOLUTION: See #0154. The name of the sequence of elements
inside the
QualifiedSubjectAttributeDesignator/SubjectAttributeDesignatorWhere
is changed from SubjectMatch to SubjectQualifier.
CHANGE REQUEST:
This is a followup to my last email on Match types in the
SubjectQualifier ([xacml] Problem in
SubjectQualifier/SubjectAttributeDesignatorWhere). If I'm
right, and that structure needs to change, I would like to
request that it not have the same name as the other match
objects (ie, it should not be called something that looks like
SubjectMatchType). While it is similar in structure to the
other match types, the "match" elements used in the qualifer
are symantically an entirely different thing, and should
therefore be logically separated by using a different name, and
should not be covered by the same explanitory text in the spec.
=============================================================================
0156: [Seth Proctor] ObligationType
e-mail sent 31 Oct 2002 10:15:16 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00312.html
STATUS: UNRESOLVED
CHANGE REQUEST:
The ObligationType used to have a choice between an AttributeAssignment
or an AttributeDesignator, but now you can only have the AA. As such, the
xs:choice should probably be changed to xs:sequence, just to stay consistent
with schema language.
=================================================================
0157: [Steve Hanna] Glitch in moving from decimal to double
e-mail sent 31 Oct 2002 13:08:08 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00315.html
STATUS: UNRESOLVED
CHANGE REQUEST:
I see that v18e reflects the TC's decision to move from
xsi:decimal to xsi:double. I'm pleased with this decision,
but I noticed a problem:
The document cited as defining the arithmetic functions
([IBMSDA]) does not exist. Or at least the URL given in
the document (http://www2.hursley.ibm.com/double/decarith.html)
does not work. I suspect that this is the result of a
global search and replace operation, changing decimal
to double.
I suggest that this reference be replaced with IEEE 754,
which defines binary floating point arithmetic and is
cited by XML Schema for that purpose.
=================================================================
0158: [Simon] [Schema Change] Redefine <AttributeValueType>
raised during Subcommittee call on 11/4/02
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4)
RESOLUTION:
1) In the context schema, replace following:
<xs:element name="AttributeValue" type="xs:anyType"/>
with:
<xs:element name="AttributeValue"
type="xacml-context:AttributeValueType"/>
<xs:complexType name="AttributeValueType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
2) In the policy schema, replace following:
<xs:complexType name="AttributeValueType">
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
with:
<xs:complexType name="AttributeValueType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
CHANGE REQUEST: Define <AttributeValueType> in both the
policy and the context schemas in the same way that
context:ResourceContent is now specified.
RATIONALE: Validating parsers are happier with this way of
specifying an "any" type>
=================================================================
0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better
e-mail sent 01 Nov 2002 11:56:332 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00000.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
CHANGE REQUEST:
1. B.5 Subject attributes: Change initial paragraph from:
"These identifiers indicate attributes of a subject. At most
one of each of these attributes is associated with each
subject. Each attribute associated with authentication
relates to the same authentication event.
To:
"These identifiers indicate attributes of a subject. When
used, they SHALL appear within a <Subject> element of the
Request Context. They SHALL be accessed via a
SubjectAttributeDesignator, a
QualifiedSubjectAttributeDesignator, or an AttributeSelector
pointing into a <Subject> element of the Request Context.
At most one of each of these attributes is associated with
each subject. Each attribute associated with authentication
included within a single <Subject> element relates to the
same authentication event.
2. B.6 Resource attributes: Add introductory sentence saying:
"These identifiers indicate attributes of the resource being
accessed. When used, they SHALL appear within the <Resource>
element of the Request Context. They SHALL be accessed via a
ResourceAttributeDesignator or an AttributeSelector pointing
into the <Resource> element of the Request Context."
3. B.7 Action attributes: Add introductory sentence saying:
"These indentifiers indicate attributes of the resource being
accessed. When used, they SHALL appear within the <Action>
element of the Request Context. They SHALL be accessed via a
ActionAttributeDesignator or an AttributeSelector pointing
into the <Action> element of the Request Context."
4. B.8 Environment attributes: Add introductory sentence saying:
"These identifiers indicate attributes of the environment
within which the request is to be evaluated. When used, they
SHALL appear within the <Resource> element of the Request
Context. They SHALL be accessed via an
EnvironmentAttributeDesignator or an AttributeSelector
pointing into the <Environment> element of the Request
Context."
RATIONALE: the way in which these attributes are to be used is
not explicitly stated anywhere. While the names imply a usage,
it would be more clear to implementors if the usage were more
explicit.
=================================================================
0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better
e-mail sent 01 Nov 2002 12:45:10 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00001.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
CHANGE REQUEST: (Example revised per Polar e-mail and 11/4 discussion)
In Section A.3 Structured types, item 1., paragraph starting
with "1, change second sentence from:
"This requires the structured data, including its tags and
attributes, to be identified and treated as an instance of
the data-type xsi:string."
To:
"This requires the structured data <AttributeValue> to be
given the DataType="xsi:string". For example, a structured
data type that is actually a ds:KeyInfo/KeyName would appear
in the Context as:
<AttributeValue
DataType="DataType="http://www.w3.org/2001/XMLSchema-instance#string";><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue>
RATIONALE: Way#1 could be read as implying that the structured
data type is automatically cast or converted to the type
required by the function that references it. We should be very
clear that this does NOT occur.
DISCUSSION:
[Anne, responding to Polar]
> Now, if you do not regard the data as a string, and you actually give
> it a data type, i.e. extension to standard XACML, I wonder what happens
> for the following problem.
>
> Does the data within the attribute value have to be completely contained?
>
> For example, if you have <ds:KeyName>jhibberi-key</ds:KeyName> where is
> the "ds:" name space defined? (In the begining of the context? of which it
> cannot be guarranteed to be there) Or in the attribute value?
The ds: name space must be defined in the beginning of the
context if "ds:" is used in an XML fragment. If it is not
defined there, then there will be an error parsing the XML
context.
=================================================================
0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn"
e-mail sent 01 Nov 2002 12:52:45 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00002.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
CHANGE REQUEST:
In policy schema, <xs:complexType name="ObligationType">,
change <xs:attribute name="FulfilOn" to <xs:attribute
name="FulfillOn"
RATIONALE: Spec uses "FulfillOn", and we decided in a TC
meeting to use that spelling. Schema just has not been brought
into agreement yet.
==================================================================
0162: [Polar] [Schema/Text Change] Subjects
e-mail sent 04 Nov 2002 16:43:06 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00032.html
http://lists.oasis-open.org/archives/xacml/200211/msg00037.html (schema)
STATUS: UNRESOLVED.
CHANGE REQUEST:
Using QualifiedSubjectAttributeDesignators where there are
multiple <Subject> elements, particularly where multiple
<Subject> elements have the same subject-category means you may
get back multiple attribute values without knowing which
<Subject> element they came from.
RESOLUTION#1:
Make the subjects (i.e. lists of attributes) unique to the
category, and use the present SubjectAttributeDesignator (with
the SubjectCategory part) and get rid of the
SubjectAttributeDesignatorWhere. That's simple and I think
everybody can get their brains wrapped around that.
RESOLUTION#2:
See
http://lists.oasis-open.org/archives/xacml/200211/msg00066.html
which contains revised Section 5.
General description of proposed resolution:
Eliminate the SubjectCategory from the
SubjectAttributeDesignator and add the SubjectQualifiers to the
SubjectAttributeDesignator.
A SubjectQualifier extends a AttributeDesignator with the
following attributes "MatchId" and a "AttributeValue" element.
This approach allows you to qualify the SubjectMatch in the
target to any category or any other attribute. The only thing
that remains a problem for targeting is the MustBePresent, as
before.
Next extend QualifiedSubjectAttributeDesignator
SubjectAttributeDesignator with a "FromSubjects" attribute of
which its default value is "single-subject", as opposed to
"multiple-subjects".
Only QualifiedSubjectAttributeDesignators are allowed to be
Expressions. If the FromSubjects attribute is set to
single-subject and multiple subjects match, the expression
raises an indeterminate.
QualifiedSubjectAttributeIsPresent extends
SubjecAttributeDesignator with a "MustBeSingleSubject"
attribute. If MustBeSingleSubject is set to "true" and the
qualifiers select zero or more than one subject, then the
answer is false. Otherwise, it returns the true if the
attribute is within that selected subject. A true result with
MustBeSingleSubject set to true means that the attribute is
present and a QualfiedSubjectATtributeDesignator with
FromSubjects=single-subject will not raise an indeterminate.
DISCUSSION:
[Anne] In a <Target>, we currently allow one or more
SubjectMatch elements, each of which contains a MatchId, a
SubjectAttributeDesignator/AttributeSelector and an
AttributeValue.
Under your proposal, I think "Example" [deleted, since it was
actually not valid] below is a valid <Target>, meaning: there
must be at least one <Subject> element in the Request where all
of the following are true:
by first SubjectMatch:
the xxx AttributeId has a value of "ghi"
the yyy AttributeId has a value of "abc"
the zzz AttributeId has a value of "def"
by second SubjectMatch:
the aaa AttributeId has a value of "qrs"
the bbb AttributeId has a value of "jkl"
the ccc Attributeid has a value of "mno"
What do we gain over having multiple <SubjectMatch> elements,
each with a single AttributeDesignator and value to be matched?
[Polar, responding to Anne] I think the answer to your
question, is that Multiple Subject matches must match any
subject and they are not related to each other. That is one
SubjectMatch has nothing to do with the subjects matched in
another.
The SubjectMatch with a SubjectAttributeDesignator matches on a
restricted set of subjects.
[Polar, responding to Simon]
> I'm trying to understand your proposal. what you do is:
> attr-desig-type(attrid, data-type, issuer, must-be-present)
> subject-qualifier(match-id, attr-value)
> subj-attr-desig-type(0...many subj-qualifier)
> qualified-subj-attr-desig(from-subjects)
Yes. (I think)
> then qualified-subj-attr-desig is used in the subject-match in the target
> and in the apply element.
>
> it looks like subj-attr-desig-type is not used by itself.
Correct. It's only used for extenstion to
QualifiedSubjectAttributeDesignator and
QualfiiedSubjectAttributeDesignatorIsPresent.
> subject expression in the target is now quite complicated.
You still had to match on a subject category attribute. That is
no different on matching on any other named attribute,
really. The only thing, is now that you may have more
qualifying it in an AND, of which I don't think is that bad.
(i.e match me all subjects that have weight = 100 with
subject-category = access-subject, and role = doctor.
Indexing can still prevail.
[Polar, responding to Anne]
> But all matches within a single <Target><Subject> must pertain to
> one Request <Subject>. If you want to specify subject matches
> that are not related to that <Subject>, then you use another
> <Subject> element in your <Target>.
Right, I forgot that. Anyway, that suffers from the same
misleading problem, doesn't it? It means the "subjects" for
which the subject matches apply.
[Polar, responding to Simon]
> We have an open issue with subject designators that we want
> to solve asap. There is a proposal from Polar, but I think
> it is too complicated for quick adoption.
>
> My proposal:
> a) Quick solution to vote on thrs: Keep current
> subject-attribute-designator element with subject-category
> attribute and use it in the target and apply
> elements. Drop subject-attr-desig-where. I think it will
> cover 95% of all cases.
I wouldn't mind this, except for having multiple subjects for a
category! It just balls everything up. I cannot tell which
subject my attributes are comming from. That really bothers me.
I think we have screwed this whole thing up with multiple
subjects requirement and not understanding the ramifications of
the queries on them.
In my latest proposal, I've added complex attributes to the
elements to pop up indeterminates in the case where you get
multiple subjects matched. I don't really like that
solution. But I made the analogous IsPresent operator use
another attribute so that it returns false if the Qualifiers
select more than one subject. This also complicates the
SubjectMatch in that it has to throw an indeterminate when the
designator qualifies multiple subjects. Yuck! I hate it.
> b) Work out alternative proposal and delay voting until it is
> resolved
I think a better more workable solution would be to make the
subjects (i.e. lists of attributes) unique to the category, and
use the present SubjectAttributeDesignator (with the
SubjectCategory part) and get rid of the
SubjectAttributeDesignatorWhere. That's simple and I think
everybody can get their brains wrapped around that.
I think this approach will solve 95% of the simple cases as
well. And let's wait to 1.1 or 2.0 to get multiple subjects
down. It's already bad enough with multiple subject
categories. Geeezzz!
[Simon, for RESOLUTION#1]
+1
I would support [Polar's "better more workable solution above]
[Anne, for RESOLUTION#1]
> I think a better more workable solution would be to make the subjects
> (i.e. lists of attributes) unique to the category, and use the present
> SubjectAttributeDesignator (with the SubjectCategory part) and get rid of
> the SubjectAttributeDesignatorWhere. That's simple and I think everybody
> can get their brains wrapped around that.
I can live with this. What we lose is the ability to associate
attribute values with the identities and authentication methods
under which those attributes were issued. We can continue to try
to improve this for 1.1 or 2.0. I really think we are going to
need some serious thought to solve the problems raised by
SADWhere, and I would rather have a good solution than a complex,
understudied, possibly unworkable one.
[Carlisle, for RESOLUTION#1]
This is my vote as well: something workable in most cases for
1.0; something fancier for 1.1 / 2.0.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC