# Specification Updates - Factor out Remote Data Registry - [Replace broad Remote Data Grants with broad Data Consent](https://github.com/solid/data-interoperability-panel/issues/143) - https://github.com/solid/data-interoperability-panel/issues/113 - Should resolve this issue raised here: [Reconsider tying RemoteAgentDataRegistration..](https://github.com/solid/data-interoperability-panel/issues/110) - Move operations out into a separate specification (and determine the format / structure) - Update shape trees to reflect latest changes to shape tree specification - [Define Data Grants as immutable](https://github.com/solid/data-interoperability-panel/issues/142) - [Data Grants should include information about who owns the data](https://github.com/solid/data-interoperability-panel/issues/140) - [Add specific shapes for different data grant scopes](https://github.com/solid/data-interoperability-panel/issues/109) - Remove Referenced Data Grants, replacing with an InheritedInstances scope. See: [Referenced Data Grant - improving ergonomy of traversal](https://github.com/solid/data-interoperability-panel/issues/124) - Ensure that [access grants can support limited control scenarios](https://github.com/solid/data-interoperability-panel/issues/100). Recent decisions about splitting access grants and data grants should make this a more straightforward adjustment. - [AllInstances scope should still take into account referenced types](https://github.com/solid/data-interoperability-panel/issues/118) - [Support physically nested access needs and grants](https://github.com/solid/data-interoperability-panel/issues/103) - Needed so that access can be authorized to "bridge relationship" data in a given data instance without having to provide access to the entire instance. - [Keep IRIs opaque to the client](https://github.com/solid/data-interoperability-panel/issues/120) - [Consider providing an alternate approach for application registration discovery](https://github.com/solid/data-interoperability-panel/issues/91) - At least in addition to the current (lower-tech) mechanism. Over time a possible replacement altogether. - Remove hard requirement on UUIDs for resource names, and instead provide requirements that a scheme must satisfy. See: [Why Requirements on Resource Names](https://github.com/solid/data-interoperability-panel/issues/99) - [Add discovery mechanism for key application services](https://github.com/solid/data-interoperability-panel/issues/101) - (e.g. authorization agent). - [Update Application Registration Formatting](https://github.com/solid/data-interoperability-panel/issues/102) - Straightforward formatting changes - [Add section on discovery mechanisms](https://github.com/solid/data-interoperability-panel/issues/104) - Of specific note here is that public data in particular would be addressed as part of this effort - [Define means for Access Grant Subject to verify Access Receipt delivered in message](https://github.com/solid/data-interoperability-panel/issues/107) - critical to ensure access receipts delivered between agents are not spoofed - [Consider adding Update Data Instance Operation](https://github.com/solid/data-interoperability-panel/issues/108)