You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
handrews
added
the
jri
Related to the JRI (JSON Referencing and Identification) proposal
label
Nov 16, 2022
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.The text was updated successfully, but these errors were encountered: