Skip to content

Improve security considerations including the role of cache/serve behavior #13

Open
@handrews

Description

@handrews

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.

Metadata

Metadata

Assignees

Labels

jriRelated to the JRI (JSON Referencing and Identification) proposalsecuritySecurity concerns

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions