Federated Digital Rights Management Mairéad Martin The University of Tennessee December 6, 2018

Topics DRM Problem Space R&E vs. industry requirements NMI and DRM Workshop FDRM Project description Architecture

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 reactive Existing Rights Expression Languages have limitations, and are immature Patent encumbrances (ContentGuard) Authorization Expressions: SAML vs. XACML vs. REL – overlap?

NMI and DRM Workshop Sept. 9, 2002 Funded by the NSF NMI program to: Explore DRM requirements in Research and Education Look at ways NMI development might be leveraged Endorsed by CNI, EDUCAUSE, I2, SURA, ViDe www.ait.utk.edu/drmworkshop

DRM Requirements for Research & Education Multiple roles in academia: consumers, producers, distributors of information Multiple applications: Instructional Management Systems, portals, databases, online content, electronic journals, online collaboration, ….. Gradations of risk

DRM Requirements for Research & Education Fair use “First Sale” principle Privacy of the end-user Derivatives Complex objects Inter-institutional collaboration and sharing of resources

DRM Models: Industry One-to-one Pay-per-view Trusted systems Use monitoring Static content User as consumer Proprietary hardware/software

DRM Model: Research & Education One-to-many Flexible access User as consumer and producer Dynamic content Inter-institutional, cross realm access Privacy Interoperability

Workshop Outcomes Conclusions: Additional DRM function - to record rights Access over enforcement Not one unifying architecture but balkanized landscape Need for more discussion DRM Requirements for R&E: Discussion Paper submitted to OASIS RLTC Creation of DRM WG within I2 Middleware Initiative

Federated DRM Project Fundamental Goal: Enable intersection of attributes about user, content and usage to manage objects An application of Shib Also federates rights administration Tennessee and Rutgers leading project

Why Shibboleth? Emphasis on federated administration Emphasis on flexible yet secure access Establishes trust communities Active privacy a core principle Open source, community development Project maturing

Project Status FDRM architecture published and presented Participating in Shibboleth Pilot Development of R&E requirements document -> refine design FDRM 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.).

FDRM Architectural Flows 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 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 The WAYF server establishes a connection with the requesting user and the Handle Service responsible for the origin site.

FDRM Architectural Flows 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 The SHIRE then passes the received handle package to the Shibboleth Attribute Requester (SHAR).

FDRM Architectural Flows 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 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).

FDRM Architectural Flows 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.

FDRM Architectural Flows 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 The RM forwards the package request to the Packaging and License Service (P/LS).

FDRM Architectural Flows 13 The P/LS creates the requested package and sends it back to the RM.

FDRM Architectural Flows 14 The RM passes the requested resource to the user.