Incorrectly Interpreting License Rights

If your application does not correctly interpret and enforce the rights expressed in the AD RMS issuance license, you may make information available in ways that the information owner did not intend. An example of this is when an application allows a user to save unencrypted information to new media when the issuance license only confers the right to view the information.

The AD RMS system organizes rights into four groups:

• EDIT — The EDIT right allows a user to create an AD RMS encrypting object and an AD RMS decrypting object; therefore, this user has permission to consume or publish information at will. The application itself must implement functionality for the rights that will actually be available for a user with the EDIT right and provide or prohibit access in the interface for the exercise of various rights.
• OWNER — The OWNER right allows a user to exercise all rights in the license, whether or not they are specifically granted. It also allows the creation of both an AD RMS encrypting object and an AD RMS decrypting object. As in the case of a user who has the EDIT right, the application may limit the exercise of some rights by not providing the functionality to exercise the rights.
• VIEWRIGHTSDATA — The AD RMS client allows a user granted the VIEWRIGHTSDATA right to reuse the license information. It grants the right to make an AD RMS decrypting object, but it should ideally be used only for reusing the rights information from a license.
• All other rights — Users with any other rights can create an AD RMS decrypting object only if the rights are specifically defined by the application and granted in the license and none of these rights allow the creation of an AD RMS encrypting object. Users with these rights are limited to the functions explicitly allowed by the various rights.

AD RMS APIs allow a user to either decrypt information or not; the information does not have any inherent protection. If a user has the right to decrypt information, the API permits it, and the application is responsible for managing or protecting that information after it is in the clear. An application is responsible for managing its environment and interface to prevent the unauthorized use of information; for example, disabling the Print and Copy buttons if a license only grants the PLAY right. Your test suite should verify that your application acts correctly on all the license rights that it recognizes.

Standard level	Description
Minimum standard	The customer implementation of XrML v.1.2 rights should be consistent with the definitions of these rights, as described in the XrML specifications, which are available at the XrML Web site (https://www.xrml.org). Any rights that are specific to your application must be defined for all entities that have an interest in your application. Your test suite and test process should verify that your application executes properly against the rights that the application supports and that it does not act upon unsupported rights. If you are building a publishing application, you must make information available that explains which intrinsic rights are and are not supported by the publishing application and how these rights should be interpreted. In addition, the user interface should make clear to the end user what the implications are of each right granted or denied an individual piece of information. Any rights that are abstracted by inclusion in new rights implemented by an application need to be mapped to the new terminology. For example, a new right called MANAGER might include as abstracted rights the PRINT, COPY, and EDIT rights.
Recommended standard	None at this time.
Preferred standard	None at this time.

Send comments about this topic to Microsoft

Build date: 3/13/2008