Transcript Federated Digital Rights Management

Federated Digital
Rights Management
Mairéad Martin
The University of Tennessee
July 18, 2015
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
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
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 the
requesting 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
8
The SHAR passes the results of the ARM to the
Shibboleth Object Attribute Resolver (SHOAR).
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
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
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.