|
NSF Middleware Initiative: Draft Document: Expires: November/2002 |
James W. DeRoest University of Washington ResearchChannel
David L. Kuhlman, Jr. University of Tennessee
Mairéad Martin University of Tennessee
John H. McNair University of Tennessee
William A. Rhodes University of Tennessee
Ron D. Tipton University of Tennessee |
| Copyright © 2002
by UCAID and/or the respective authors |
|
| Comments to: nmi-support@nsf-middleware.org |
May/2002
|
The Role of Directories in
Video-on-Demand Applications
Abstract
The document presents an examination of three Video-on-Demand (VoD) scenarios of use to ascertain the role directories play in VoD applications in higher education, both in intra-realm and inter-realm contexts. Each scenario is deconstructed into component message flows to explore the extent to which directory services support access control, and what additional roles directories have in VoD deployment.
This analysis led to conclusions about the need to establish new directory services to specifically support VoD applications – a video asset directory and video endpoint directory, both complementing the enterprise directory. In addition, object class development is required to provide a standard and comprehensive description of users, devices and resources to enable global sharing of VoD assets.
Table of Contents
The Role of Directories in Video-on-Demand Applications
2 Conventions used in this document
4 Theories, Existing Standards and Proposed Solutions
4.1 Scenario #1: Use of Digital Video Assets in Library Electronic Reserves
4.2 Scenario #2: Annotation of Instructional Video
4.3 Scenario #3: Streaming and Archiving of a Videoconferencing Session
1 Introduction
The goal of this document is to ascertain what role directories play in video-on-demand applications. The three scenarios presented here were selected from scenarios developed by the VidMid Video-on-Demand Working Group, a collaboration between the Internet2 Middleware Initiative and the Video Development Initiative.
The three scenarios are:
1. Use of Digital Video Assets in Library Electronic Reserves;
2. Annotation of Instructional Video; and
3. Streaming and Archiving of a Videoconferencing Session.
We have by no means exhaustively represented the extent of developments in streaming video software and hardware, standards for multimedia delivery, broadband and mobile networking, and search and retrieval capabilities, but our selection has focused on scenarios representing applications of VoD that are most prevalent in higher education today. Each scenario is presented in the following way:
a) Description of scenario
b) Assumptions
c) Message flows
d) Diagram
2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.
3 Terminology
Authentication/Authorization Service:
Service that validates identity (authentication) and allowed access (authorization)
of a client.
Client:
User employing an endpoint to access video assets.
Directory:
Network-accessible database designed for mostly read access via standard protocols, e.g., LDAP.
Endpoint:
Hardware/software combination that provides audio and video encoding/decoding and signal functions.
Enterprise Directory:
Directory used to provide institutional information about the users often used for user authentication and/or authorization information.
Handle:
An identifier that can be shared between servers to refer to an individual without sharing any personal information about that user.
HTTP server:
Web server used to provide access to video assets.
Role:
Attribute associated with an entry in a directory to reflect specific privileges or membership in a group.
Shibboleth:
A project of Internet2/MACE to develop architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls
Video Asset Directory:
Directory containing information about the video asset, such as content,
ownership, and permissions. This information is a subset of the total metadata associated with the video asset.
Video Endpoint Directory:
Directory containing additional information about a client such as user's endpoint capabilities, callserver (SIP proxy, gatekeeper) and presence information.
Video Server:
For VoD, an endpoint that provides a video stream.
Video-on-Demand (VoD):
The client-initiated streaming of a digital video file from server to client.
4 Theories, Existing Standards and Proposed Solutions
4.1 Scenario #1: Use of Digital Video Assets in Library Electronic Reserves
4.1.1 Description of Scenario
John is a student in English Theater 201. His current assignment is to analyze death scenes in Shakespearean plays and present five 20 second video clips to illustrate his written assignment.
The class instructor has made a collection of Shakespeare's plays available in the electronic reserves section in the library for English Theater 201 students. John accesses the web-based reserve catalog, and clicks on the link to English Theater 201. Once his credentials are passed to the web server, a list of available movies and clips is displayed. He only has permission to view the clips and cannot capture any content, so he will bookmark the segments he selects, and present the bookmarks in his homework.
4.1.2 Assumptions
a) An enterprise directory is being used for authentication and authorization of the students.
b) The local enterprise security service can be PKI, Kerberos, a simple username/password or some other mechanism. All of these use the enterprise directory for verification of the user’s identity.
c) A group object has been created in the enterprise directory to represent the English Theater 201 students, and aliases to the student user objects in this directory have been assigned to this group.
d) The video server has the capability of indexing individual frames enabling the attachment of bookmarks to the frames. The bookmarks are stored in database tables and can be inserted as hyperlinks in HTML, XML, or proprietary document formats. The bookmarks created and maintained by the VoD system could also reside in a directory under a profile associated with the user’s identity. That would allow the bookmarks to follow the user as a roaming profile always available upon authentication.
e) Access is from public desktop machines in the Library reserve department.
f) The client application is already installed on client machines – a plug-in or standalone viewer, which also has the capability of annotating the video.
4.1.3 Message Flows
Message flows are divided into three phases – authentication, authorization and delivery.
Authentication Phase:
Diagram 1a
1. John authenticates with his local enterprise security service.
2. He then receives security credentials (a cookie, certificate, or token, for example), valid for some predetermined period of time – a single session, for example, or for the duration of the course.
3. He requests the English Theater 201 web page in order to access the video assets.
4. The HTTP server requests John’s security credentials.
5. The client application provides security credentials.
6. The HTTP server sends security credential verification request to the enterprise directory.
7. The enterprise directory verifies the security credentials.
Authorization Phase:
Diagram 1b
8. The HTTP server sends an attribute request to the enterprise directory to determine if John is a member of the English 201 group.
9. The enterprise directory returns the requested client attributes.
10. If it is determined that John is a member of the English 201 group, the HTTP server displays a list of available video clips and generates an artifact (cookie or token, for example) to be used in requests for access to video clips during this session.
Delivery Phase: (see Diagram 1b)
11. John makes specific video clip request.
12. Video server directs video stream to client.
4.2 Scenario #2: Annotation of Instructional Video
4.2.1 Description of scenario
During the clinical year of the Veterinary Medical curriculum, students take part in medical rounds. In preparation for each case, students watch an instructional video on the procedure in question. The students are required to annotate the video as they watch it and submit their annotations to the instructor prior to the round. The annotated video is reviewed by the instructor, and then uploaded to a video server for shared access. While viewing, the user enters annotations that will be saved locally as new layers with the video file. On completion, the annotated video is transferred to the instructor. After reviewing the video, the instructor uploads the annotated version to the video server.
4.2.2 Assumptions
a) An enterprise directory is being used for authentication and authorization of the students.
b) The local enterprise security service can be PKI, Kerberos, a simple username/password or some other mechanism. All of these use the enterprise directory for verification of the user’s identity.
c) A group object has been created in the enterprise directory to represent the Veterinary Medical students, and aliases to the student user objects in the directory have been assigned to this group.
d) The user objects have attributes indicating 1.) affiliation (student, instructor), 2.) college, and 3.) curriculum year.
e) There is a video asset directory associated with the video server that defines differential permissions and constraints for the video assets, including read/write permissions for the video server – the students do not have permission to upload the video files to the video server.
f) Video annotations are enabled by MPEG-4 or SMIL technologies.
g) The video file format and video client application support saving annotations with the video file.
h) The client application is already installed on client machines – a plug-in or standalone viewer, which also has the capability of annotating the video.
4.2.3 Message Flows
Authentication Phase:
Diagram 2a
1. The student authenticates with the local enterprise security service.
2. The student then receives security credentials (a cookie, certificate, or token, for example), that are valid for some predetermined period of time - a single session, for example, or for the duration of the course.
3. The student requests the class web page in order to access the video assets.
4. The HTTP server requests the student’s security credentials
5. The client application provides security credentials
6. The HTTP server sends security credential verification request to the enterprise directory.
7. The enterprise directory verifies the security credentials
Authorization Phase:
Diagram 2b
8. The HTTP server requests access control attributes associated with the video asset from the video asset directory.
9. The video asset directory responds with the requested access control attributes to the HTTP server.
10. The HTTP server submits a student attribute request to the enterprise directory to determine affiliation and other requirements.
11. The enterprise directory responds with the requested student attributes.
12. If it is determined that the student is in the clinical year of the Veterinary Medical curriculum, the HTTP server displays a list of available video clips at the client application and generates an artifact (cookie or token, for example) to be used in requests for access to video clips during this session.
Delivery Phase: (see Diagram 2b)
13. The student makes a specific video clip request.
14. The video server directs a video stream to the client application
4.3 Scenario #3: Streaming and Archiving of a Videoconferencing Session
4.3.1 Description of Scenario
An Internet2 Member Meeting is planned. Live videoconference capability will be available for the event, permitting remote users with access to appropriate MCU and resources to participate in two-way mode with the events. Additionally, the conference is simultaneously streamed to extend the conference (one way visual only) to a wider audience. This stream will be retained as an archive of the event that may be accessed "on-demand."
The live streams make it possible for people anywhere, who do not have real-time H.323 equipped systems available to them, to participate actively with an audio and video feed of the event and with a telephone or text based back-channel for their interaction. The archived VoD files made available immediately after the event make it possible for remote participants to refresh aspects of the event or to review material for more intense study.
4.3.2 Assumptions
a) Each user’s local enterprise directory is used for authentication and authorization of Internet2 members in this application.
b) The local enterprise security service can be PKI, Kerberos, a simple username/password or some other mechanism. All of these use the enterprise directory for verification of the user’s identity.
c) An attribute in the enterprise directory showing affiliation of "faculty" or "staff" is required to view the live and archived video streams.
d) Internet2 member institutions have formed a trust community, or tribe, and their enterprise directories include a shared set of attributes (i.e., "affiliation") and values (i.e., "faculty", "student" or "staff".)
e) Components of the Shibboleth (or similar) architecture are in place to support federated authentication and authorization in a secure manner.
f) In this scenario, the local enterprise directory has been enhanced with features to enable it to serve as a Shibboleth attribute authority.
g) An H.323 Multipoint Control Unit has the required bridge functionality to enable both streaming of the conference, and the telephone and text back-channel.
4.3.3 Message Flows
Authentication Phase:
Diagram 3a
1. The user requests access to the live video stream or archived video file of the conference from the (remote) I2 HTTP server.
2. The HTTP server requests a handle from the user's local handle service.
3. The local handle server requests security credentials from the client application.
4. If the client application does not have credentials, the user must authenticate with their local enterprise security service.
5. The enterprise security service responds with security credentials.
6. The client application passes the required credentials to the handle server.
7. The handle service contacts the local enterprise directory to assign a handle to represent the user.
8. The enterprise directory responds to the handle service with the URL of the attribute authority.
9. The handle service returns the handle and the URL of the attribute authority to the HTTP server.
Authorization Phase:
Diagram 3b
10. The HTTP server sends an attribute request to the enterprise directory for the user’s affiliation attributes.
11. The enterprise directory responds with the requested attributes.
12. If it is determined that the user is affiliated as faculty or staff with an Internet2 member institution, the HTTP server displays a URL to view the stream during the event, and generates an artifact (cookie or token, for example) to be used in requests for access during this session.
Delivery Phase: (see Diagram 3b)
13. The client application negotiates stream parameters with the video server.
14. The video server directs a video stream to the client application.
4.4 Conclusion
Our analysis of the role of directories in three typical VoD scenarios of use in higher education reveals that directory services are critical to these applications if discretionary access, shared administration and scalable delivery are desirable outcomes. A given scenario may involve one or more directory services, possibly in different realms or administrative domains, and these services are often complementary. In VoD applications, directories need to hold attributes about users, content, devices, and usage. In order that the enterprise directory is not over-extended with this additional information, and to keep it truly “lightweight”, we have posited two additional directories – a video asset directory and a video endpoint directory. Third-party servers (directory and other) may also be present in a VoD architecture to handle financial transactions, but we have not included these in our scenarios in order to focus on directory-enabled access.
The video asset directory contains a subset of the total metadata (descriptive, administrative, rights) about the video assets. Essentially, the video asset directory contains at least the metadata or attributes that are required to enable policy decisions to be enforced – decisions about who can access the asset and under what conditions, etc. The video asset directory includes critical information about roles and agents, which are critical determinants of access. Additional descriptive metadata might also reside in the video asset directory depending on local policies and emerging standards relevant to thedescription of multimedia content, such as MPEG-7 and METS.
The video endpoint directory also supports implementation of policy in so far as it relates to end devices, such as client applications and video servers. Such policies might include bandwidth provisioning, and accounting/billing functions, for example, as well as support presence information and resource discovery. It might indeed be advantageous to integrate the functions of the endpoint directory with directory services emerging to support videoconferencing. End point directories in videoconferencing serve to eliminate the need for prior configuration. There may be some applications of this function in VoD. In future iterations of this paper, we would like to explore the cases when information about a client application is required, where that information should reside, and how the endpoint directory could be discovered. When is it appropriate, for example, to store attributes closer to the client?
Maintaining authorization information separate from the asset – either in the video asset or video endpoint directory - has the additional benefit for the content owner of not having to change both the rights information and content format to reflect changes in either.
Clearly, administration of these individual directories needs to be distributed and the specialized video directories need to be entirely consistent with the enterprise directory, and with directory services and policies established to support a tribal model. The extent to which the user might have a role in administering and maintaining this information also needs to be explored.
In addition to revealing what components might be included in a VoD architecture, this exercise has illustrated the extent to which the Shibboleth model works well for inter-realm sharing of resources. High-quality video assets are valuable instructional resources, but are typically costly and time-consuming to create, it is, therefore, highly desirable for institutions to be able to share each other’s video resources. The federated administration of Shibboleth provides a means to do so, while securing private identity and secure messaging.
Analyzing the role of directories in VoD applications has also led to some conclusions about object class development and directory extensions to support these applications. As is the case with videoconferencing applications, video specific object classes are required to support information and attributes associated with users, devices, and resources in VoD applications. The eduPerson object class (or eduPerson-like attributes) can support the need to specify affiliation, which is key to the three scenarios presented here. An equivalent object class is required for video asset and endpoint directories. It is possible that the CommObject class defined by the VidMid Videoconferencing Working Group might fulfill this role for at least the endpoint directory. It is likely that other attributes in the video asset directory would be based on a standard metadata schema, such as the Dublin Core, in order to interoperate with other content management systems. Similarly, following a standards-based and widely used method for specifying unique IDs for assets, such as the Digital Object Identifier, is recommended for the video asset directory.
5 Documents
1. Johnson, Tyler et al. CommObject: Object Class Definitions, Internet2 VidMid Working Group and Video Development Initiative, NSF Middleware Initiative, May 2002. Available at http://middleware.internet2.edu/video/
2. Johnson, Tyler et al. CommObject: Directory Services Architecture for Video and Voice Conferencing Over IP, Internet2 VidMid Working Group and Video Development Initiative, NSF Middleware Initiative, May 2002. Available at http://middleware.internet2.edu/video/
6 Acknowledgments
The authors wish to thank members of the VidMid Working Group, the Video Development
Initiative, Internet2 Middleware Initiative and Internet2 staff for their
contributions to the development of this document. Graphics were created by
Dan Lipe of DanLipe Designs (danlipedesign.com) – we thank him for his patience
with us during the development process. We are also grateful to Mike West,
Graduate Student Assistant in the Advanced Internet Technologies, for his
assistance.
7 References
a) Cantor, Scott and Erdos, Marlena. Shibboleth-Architecture DRAFT v04. Internet2 and Middleware Architecture Committee for Education (MACE): November 21, 2001. Available at http://middleware.internet2.edu/shibboleth/
b) Gettes, Michael. A Recipe for Configuring and Operating LDAP Directories. Version 1.5, May, 2000. Available at http://www.georgetown.edu/giia/internet2/ldap-recipe/
c) Howes T., Smith M., and Good G. Understanding and Deploying LDAP Directory Services. MacMillan Network Architectures and Development Series, 1999.
d) Lagoze, Carl. Keeping Dublin Core Simple: Cross-Domain Discover or Resource Description?. D-Lib Magazine, Volume 7, Number 1, January 2001. Available at doi:10.1045/january2001-lagoze
e) eduPerson Object Class. Available at http://www.educause.edu/eduperson
8 Contact Information
James W. DeRoest
The University of Washington
4545 15th Ave NE, Room 111, 4545 Bldg
206-543-6343
deroest@cac.washington.edu
David L. Kuhlman
The University of Tennessee
600 Henley Street, Suite 313
Knoxville, TN 37996
865-974-2908
jkuhlman@utk.edu
Mairéad Martin
The University of Tennessee
600 Henley Street, Suite 313
Knoxville, TN 37996
865-974-2908
maireadm@utk.edu
John McNair
The University of Tennessee
600 Henley Street, Suite 313
Knoxville, TN 37996
865-974-2908
jmcnair@utk.edu
William A. Rhodes
The University of Tennessee
600 Henley Street, Suite 313
Knoxville, TN 37996
865-974-2908
wrhodes@utk.edu
Ron Tipton
The University of Tennessee
600 Henley Street, Suite 313
Knoxville, TN 37996
865-974-2908
uther@utk.edu