Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove JSON Processing section #1298

Closed
wants to merge 1 commit into from
Closed

Remove JSON Processing section #1298

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 0 additions & 72 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4239,78 +4239,6 @@ <h2>HTTP</h2>
</p>
</section>

<section class="informative">
<h2>JSON Processing</h2>

<p>
While the media types describing conforming documents defined in this
specification always express JSON-LD, JSON-LD processing is not required to be
performed, since JSON-LD is JSON. Some scenarios where processing a
<a>verifiable credential</a> or a <a>verifiable presentation</a> as JSON is
desirable include, but are not limited to:
</p>

<ul>
<li>
Before securing or after verifying content
that requires <a href="https://csrc.nist.gov/glossary/term/data_integrity">data
integrity</a>, such as a
<a>verifiable credential</a> or <a>verifiable presentation</a>.
</li>
<li>
When performing JSON Schema validation, as described in Section
<a href="#data-schemas"></a>.
</li>
<li>
When serializing or deserializing <a>verifiable credentials</a> or
<a>verifiable presentations</a> into systems that store or index their contents.
</li>
<li>
When operating on <a>verifiable credentials</a> or <a>verifiable
presentations</a> in a software application, after verification or validation
is performed for securing mechanisms that require an understanding of
and/or processing of JSON-LD.
</li>
<li>
When an application chooses to process the media type using the `+json`
structured media type suffix.
</li>
</ul>

<p>
That is, JSON processing is allowed as long as the document being consumed or
produced is a <a>conforming document</a>. If JSON processing is desired, an
implementer is advised to follow the following rule:
</p>

<ul>
<li>
Ensure that all values associated with a `@context` property are in the
expected order, the contents of the context files match known good
cryptographic hashes for each file, and domain experts have deemed that the
contents are appropriate for the intended use case.
</li>
</ul>

<p>
Using static context files with a JSON Schema is one acceptable approach to
implementing the rule above. This can ensure proper term identification,
typing, and order, when a JSON document is processed as JSON-LD.
</p>

<p>
The rule above guarantees semantic interoperability between JSON and JSON-LD for
literal JSON keys mapped to URIs by the `@context` mechanism. While JSON-LD
processors will use the specific mechanism provided and can verify that all
terms are correctly specified, JSON-based processors implicitly accept the same
semantics without performing any JSON-LD transformations, but instead by
applying the above rules. In other words, the context in which the data exchange
happens is explicitly stated for both JSON and JSON-LD by using the same
mechanism. With respect to JSON-based processors, this is achieved in a
lightweight manner, without having to use JSON-LD processing libraries.
</p>

</section>
</section>

<section>
Expand Down