Retrieval of resources on demand has endless security implications which have to be addressed within the specification. However, encouraging the retrieval and trust-verification of resources prior to loading them into a cache/server allows resolving references without further security concerns. The security considerations are handled outside of JRI, in whatever code or process locates, retrieves, and parses the resource into the form suitable for the cache/server.
This should be addressed explicitly in the JRI specification. I have noticed that not all users of "$ref" seem aware of the security concerns, but after discussing this with a friend who has 20 years of security experience it is clear to me that we need to ensure that JRI is usable without on-demand retrieval, and the security implications are clear.
Following up on some discussion in the most recent JSON Schema community call:
Part of the reason for specifying discovering, caching, and serving resources as part of JRI is to bring that cache/server inside the trust boundaries of the spec.
Retrieval of resources on demand has endless security implications which have to be addressed within the specification. However, encouraging the retrieval and trust-verification of resources prior to loading them into a cache/server allows resolving references without further security concerns. The security considerations are handled outside of JRI, in whatever code or process locates, retrieves, and parses the resource into the form suitable for the cache/server.
This should be addressed explicitly in the JRI specification. I have noticed that not all users of
"$ref"seem aware of the security concerns, but after discussing this with a friend who has 20 years of security experience it is clear to me that we need to ensure that JRI is usable without on-demand retrieval, and the security implications are clear.