We just enabled the Inherited Keys tab on the Developer Keys page and had a few questions since we're seeing several keys enabled. Some of these are for vendors we have implemented, and some are not.
Are there any best practices recommended for ensuring a higher degree of security?
If we weren't using these inherited keys before for a vendor that we have installed, would turning off the inherited key prohibit access to the service for any of our users?
Does allowing the inherited keys to remain enabled cause any unintended data to be sent to these vendors?
Good question! I'm interested in this as well. I love the idea of scoped developer keys, but curious how Canvas handles it on their end.
Following up on this question. We've searched throughout the community forums and have not been able to find information on how to know exactly what these inherited keys need access too. With more inherited keys and not much detailed information on the Canvas vetting process, it would be beneficial to have at least the scopes visible for admin for these keys.
At this point, piggy-backing off of this question, does anyone have any recommendations for how to ensure a higher degree of security when using inherited keys and turning on new ones?
@jk224 Yep, I think it would be really useful if there was a read-only view of the inherited developer keys. The other complication I see with inherited developer keys is even if we could review the permissions we are granting at setup time how can we then be aware of any further changes that are made to the developer key?
I know that if the allowed permissions change the users will get prompted to re-grant the tool access to their account, but it would be useful if we as an organisation had to re-enable the tool (or something similar).
On helpful side thing would also be if Instructure allowed users to see what permissions a user was granting on the "Allow this application access to your account?" page.