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] | [Elist Home]

Subject: RE: [xacml] XrML & XACML Review

Title: RE: [xacml] XrML & XACML Review

After reviewing the XrML 2.0 specification in detail, I would say that XACML and XrML are fundamentally the same.  The differences between the two specifications are in the approach and semantics used to model access rights.  Both specifications are attempting to answer the same question: "Is such-and-such a Principal authorized to exercise such-and-such a Right against such-and-such a Resource?" (eXtensible rights Markup Language (XrML) 2.0 Specification Part II: Core Schema page 43)

The XrML schema is similar to the 3-tuple of subject, action and object originally proposed for XACML.  The core element is a grant, which contains a principal, right, resource and condition elements.  The principal, right and resource elements map to the subject, action, resource defined in XACML.  The XrML condition has aspects of both the condition and obligation elements in XACML.  However, it is very limited when compared to the predicates and predicate expressions supported by XACML.  In XrML conditions are all combined with an implied  "and".  XrML does not have a way to explicitly express a denial or negative assertions. 

The XrML use cases focus on access rights and licensing of digital works.  In these cases, the issuer of the license is the owner of the digital work; therefore, there would not be a need to combine different licenses or policy statements.  However, XrML supports both encrypting and digital signing of the licenses.

To simplify the writing or generation of policy, XrML supports using variables and templates within a license documents.  This functionality is similar to XSLT use of variables and templates.  They are resolved as a pre-process prior to evaluating the policy statements themselves. 

Similar XACML, XrML supports external references for many of its elements. The standard supports requesting data or access services via WSDL, UDDI, or Xpath. 

In XrML, rules and obligations can be explicitly delegated to another trusted process.    

As with XACML, the core elements in XrML are types that can be redefined to extent the basic syntax.   XrML has a standard set of extensions to support payment and state full conditions, X509 Subjects, and a variety of rights/actions.  Just to name a few.

Overall, XrML seems to have addressed all of the issues and use cases relating to license agreements.  From that perspective, it is very strong.  However, XrML is not suited for complex access policy or rule sets.


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

Powered by eList eXpress LLC