---
# System prepended metadata

title: Specification Updates

---

# 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)

