Introducing Matthew Rascoff, new Provost for Digital Education and Innovation.
II. Agenda Items
4:05- 4:30 – DukeExtend Evan Levine, Shawn Miller, Michael Greene (15 minute presentation, 10 minute discussion)
What it is: Duke Extend provides Duke faculty with a way to offer online modules to Duke students, selected groups of learners beyond the University.
Why it’s relevant: Duke Extend gives faculty the ability to build and deliver flexible content to provide full online courses or smaller, modular content. Courses can be offered ‘on-demand’ or ‘session based’ and can be customized to meet specific course/teaching needs. Extend also integrates with other Duke learning tools. Evan, Shawn and Michael will provide an overview of the service and how it will be utilized as part of Duke’s online learning environment.
You’ve heard about Duke Extend a couple of times. We gave a presentation on the learning tools ecosystem just before the holidays.
For more information:
Over a year or so ago, Coursera was making changes to the way it was doing business. We had conversations about alternatives to Coursera. This kicked off a 3-month process of looking at alternatives: Canvas; OpenEdX; and OpenEdX became the platform this
Why use Duke Extend?
Build and deliver flexible content
Reach global audiences of any size
Break the semester mold
Duke Extend is a technology that sits between Sakai and Coursera. Both Sakai and Duke Extend are built on open-source technologies; we have some limited say into their development. Coursera is both a platform and a marketing or business enterprise. It’s closed source and we don’t have much control over its development.
Sakai is free for anyone at Duke to use; Coursera isn’t, for certificates. With Duke Extend it can be free, but we also have the option of adding a paywall.
Sakai is tightly tied to the Duke NetID, but Duke Extend can use NetIDs or other forms of access. Coursera is public by default, but requires payment to reach certain layers.
Sakai is meant to be a do-it-yourself tool for faculty; it tries to meet many needs. Duke Extend sits more closely to the managed side; it will involve more consultation from CIT and OIT.
Duke Extend is not a replacement for LMS or a way to create 1900 courses; it is great for setting up boutique offerings that can be provided over and over.
Duke Extend is based on Open edX, and we can benefit from changes made by Open edX and they can benefit from ours. We're using a vendor, OpenCraft, who's been in the Open edX community for a long time and have done work with Harvard Business School and McKinsey. We’re hosting this on Amazon Web Services with help from OIT, and we’re using a lot of unlisted YouTube videos, as this is the Open edX standard.
Duke Extend has a complicated software stack, which helped us decide to engage an experienced vendor.
We’re using Duke technology: NetID/shibboleth; OneLink; Warpwire; and Lynda.com. Unfortunately Lynda.com doesn’t allow embedding, but we can link out to their content.
Warpwire is your option if you have video content that shouldn’t be made public.
Library patents module
Ronen Plesser's Intro to Astronomy: we invited 160,000 people by email, and 4,000 signed up. (We expected only 1%.) Of those who signed up, 20% weren't part of the bulk email.
Pilot feedback from this course:
Faculty are pleased with functionality and potential.
OneLink signups were found to be difficult, since new OneLink registrants weren’t immediately added to the course. We're working on making this now two-step process simpler in the future.
CoLab Roots courses
Research computing modules
Skills prep (boot camp) modules
Future of Duke Extend:
Building up infrastructure
Setting up a Drupal front-end for curation
(Drupal would allow better organization of the course catalog.)
Better access to data an analytics tools
Connecting to marketing or ecommerce
Connecting content to Sakai courses
How to get started:
Questions and Discussion
Question. Is there a way to use this digital platform as the web presence for a program?
Answer. You’d put your modules and work to do here. Build a WordPress site to provide other information about the program. Or, build a Drupal front-end that provides structure and pulls its modules from the Duke Extend platform.
Ultimately, we might offer a whole suite of micro-courses to alumni, and a layer of Duke Extend that's only available to alumni. This might include Coursera content, pared down to a one-week course, tied into a local visit. Duke Extend is flexible enough that courses could be scheduled or left always open, on-demand.
In the future we’re going to look into a train-the-trainer model.
Question: What about graduate student peer education?
Answer: We’d be open to talking about it.
4:30- 4:50 – Duke OneLink Service Update, Mary McKee (10 minute presentation, 10 minute discussion)
What it is: Duke OneLink is a service that allows the broader Duke community to sign in to select Duke online systems in lieu of a Duke NetID. OneLink requires registration so that Duke can associate OneLink credentials to a new or existing Duke account. This account can then be accessed by registering OneLink credentials.
Why it’s relevant: OneLink account registration is growing faster than ever, allowing many services the ability to leverage centralized authentication services for users without NETIDs. Now serving applicants, OneLink is increasingly viable for replacing localized accounts with a lightweight Duke identity that can be built upon over time.
Since 2015 there have been a lot of changes to the service, much of which affected the Toolkits service.
Basic overview: OneLink is a non-NetID electronic credential. This could be a username and password, or "OneLink External", a link with an external identity provider like Google or Facebook. You may have heard this called "Social SAML."
“Social SAML” wasn’t the best term for this; it was used because social account providers (like Google and Facebook) were among the first to allow portable credentials we could use in this way.
We don’t want to give everyone NetIDs, and we have a lot of services we'd like to extend out to a wider community, while leveraging centralized resources and support and apply security standards.
Initial vision: there’s a higher-ed interest in using external (non-Duke) credentials to get access to Duke resources. This scales accounts without requiring Duke to provide password reset services for every account. We also want to reduce the liability and overhead related to Duke Guest account registration, and allow alumni to use their Duke accounts without depending on NetIDs.
This service has doubled in size every six months, consistently.
There have been a few things part of our initial vision that haven’t really worked out.
It's not as simple as "internal vs. external"; people transition between the two states all the time. We need more flexibility.
We also learned that people don't always know whether they have a OneLink account or not, since registration experiences have varied. We're trying to standardize this.
Also, OneLink accounts have not always ported easily from application to application.
We introduced a massive paradigm shift.
OneLink version 2: This time it’s personal.
The idea here is to separate the credential from the identity. With OneLink, we can have multiple credentials tied to a single identity. You can think of OneLink as being the keyfob remote to your car key. It will let you into the car, but it won’t give you the same level of access as the car key will. (Opening doors, but not starting the ignition.)
Any identity can have one NetID and any number of OneLink accounts. An applicant will start as a OneLink user; if they matriculate they will get a NetID on the same account, and retain a consistent identity.
The last time we came to ITAC we had about 10k accounts. Now we have 100k accounts and 85k users. (A user might have more than one set of accounts, or may have been using a now-retired credential provider, such as AOL.)
We’ve gone from 100 OneLink logins per day to 4700.
Previously we limited eligibility to people we already knew about (alumni and former NetID users); now we allow anyone to be eligible for OneLink.
The OneLink registration process involves filling in an online form with information about yourself; we then compare to our existing identity information to see if we already know who you are. We'll either link your registration to the existing identity or offer to set up a new account. A minority of these registration attempts require analyst attention to review applications compared to Duke’s existing records. We're working to reduce the need for analyst review.
Making registration process good, and Service Desk knowledgebase articles and triage paths consistent.
We’ve focused a lot on collecting metrics about invitation success. Now we’ll focus on getting good metrics on the registration process.
Our logs now have a “stream ID” which we can send across systems. This key lets us get a holistic metrics picture of where we’re losing people.
We’re piloting new admin service tools. We hope to start looking at credential activation as a way to facilitate onboarding, making self-service available.
Questions and Discussion
Question: Is there a connection between this and federated systems like Kerberos?
Answer: Because this is implemented in Shibboleth, we have the ability to federate. We see this as a way of filling the gap between having a Duke account and having another federated account (such as at another higher-ed institution).
By default any service that supports Shibboleth login is capable of using OneLink, but you have to ask us to enable that. We wouldn’t necessarily want you to use OneLink credentials to log into Duke@Work.
Question: Could this provide a way for parents to be able to log in to student bursar accounts?
Answer: Yes, this is viable.
Question: Do we have visibility into the social accounts related to OneLink identities?
Answer: We collect very little identity from the social accounts; for example, we get a unique identity from Google, but that doesn’t tell us the name of the Google account. We’re very careful to keep this lean to ensure user comfort.
On the topic of consent: we don’t want to ask alumni to come to the Duke Alumni site with fear that we’re going to mine data about them and use it in ways they don’t approve of. Instead, we establish a consensual process; they reveal data to enable certain services, but if they don’t want those services, they don’t reveal those data. We don't take more data than we need to provide the service.
In Identity Management we stress the distinction betweeen authentication versus authorization; then security versus privacy.
There’s an opportunity for improvement for online courses: once a person is invited to register for OneLink, they still have to be added as a student in the course once OneLink registration is complete.
Question: What are the minimum data points you require for a OneLink registration?
Answer: First name, last name, email, and year of birth. We also solicit middle name and full date of birth, but they’re optional.
4:50- 5:15 – Security Camera Update, John Board, Bob Johnson, Barton Lawyer (15 minute presentation, 10 minute discussion)
What it is: Bob, Bart, and John will discuss the existing and planned security camera installations at Duke, both the camera locations and the extensive back-end infrastructure supporting them, as well as the usage policy for video from the cameras.
Why it’s relevant: University departments may request security cameras to be installed as part of a new construction effort, major renovation, or as a stand-alone project. All cameras transmit digital video data in real-time to a secure OIT-managed video storage and retrieval system located in a secure data center.
Our first foray was tied to a need for door access and video to be matched up in the same system for compliance reasons. The solution was never meant to be a comprehensive solution, but requests kept coming in. There were reliability issues, so we looked at other alternatives, including the one we ended up selecting.
We’ll soon have good coverage around campus to support the DUPD efforts to keep campus safe. A camera oversight and review committee was established to oversee the service and address technology, privacy and retention concerns. They established a policy; and technical standards used today.
One of the key questions has been around the privacy aspects. The approach has been to model access to the cameras after Duke’s acceptable use policy and limits who may see the video and the reasons for viewing them. There must be a clear reason for viewing the videos (e.g. DUPD for public safety situations), and extraordinary requests require high-level approval.
In most cases, departments are not free to set up and monitor their own cameras on campus due to the privacy and liability concerns. Specifically exempted from this policy are cameras in classrooms, laboratories for research purposes, and cameras on police cars and body cameras.
The current process to request a camera on the Duke system are to make a request to the DUPD. DUPD performs a site visit, needs analysis, and estimate; the results are forwarded to the camera committee. If approved, OIT managed the installation.
Most of the cost of any camera installation is the cable installation. There’s an annual maintenance fee for every camera. Active, automated to look for broken cameras, camera drift, and other technical issues.
Questions and Discussion
Question: What about off-campus and legacy cameras?
Answer: This is not for health system purposes.
Question: Sensors for research purposes?
Answer: The policy exempts sensors for research purposes.
Question: How scalable is this?
Answer: The system can scale to meet the needs of campus.
Question: What about new facilities?
Answer: There’s a discussion of whether cameras are appropriate for a new building. Most new buildings get cameras at primary entrances and exits.
Question: What’s the cost trend over time?
Answer: Installation of conduit is very expensive, and that cost is not going down over time. Disk space may get less expensive, but image resolution and file sizes keep increasing.