Mairéad MartinThe University of TennesseeApril 19, 2023

Federated Digital Rights Management

Topics

DRM Problem SpaceR&E vs. industry requirementsNMI and DRM WorkshopFDRM

Project descriptionArchitecture

DRM Problem Space

DRM - the management of intellectual property and distribution of digital content But different interpretations abound …..

Industry: DRM = protect the copyright owner’s rights through enforcement, and support licensing model Research & Education: DRM = enable access while managing intellectual property and protecting user’s privacy, (distributed sharing and collaboration model)

DRM Problems

Industry driven: R&E reactiveExisting Rights Expression Languages have limitations, and are immaturePatent encumbrances (ContentGuard)Authorization Expressions: SAML vs. XACML vs. REL – overlap?

NMI and DRM Workshop

Sept. 9, 2002Funded by the NSF NMI program to:

Explore DRM requirements in Research and EducationLook at ways NMI development might be leveraged

Endorsed by CNI, EDUCAUSE, I2, SURA, ViDewww.ait.utk.edu/drmworkshop

DRM Requirements for Research & Education

Multiple roles in academia: consumers, producers, distributors of informationMultiple applications: Instructional Management Systems, portals, databases, online content, electronic journals, online collaboration, …..Gradations of risk

DRM Requirements for Research & Education

Fair use“First Sale” principlePrivacy of the end-userDerivativesComplex objectsInter-institutional collaboration and sharing of resources

DRM Models: Industry

One-to-onePay-per-viewTrusted systemsUse monitoringStatic contentUser as consumerProprietary hardware/software

DRM Model: Research & Education

One-to-manyFlexible accessUser as consumer and producerDynamic contentInter-institutional, cross realm accessPrivacy Interoperability

Workshop Outcomes

Conclusions: Additional DRM function - to record rights Access over enforcementNot one unifying architecture but balkanized landscapeNeed for more discussion

DRM Requirements for R&E: Discussion Paper submitted to OASIS RLTCCreation of DRM WG within I2 Middleware Initiative

Federated DRM Project

Fundamental Goal: Enable intersection of attributes about user, content and usage to manage objectsAn application of ShibAlso federates rights administrationTennessee and Rutgers leading project

Why Shibboleth?

Emphasis on federated administrationEmphasis on flexible yet secure accessEstablishes trust communitiesActive privacy a core principleOpen source, community developmentProject maturing

Project Status

FDRM architecture published and presentedParticipating in Shibboleth PilotDevelopment of R&E requirements document -> refine designFDRM architecture in NMI 2.0 (October 2002)Need to secure funding for prototype development

FDRM Architecture: Components

FDRM Components

Resource Attribute Authority (RAA) Function: A database of metadata containing rights records with rights, permissions and constraints associated with a digital resources.

Shibboleth Object Attribute Resolver (SHOAR) Function: A component that interacts with the RAA in order to obtain the rights metadata associated with the requested resource.

FDRM Components

Resource Manager (RM)Function: The RM resolves the user’s attributes with the resource attributes (rights, permissions and constraints), and forwards the details of the package request to the P/LS. The RM is the equivalent of a DRM Controller in a commercial DRM model.Packaging/License Service (P/LS)Function: A fundamental component of DRM architecture, the P/LS dynamically packages content for delivery. The licensing function of the P/LS entails specification of the rights the user is allowed to exercise on the content (e.g., play, annotate, edit, transfer, etc.).

1

A user in an origin site launches a web browser and selects a URL to access a managed resource from a HTTP server.

FDRM Architectural Flows 1

FDRM Architectural Flows 2

2

The Shibboleth Indexical Resource Establisher (SHIRE) receives the user's request and sends the location of the requested resource and the SHIRE's URL to an off-site "Where Are You From?“(WAYF) server.

FDRM Architectural Flows 3

3

The WAYF server establishes a connection with therequesting user and the Handle Service responsible for the origin site.

FDRM Architectural Flows 4

4

The local Handle Service returns the handle package to the SHIRE. The handle package includes the opaque handle and the address of the user's local AA (UAA) server.

FDRM Architectural Flows 5

5

The SHIRE then passes the received handle package to the Shibboleth Attribute Requester (SHAR).

FDRM Architectural Flows 6

6

The SHAR constructs an Attribute Query Message (AQM) and submits it to the UAA defined in the handle package. The AQM includes the opaque handle, the target URL and the SHAR name.

FDRM Architectural Flows 7

7

The UAA responds to the AQM with an Attribute Response Message (ARM), which includes the SHAR name, target URL and the user attributes as allowed by the user's Attribute Release Policy (ARP).

FDRM Architectural Flows 8

The SHAR passes the results of the ARM to the Shibboleth Object Attribute Resolver (SHOAR).

8

FDRM Architectural Flows 9

9

The SHOAR constructs a Resource Attribute Query(RAQ) and submits it to the Resource Attribute Authority (RAA) associated with the requested resource.

FDRM Architectural Flows 10

The RAA returns a Resource Attribute Response (RAR) to the SHOAR detailing the supporting services and access rights associated with the requested resource.

10

FDRM Architectural Flows 11

11

Depending on the assertions received from the UAA and the RAA, the SHOAR sends a package request to the Resource Manager (RM).

FDRM Architectural Flows 12

12

The RM forwards the package request to the Packaging and License Service (P/LS).

FDRM Architectural Flows 13

13

The P/LS creates the requested package and sends it back to the RM.

FDRM Architectural Flows 14

14

The RM passes the requested resource to the user.