OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XACML 3.0 schemas


All,

I have started updating the schema files for XACML 3.0 core. As
described in issue 34 in the issues list
(http://wiki.oasis-open.org/xacml/IssuesList), there is a circular
dependency which needs to be resolved.

In 2.0 there are two schema files: the policy and context schemas.

In 2.0 the context schema imports the policy schema since the response
needs the obligation definitions from the policy schema.

In 3.0 we need to add a policy issuer to the policy schema. The policy
issuer has the same type of content as an Attributes element from the
request context, so the policy schema needs to import the context schema.

Together these lead to a circular import, which is not handled by many
commonly used tools and parsers.

There are three alternatives to proceed:

1. Duplicate the definitions of obligations into the context schema, so
it doesn't need to import them from the policy schema.

2. Refactor the common element (obligations and attributes) into a third
schema which is imported by both the policy and context schemas.

3. Merge the context and policy schemas into a single xacml schema.

To me the third option seems best. It just requires a cosmetic change in
the AttributeValue element in order to work. Currently both the context
and policy schemas define their own AttributeValue element. The
difference is that the one in the policy schema has a DataType attribute
while the one in the context schema does not have.

I suggest that we drop the AttributeValue element defined in the context
schema and reuse the one in the policy schema, and drop the DataType
attribute from the Attribute element.

The first solution leads to redundancy between the schema files and the
second means that a request is not contained in a single namespace,
which is a bit annoying. It would look like this:

<Request xmlns="...:context:schema:os">
  <Attributes xmlns="...:common:schema:os"
      Category="Whatever">
      ...
  </Attributes>
   ...
</Request>

There is a similar situation for policies which contain obligations.

Let me know if you think this is a good solution. Is there some reason
to have separate context and policy schemas, which I don't know about?

For now I will proceed based on a merged schema.

Regards,
Erik



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]