- Combiner parameters are a property of the combining algorithm. The standard combining algorithms do not include any one which takes any parameters. You cannot just add a combiner parameter to the policy and expect the combining algorithm to start to behave differently. The profile should define new combining algorithms which clearly specify how they behave given parameters.
I agree. I will correct this in the next version.
- I don't understand section 10.2.
This allows the policy designer to specify a custom obligation schema (as defined in Sections 6.1 and 7) for a given policy, thereby making it possible to have a policy-specific set of obligations, attributes and constraints (sequencing or overriding constraints) for each policy.
- Could you avoid the double negative in the "not-transaction-action" attribute by renaming it to "transaction-action"?
My initial thought on this was that since the default is “transaction”, the attribute that overrides this default behavior should be called “not-transaction” to make this choice explicit. But I think we can change this to “transaction-action” with the default being “true”.
Best regards,
Erik
On 2012-12-11 20:43, Mohammad Jafari wrote:
Submitter's message
This is the proposed first draft for the XSPA Obligation Profile. I have incorporated the points raised by Danny Thorpe and have also added substantial details about the semantics of the attributes and each obligation as well as the overall model.
I have also included a complete example with sample codes for the schema, policies, request and response and the event flow for processing them.
I have not included the XML schema definitions at this point since things may change. It can be added later once the content of the document is finalized. For the moment, the examples should give a sufficient picture of how things work.
Your feedback and comments is greatly appreciated.
--Mohammad
-- Mohammad Jafari
Document Name: Proposed draft for XSPA Obligation Profile for XACML
Description
This is the proposed first draft for the XSPA Obligation Profile. I have
incorporated the points raised by Danny Thorpe and have also added
substantial details about the semantics of the attributes and each
obligation as well as the overall model.
I have also included a complete example with sample codes for the schema,
policies, request and response and the event flow for processing them.
I have not included the XML schema definitions at this point since things
may change. It can be added later once the content of the document is
finalized. For the moment, the examples should give a sufficient picture of
how things work.
Download Latest Revision
Public Download Link
Submitter: Mohammad Jafari
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: repository
Date submitted: 2012-12-11 11:43:11 |