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

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

3. 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)

4. 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?

5. 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

6. 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

7. 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

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

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

10. 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

11. 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

12. 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

24. 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

25. FDRM Architecture: Components

26. 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.

27. 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.).

28. 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.

29. 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.

30. FDRM Architectural Flows 3
The WAYF server establishes a connection with the
requesting user and the Handle Service responsible
for the origin site.

31. 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.

32. FDRM Architectural Flows 5
The SHIRE then passes the received handle package
to the Shibboleth Attribute Requester (SHAR).

33. 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.

34. 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).

35. FDRM Architectural Flows 8
The SHAR passes the results of the ARM to the
Shibboleth Object Attribute Resolver (SHOAR).

36. 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.

37. 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.

38. 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).

39. FDRM Architectural Flows 12
The RM forwards the package request to the
Packaging and License Service (P/LS).

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

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