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 & RDF


About http://wiki.oasis-open.org/xacml/XACMLandRDF


"2. Add provisions in the request/response syntax to identify resources, subjects, and actions by URI alone."

According to the 3.0 core spec (lines 2418-2419), attributes are identified by all of category, attributeId, data type, and issuer (if present). I'm assuming there were good reasons to include category et al? In practice, I don't think I've seen any attributeId reused across categories. Is anyone actually doing that?

"3. Extend the policy language to test ontological conditions such as subclass membership and class relations."

What extensions do you think are necessary to support such features?

"Attributes/properties of what?"

The Document example rule matches any document, but in practice one would often want to grant access to a limited set of documents. I think we need to some semantic definitions on attribute *values* to handle this. That seems to be the case for hierarchical actions as well.

Another example where that would be helpful is with hierarchical roles. A policy may grant access to 'employee', but the request may specify 'manager' as the value for the role-id attribute. The ontology should be able to define that 'manager' implies 'employee'. The RBAC profile allows us to specify such a role hierarchy, but not very elegantly IMHO, since the permission PolicySets "must be stored in the policy repository in such a way that they can never be used as the initial policy for an XACML PDP" (lines 160-161). Defining the role hierarchy as an ontology, and specifying some machinery in the context handler to process ontologies could improve the RBAC profile.

"RDF for attribute metadata"

"We don't want to force the PEP to include type="Document" and type="SpecialDocument". So the first thing the PIP does is to discover all the additional types entailed from the initial request context."

According to Figure 1 of the core 3.0 spec (lines 475-478), the PIP is asked for attribute values *after* the PDP decides it needs them. What in the Document/SpecialDocument example would make the PDP request attribute values from the PIP? Or did you mean the context handler?


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