Docstoc

martin

Document Sample
martin Powered By Docstoc
					Federated Digital
Rights Management

Mairéad Martin
The University of Tennessee
September 8, 2012
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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:14
posted:9/8/2012
language:Unknown
pages:41