We were wondering if anyone has developed a vetting and renewal process for giving third party applications developer keys for their Canvas instance? I already messaged @joseph_allen but then I thought, "why not post this to the Canvas Admin area too?" We have recently had a few schools that purchased access to some online training or secure browsers for testing that require a developer key to be setup and function. This means they get a developer key for the whole instance even though their LTI just exists in a sub account for the school in question. carroll-ccsd and I feel that we need something in place showing that they're FERPA compliant, safeguard our data, and at the contract's end they destroy or give us the data. What are other people doing? Beyond the vetting we are working on the procedure to renew (or not) the dev key annually without causing us a ton more work when we're dealing with 364+ schools.
Hi SHEBENE, one of our teams has acquired a tool (used outside of Canvas) that they want to now integrate with Canvas. The installation setup requires a Developer Key, and I'm not comfortable giving them access to the entire account. I'd be willing to provide it if they can work with us on the scoping parameters, so that everything is in alignment with the existing Data Sharing Agreement. Did you ever land on a vetting process? Are you leveraging scoping with issued developer keys?
Our current model is that our legal department will write an addendum to the site-specific contract in relation to FERPA that furthers it to include the district as a whole and outlines state-specific language in regards to data. This is a slow process to where we're really waiting for Canvas to update to a model that allows developer keys at the sub-account level. It appears that they're working towards that. Additionally, @joseph_allen shared the HCPSS document they came up with for a data agreement. You could inquire about getting a copy of that if it interests you.
Thanks Neal, I'm also at HCPSS so familiar with our DSAs which we use with all our LTIs, but we previously haven't authorized tools that asked for adeveloper key. Seems like that enables access we don't want 3rd parties to have even with the DSA in place. Have you done anything with the scoping limits Canvas added last year, or are you just holding off on developer keys altogether? In our case, the requested integration isn't subaccount-specific, but it won't necessarily be widely used either so I'm hesitant to give them access to everything.
We understand and share the hesitance. We have one key given to HonorLock and look forward to moving it down to the sub-account it needs instead of the district level. We haven't looked at the scoping limits but would be interested to find out more if anyone else has utilized this. Otherwise, yes, we're holding off on developer keys, waiting for the sub-account access as a natural limiter/filter.
Following up on this to see if anyone has any examples of written correspondence that they have these developers fill out? To serve as a first-round of written contract.
Here's what we send to vendors. They don't always understand it, particularly if they are sales types. Our compliance office requires a Full HECVAT which can be a big lift for small businesses, but honestly, there are lots of other vendors who have published their HECVAT documents which people can use as a model.