[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Comments resolved at 12/09/02 meeting
On Tue, 10 Dec 2002, Michiharu Kudoh wrote:
> ================
> Case 1)
> <AttributeSelector
> RequestContextPath="//Attribute[@AttributeId='serial-no' and
> @DataType='..string']/AttributeValue/text()" DataType="..string"/>
>
> The above AttributeSelector retrieves a text node "1234" in the request.
> This value is cast into XACML string type specified in the
> AttributeSelector element.
And returns a bag of "...#string".
I agree with this approach. The DataType names the resultant type.
> ================
> Case 2)
> <AttributeSelector
> RequestContextPath="//Attribute[@AttributeId='serial-no' and
> @DataType='..string']/AttributeValue/text()" DataType="..integer"/>
>
> The above AttributeSelector is still valid. The value "1234" is cast into
> an integer type and it succeeds. The caller of the AttributeSelector
> receives a bag of one integer.
Correct. Provided the Context Handler/PDP can convert the data to an
integer.
What should happen if it cannot? Indeterminate? Or leave it out, i.e.
empty bag?
> ================
> Case 3)
> <AttributeSelector
> RequestContextPath="//Attribute/@IssueInstant" DataType="..DateTime"/>
>
> The above AttributeSelector retrieves "12/10" and the caller of the
> AttributeSelector receives a bag of one DateTime.
I agree. But the same question, what if the pointed at nodes are not of
the correct type.
> ================
> Case 4)
> <AttributeSelector
> RequestContextPath="//Attribute[@AttributeId='keyinfo' and
> @DataType='..ds:keyinfo']/AttributeValue" DataType="..ds:KeyInfo"/>
>
> The above AttributeSelector retrieves ds:KeyInfo node as a aggregated DOM
> node. Since data type specified in the policy is not XACML primitive data
> type, then no cast operation is performed and a DOM structure (it should be
> a XACML primitive type) is returned (as one element bag structure). The
> policy writer is expected to specify an external function that handles such
> DOM node. The returned bag may include more than one DOM node.
I would say not a DOM node, because we don't have functions do deal with
DOM nodes. The PDP must understand the type to a point. That is it has
been given a set of extension functions that work on that type. The higher
order functions like map and such can deal with them using the extension
functions.
For example, you load the PDP with external functions, such as
"external:keyinfo-get-key-name", which takes a "ds:keyinfo" and returns a
"string", which is the <KeyName> element of the KeyInfo. The following is
a condition which is true if "Alice" is a key name of any key info
selected by the AttributeSelector.
<Condition FunctionId="any-of">
<Function "function:string-equal"/>
<AttributeValue DataType="....#string">Alice</AttibuteValue>
<Apply FunctionId="function:map">
<Function FunctionId="external:keyinfo-get-key-name">
<AttributeSelector ....... DataType="ds:keyInfo">
</Apply>
</Condition>
Cheers,
-Polar
> Michiharu Kudo
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
>
>
>
>
> |---------+---------------------------->
> | | Anne Anderson |
> | | <Anne.Anderson@Su|
> | | n.com> |
> | | |
> | | 2002/12/10 05:37 |
> | | Please respond to|
> | | Anne.Anderson |
> | | |
> |---------+---------------------------->
> >--------------------------------------------------------------------------------------------------------------|
> | |
> | To: Seth Proctor <Seth.Proctor@Sun.com>, "John Merrells <merrells@jiffysoftware.com> XACML |
> | COMMENT", XACML TC <xacml@lists.oasis-open.org> |
> | cc: |
> | Subject: [xacml] Comments resolved at 12/09/02 meeting |
> | |
> | |
> >--------------------------------------------------------------------------------------------------------------|
>
>
>
> The appended comment text represents the resolutions to comments
> that were made at the 12/09/02 XACML Comment Subcommittee
> meeting.
>
> Present: Anne Anderson, Tim Moses, Carlisle Adams, Bill Parducci,
> Michiharu Kudo, Polar Humenn, Hal Lockhart.
>
> The XACML Comments Subcommittee will meet again on Tuesday
> 12/10/02 from 10am - noon (EST) to resolve the remaining open
> comments, which are:
>
> 0071.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00035.html
> Subject: Element <Description>
> [editorial]
>
> 0072.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00039.html
> Subject: 5.31 Element <AttributeSelector>
> [several sub-comments, possibly resolved by #68]
>
> 0073.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00047.html
> Subject: XACML 1.0 Committee Specification Comments
> [lots of sub-comments]
>
> 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
>
> Comments resolved on 12/09/02 or still open after 12/09/02
> ====================================================================
> 0052b. "In the case where the XPath expression matches attributes in
> the request context by AttributeId, it must also match the
> attribute's data-type with the selector's DataType."
>
> Does the 'it' above mean the XPath expression? So, it's saying
> that if you write an xpath expression to select an attribute from
> the context, and the expression includes a predicate for matching
> with an AttributeID, then that expression MUST also include a
> predicate that matches the selectors data type with the data type
> of the selected attribute...?
>
> CATEGORY: Unclear.
> STATUS: Resolved 12/09/02.
> RESPONSE: "it" means the XACML context handler. The XACML
> context handler must filter the values returned by the XPath
> expression based on matching the DataType, returning only those
> that match the DataType to the PDP.
> ACTIONS:
> Use the wording in the XACML draft dated 12/6/02 (attached to
> http://lists.oasis-open.org/archives/xacml-editors/200212/msg00024.html)
> plus the following edits:
>
> 1) Section 5.32: eliminate references to "primitive" type.
>
> 2) In Section 5.32, pdf:2373-2375: replace following sentence:
>
> In the case that the XPath expression matches attributes in
> the request context by their Attribute Id, the PDP MUST
> additionally verify that the attribute's DataType is the
> same as the element's DataType.
>
> with
>
> The PDP SHALL eliminate values from the resulting bag that
> are not of the DataType specified in the AttributeSelector.
>
> 3) In Section 6.7 Element <Attribute>, pdf:2633, change the description of
> the DataType xml attribute from:
>
> Attribute data type
>
> to:
>
> The data type of the contents of the <AttributeValue>
> element. This SHALL be either a primitive type defined by
> the XACML 1.0 Specification or a type defined in a schema
> whose namespace is defined in the Context schema.
>
> 4) In Section 5.32 Element <AttributeSelector>, pdf:2403: change
> the description of the DataType xml attribute from:
>
> The data-type of the attribute.
>
> to
>
> The data-type of the value of each node in the sequence
> returned by the XPath expression.
>
> DISCUSSION:
> 12/9/02: There are several cases (I may not have the XPath syntax
> quite right -aha)
>
> 1. An XPath expression may select nodes that are parents of the
> contents of an <AttributeValue>. The selected nodes may
> contain
>
> 1a. A primitive value.
> Example: "/Request/Subject/Attribute@IssueInstant"
> selects primitive values of type xs:dataTime from the
> IssueInstant xml attribute of all Subject Attributes.
> 1b. A structured value.
> Example: "/Request/Subject/Attribute" selects
> structured values whose structure is defined in
> the XACML schema. Type is xacml:AttributeType
>
> In this case, the XACML schema itself specifies the type of
> the resulting node value(s).
>
> 2. An XPath expression may select the full contents of one or more
> <AttributeValue> nodes themselves. The selected nodes may contain
>
> 1a. A primitive value.
> Example:
> "/Request/Subject/Attribute[@AttributeId="urn:...:subject-id"
> and @DataType="xacml:x500Name"]"
>
> might select one or more primitive values like "cn=Anne,
> ou=Labs, o=Sun, c=US", with a DataType of xacml:x500Name.
>
> 1b. A structured value.
> Example:
> "/Request/Subject/Attribute[@AttributeId="urn:...:key-info
> and @DataType=ds:keyInfo"
> would select structured elements with values like:
> <ds:KeyName>anne's public key</ds:KeyName>
> <ds:KeyValue>
> <ds:RSAKeyValue>
> <ds:Modulus>BQADgY0AMIGJAoGBAK/yHi+g4n</ds:Modulus>
> <ds:Exponent>CZGRYY2feUmVrM0QKOzAdr</ds:Exponent>
> </ds:RSAKeyValue>
> </ds:KeyValue>
>
> In this case, the <Attribute> element's DataType xml attribute
> specifies the type of the resulting node value(s).
>
> 3. An XPath expression may select nodes that are sub-elements of the
> contents of an <AttributeValue>. The selected nodes may contain
>
> 3a. A primitive value.
> Example:"/Request/Subject/Attribute[@AttributeId="urn:...:key-info
> and @DataType=ds:keyInfo/KeyName"
> would select elements of xs:string DataType with values like:
> "anne's public key"
> 3b. A structured value.
> Example:"/Request/Subject/Attribute[@AttributeId="urn:...:key-info
> and @DataType=ds:keyInfo/KeyValue"
> would select elements with values like:
> <ds:RSAKeyValue>
> <ds:Modulus>BQADgY0AMIGJAoGBAK/yHi+g4n</ds:Modulus>
> <ds:Exponent>CZGRYY2feUmVrM0QKOzAdr</ds:Exponent>
> </ds:RSAKeyValue>
>
> In this case, the schema associated with the "ds" namespace
> (which must be referenced in an xmlns attribute in the Context
> header) will specify the type of the resulting node value(s).
>
> 4. An XPath expression may select the ResourceContent or a
> sub-element of the ResourceContent.
>
> In this case the schema associated with the ResourceContent
> will specify the type of the resulting node value(s).
>
> Where the values selected are of primitive types defined by
> XACML, then standard XACML functions can deal with them.
>
> Where the values selected are of primitive or structured types
> not defined by XACML, then extended functions must be supplied to
> deal with them.
> =======================================================================
> 0066.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00016.html
> Subject: another resource question
> From: Seth Proctor <seth.proctor@sun.com>
> Date: Tue, 03 Dec 2002 18:08:04 -0500
>
> Section 7.8 doesn't say anything about error conditions, and I'm
> wondering if it should. I know that some things are out of scope
> and shouldn't be considered (eg, if only some Descendants could
> be resolved, the app-specific code should decide whether or not
> this is an error). But what should happen if there is some
> unrecoverable error in the process of discovering the resource
> list? Should the PDP return an error, or should it evaluate with
> the single resource that was provided in the Request? I would
> hope it could return an error, but 7.8 doesn't say anything about
> this.
>
> CATEGORY: Incomplete.
> STATUS: Resolved 12/09/02.
> RESPONSE: Allow for <Decision>s to be returned about resources
> that could not be discovered. Do this by returning a <Decision>
> with the ResourceId of the hierarchical element that could not be
> resolved or completely resolved, with an error <Status> on that
> <Decision>. Other <Decision>s on hierarchical elements, even if
> they are descendants of the element that has the error, may have
> non-error <Status> in the same Response.
> ACTIONS:
> Use wording from 12/6/02 draft (attached to
> http://lists.oasis-open.org/archives/xacml-editors/200212/msg00024.html)
> with the following additional edit:
>
> pdf:2918:
> 1) eliminate "related"
> 2) insert between element and SHALL the words "associated with
> the parent element".
> =======================================================================
> 0068.
> http://lists.oasis-open.org/archives/xacml-comment/200211/msg00134.html
> Subject: D002
> From: John Merrells <merrells@jiffysoftware.com>
> Date: Tue, 26 Nov 2002 17:35:05 -0800
>
> [Same comment submitted for D024]
>
> The policy uses string-equal as if the args were (bag<string>,string),
> this should
> probably be using the any-of method...
>
> <Condition
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
> <SubjectAttributeDesignator
>
> AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-tests:bogus"
> DataType="http://www.w3.org/2001/XMLSchema#string"/>
> <AttributeValue
>
> DataType="http://www.w3.org/2001/XMLSchema#string";;>Zaphod
> Beeblebrox</AttributeValue>
>
> CATEGORY: Incorrect.
> SEE ALSO: #69
> STATUS: Resolved 12/09/02.
> RESPONSE: Use wording specified in ACTIONS below. Say nothing in
> the specification about policies that are rejected before ever
> being presented to a PDP for evaluation: XACML specifies only the
> behavior of the PDP in evaluating a policy that is presented to
> it. Conformance Tests will not require systems that reject
> policies asynchronously with Request evaluations to return a
> given Response that depends on the rejected policy.
> ACTIONS:
> 1) Add to Section 7 a new sub-section:
>
> 7.x Syntax and Type Errors
>
> If a policy with invalid syntax is evaluated by the XACML PDP
> at the time a Request is received, then the result of that
> policy SHALL be "Indeterminate" with a StatusCode value of
> "urn:oasis:names:tc:xacml:1.0:status:syntax-error".
>
> If a policy with invalid static types is evaluated by the XACML
> PDP at the time a Request is received, then the result of that
> policy SHALL be "Indeterminate" with a StatusCode value of
> "urn:oasis:names:tc:xacml:1.0:status:processing-error".
>
> 2) Add following "Special Instructions" to every Conformance Test
> that uses an initial policy that has a syntax or static type
> error:
>
> The policy for this test contains [schema|static type] errors.
>
> If an initial policy with invalid [syntax|static types] MAY
> EVER be evaluated by the implementation's XACML PDP at the time
> a Request is received, then this test MUST be passed. In this
> case, the resulting Decision MUST be "Indeterminate"
> with a StatusCode value of
> ["urn:oasis:names:tc:xacml:1.0:status:syntax-error" - if
> syntax error
> |
> "urn:oasis:names:tc:xacml:1.0:status:processing-error" - if
> static type error
> ]
>
> If the implementation's XACML PDP CAN NEVER attempt to evaluate
> an initial policy with invalid [syntax|static types], then the
> implementation MUST demonstrate that the policy in *Policy.xml
> will be rejected by whatever entity is responsible for
> validating policy syntax in the system in which the XACML PDP
> will be used. In this case, the supplied Request and Response
> files are not relevant and may be ignored.
>
> DISCUSSION:
>
> Summary: some implementations perform validity checking on
> policies at the time they are configured into the PDP. The PDP
> will never see such policies. These PDPs may, however, see
> invalid policies that are referenced via a PolicyIdReference or
> PolicySetIdReference.
>
> Other implementations may look for and evaluate policies only at
> the time a Request is received. In this case, one or more of the
> initial policies may have validity errors.
>
> The XACML specification should not force an implementation to
> perform policy validity checking (syntax or type) at the time a
> Request is received, so the Conformance tests should not require
> this.
> ==========================================================================
> 0069. http://lists.oasis-open.org/archives/xacml/200212/msg00027.html
> Subject: IIC012: syntax-error or processing-error?
> From: Anne Anderson <Anne.Anderson@Sun.com>
> Date: Wed, 04 Dec 2002 08:58:43 -0500 (EST)
>
> Conformance Test IIC012 is intended to test for the error case in
> which a Condition FunctionId uses a function that does not return
> a Boolean result. The <Condition is:
>
> <Condition FunctionId
> ="urn:oasis:names:tc:xacml:1.0:function:integer-subtract">
> <Apply FunctionId
> ="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only">
> <SubjectAttributeDesignator
> AttributeId
> ="urn:oasis:names:tc:xacml:1.0:conformance-test:age"
> DataType="http://www.w3.org/2001/XMLSchema#integer"/>
> </Apply>
> <Apply FunctionId
> ="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only">
> <EnvironmentAttributeDesignator
> AttributeId
> ="urn:oasis:names:tc:xacml:1.0:conformance-test:bart-simpson-age"
> DataType="http://www.w3.org/2001/XMLSchema#integer"/>
> </Apply>
> </Condition>
>
> Question: should the StatusCode Value from evaluating this Policy
> be "urn:...:status:syntax-error" (since it is a type error), or
> "urn:...:status:processing-error"?
>
> I'm leaning toward syntax-error. What do others think?
>
> CATEGORY: Unclear.
> SEE ALSO: #68
> STATUS: Resolved 12/09/92 (same as #68).
> RESPONSE: See #68
> ACTIONS: See #68
>
> DISCUSSION:
> Long discussion on xacml@lists.oasis-open.org
> See #68.
> ==========================================================================
> 0071.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00035.html
> Subject: Element <Description>
> From: Anne Anderson <Anne.Anderson@Sun.com>
> Date: Thu, 05 Dec 2002 14:02:39 -0500 (EST)
> --------------------------------------------------------------------------
> 0071a. In Section 5.20 "Element <Policy>" under the description of the
> <Description> sub-element, add "See 5.2 Element
> <Description>."
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
> --------------------------------------------------------------------------
> 0071b. In Section 5.2 "Element <Description>", change first sentence
> from:
>
> The <Description> element is used for a free-form
> description of the <PolicySet> element and <Policy>
> element.
>
> to:
>
> The <Description> element is used for a free-form
> description of the <PolicySet>, <Policy>, and <Rule>
> elements.
>
> CATEGORY: Incomplete.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
> ===========================================================================
> 0072.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00039.html
> Subject: 5.31 Element <AttributeSelector>
> From: John Merrells <merrells@jiffysoftware.com>
> Date: Thu, 05 Dec 2002 12:16:38 -0800
> ------------------------------------------------------------------------
> 0072a. If you want to enforce type correctness
>
> between the selector and the values then you have these
> choices... 1) The author of the XPath expression must write the
> expression so that it matches both the AttributeId and the
> DataType.
>
> Subject/Attribute[AttributeId= '...subject-id' and
> DataType"..."]/AttributeValue
>
> or, 2) the processor must enforce the type correctness. Option 1
> is clearly error prone as people just won't bother, option 2
> could be quite hard. [Although using the AttributeValue as the
> context node you could say "../@DataType"]
>
> CATEGORY: Incomplete.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> [Anne Anderson]
> I think we specified option 2 in the resolution to 0052b:
>
> The XACML context handler must filter the values returned by the
> XPath expression based on matching the DataType, returning only
> those that match the DataType to the PDP.
>
> [John Merrells, responding to Michiharu Kudo]
> >For the type correctness, I don't expect that option 1 always
> >occurs. So each implementation should enforce the type
> >correctness. I mean that the processor just calls some XPath
> >processor to retrieve the requested node set irrespective of the
> >datatype specified in the selector. After some string
> >conversions are performed, the processor checks whether each
> >string value can be converted to the datatype specified in the
> >selector. Either way, this kind of run-time type checking should
> >be implemented for the case of ResourceContent.
>
> Good. The specification text needs to be changed. Currently it
> states:
>
> "In the case where the XPath expression matches attributes in the
> request context by AttributeId, it must also match the
> attribute's data-type with the selector's DataType. "
>
> >If XPath expression does not include a predicate expression to
> >satisfy data type requirement (Subject/Attribute[AttributeId=
> >'...subject-id' and DataType"..."]/AttributeValue), it can
> >select a node that has different data type. But I think this is
> >the problem of the policy specification and not the problem of
> >the AttributeSelector specification. Certainly, it would be
> >better to add some note about this in the specification.
>
> Yes. If the expression author writes an XPath that selects
> multiple attribute values with different DataTypes, then that is
> their problem.
>
> It would be good for the specification to point this out for
> expression writers.
> --------------------------------------------------------------------------
> 0072b. How is the selected node converted into a value?
>
> You can convert a node into a string-value, as defined in the
> XPath spec. You then have a choice of using the string to value
> conversions that are defined in XPath, or use the conversions as
> defined in XACML. I would specify as the later, as XPath has some
> oddities in this area. (ie. The string 'false' has the boolen
> value true.)
>
> CATEGORY: Incomplete.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> [Anne Anderson]
> I believe this is clearly specified in Section 5.33,
> pdf:2404-2415:
> XPath 1.0: apply "string" function
> XPath 2.0: use xf:string accessor function.
>
> [John Merrells, responding to Michiharu Kudo]
> >I think that the semantics of the AttributeSelector should
> >conform to the specified version of the XPath. So the conversion
> >functions would be ones specified in the corresponding XPath
> >specification. In the case of XPath 1.0, each conversion (node
> >set to string value and string value to each data type) would be
> >the conversion specified in XPath 1.0 even if it may have some
> >oddities in it.
>
> I'd suggest that Implementors of XACML will find it easier to
> convert a string into an XACML type, than to convert a string
> into an XPath type and then into an XACML type. Fisrtly the XPath
> conversion functions would have to be exposed through the XPath
> processor API. The XPath interface specification does not mandate
> this. Also, the string to XACML type constructors should be
> readily available. [As the implementor will almost certainly have
> implemented these for expression processing.] Secondly, the
> specification will have to provide a table that maps the XPath
> type system onto the XACML type system.
>
> [Michiharu Kudo, responding to John Merrells]
> For the string type, I think there is no need to specify which
> string type to be implemented in the specification. It is up to
> the implementors. In turn, that string must be converted into
> the target XACML data type (e.g. XMLSchema#boolean) specified in
> the AttributeSelector element. This conversion is not clearly
> specified in the specification. We may borrow conversion
> semantics from XPath 2.0 function and operator draft document
> e.g. xf:boolean-from-string.
>
> --------------------------------------------------------------------------
> 0072c. The next problem is working out which type to convert the
> string-value into.
>
> If we assume that the author or processor has checked that the
> selector and value types match then we can use the DataType
> specified in the selector.
>
> CATEGORY: Incomplete.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> [Anne Anderson]
> I believe this is specified in the response to #52b: The XACML
> context handler must filter the values returned by the XPath
> expression based on matching the DataType, returning only those
> that match the DataType to the PDP.
>
> [John Merrells, responding to Michiharu Kudo]
> >And I could not find any XACML function definition that converts
> >"false" string value to False boolean value in the committee
> >specification. Which function are you talking about?
>
> Section '4.3 Boolean Functions': "Function: boolean
> boolean(object) ... a string is true if and only if its length is
> non-zero"
>
> >If the conversion failed, then "Indeterminate" should be
> >returned (optionally with some status code such as
> >syntax-error).
>
> This statement should be added to the specification.
> --------------------------------------------------------------------------
> 0072d. Another example that should be explored is an XPath
> expression executed over the ResourceContent.
>
> In this case there are no DataTypes provided with the values, so
> there's no type checking that can be performed. We can only
> assume that the value provided is a valid representation for a an
> instance of the value of DataType specified in the selector. If
> the value can not be coerced into that DataType then what should
> the processor return?
>
> CATEGORY: Incomplete.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> [Michiharu Kudo]
> In the case of ResourceContent, the selected node set and resultant string
> value(s) must be checked against the data type specified in the selector.
> If the conversion failed, then "Indeterminate" should be returned
> (optionally with some status code such as syntax-error).
> ===========================================================================
> 0073.
> http://lists.oasis-open.org/archives/xacml-comment/200212/msg00047.html
> Subject: XACML 1.0 Committee Specification Comments
> From: "Chopra, Dipak" <dipak.chopra@sap.com>
> Date: Mon, 09 Dec 2002 05:44:55 +0100
>
> I reviewed the XACML 1.0 Committee Spec and here is the list of
> questions/comments.
> ----------------------------------------------------------------------------------
>
> 0073a. Can PAP and PDP exchange Policy Set?
>
> Based on the Section 3.1 Data Flow Model, it seems like only
> Policy can be exchanged. If that is the case, how can PDP
> evaluate Policy Set as mentioned in Section 7.7 Policy Set
> Evaluation?
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073b. What is the commonality between different Policy elements
> in the same Policy Set?
>
> The requirement on line #354 seems to indicate that the merging
> of different Policy elements into Policy Set is governed by "a
> given action". Does it mean that the cardinality between Policy
> Set and Action is 1 to 1? It seems confusing as schema does not
> suggest that.
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073c. As Target can have multiple Resource and Action elements,
> not every Action is valid for each Resource. But the current
> schema allows to provide more non-existent access to resources.
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073d. What is the significance of an Obligation with
> FulfillOn="Deny"?
>
> Which use case needs this feature?
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073e. Line #2675, scope can be "Descendants" or "Children" as
> mentioned on lines #2907, 2908 in the case of multiple results.
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073f. Section 7.6 Policy Evaluation.
>
> The table should be Policy truth table.
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073g. Section 7.7 Policy Set Evaluation.
>
> The table should be Policy Set truth table.
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073h. In this table, what is the meaning of "Effect" of Policy.
>
> As far as schema is concerned, Policy does not have this
> attribute. Only Rule has Effect element. Probably the right
> statement "At least one policy value has the calculated effect
> value".
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073i. Line #2907, 2908.
>
> It seems like authorization decision MAY include multiple results
> based on the structure of resource sub-tree. I think this
> mechanism provides more information than requested. PEP is
> requesting if this subject(s) has the specified access
> (actions(s)) on the specified resource and its child nodes. The
> response should be one result. Why would PEP want to get detailed
> result information for each sub-node under resource? PEP must
> know about the structure (if there is any) of the requested
> resource and accordingly request for authorization decision from
> PDP. Based on that response, PEP should be able to allow or
> disallow the request. On line #2968, it says only one Decision
> element, which is not right based on lines #2907, 2908.
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> ----------------------------------------------------------------------------------
>
> 0073j. There are two different types of resources.
>
> Functionality resource and data-instance resource. For example,
> ManagePO resource can be used to create/delete/modify an instance
> of PO. So ManagePO is a type of functionality type resource and
> instance of PO is a data-instance type resource. If we need to
> mandate that this action of this data-instance type resource can
> only be permitted by this functionality-type resource, how do we
> enforce that?
>
> CATEGORY: Unclear.
> STATUS: Not yet discussed.
> RESPONSE:
> ACTIONS:
>
> DISCUSSION:
> =====================================================================================
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC