From 3cb409312d95ed5d3e24eca5221eaab6ed5c96d1 Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Mon, 30 Sep 2024 11:26:05 -0700 Subject: [PATCH] Fix grammar and flow in the Security Considerations section. Co-authored-by: Ted Thibodeau Jr --- index.html | 361 +++++++++++++++++++++++++++-------------------------- 1 file changed, 181 insertions(+), 180 deletions(-) diff --git a/index.html b/index.html index 0e972c0c6..e92195713 100644 --- a/index.html +++ b/index.html @@ -421,8 +421,8 @@

What is a Verifiable Credential?

as defined in this document. Verifiability of a credential does not imply the truth of [=claims=] encoded therein. Instead, upon establishing the authenticity and currency of a [=verifiable credential=] or -[=verifiable presentation=], a [=verifier=] validates the included claims using their own -business rules before relying on them. Such reliance only occurs after +[=verifiable presentation=], a [=verifier=] validates the included [=claims=] using +their own business rules before relying on them. Such reliance only occurs after evaluating the issuer, the proof, the subject, and the claims against one or more verifier policies.

@@ -490,7 +490,8 @@

Ecosystem Overview

three parties can use information from a logical verifiable data registry">
- The roles and information flows forming the basis for this specification. + The roles and information flows forming the basis for this + specification.
@@ -954,8 +955,9 @@

Credentials

'DtEhU3ljbEg8L38VWAfUA...'. ">
- Information graphs associated with a basic verifiable credential, using an [=enveloping proof=] - based on [[[VC-JOSE-COSE]]] [[?VC-JOSE-COSE]]. + Information graphs associated with a basic verifiable credential, + using an [=enveloping proof=] based on [[[VC-JOSE-COSE]]] + [[?VC-JOSE-COSE]].
@@ -1374,10 +1376,11 @@

Identifiers

in Section [[[#privacy-considerations]]] that create privacy concerns. Where privacy is a vital consideration, it is permissible to omit the `id` [=property=]. Some use cases do not need or explicitly need to omit, -the `id` [=property=]. Similarly, special attention is to be given to the choice between -publicly resolvable URLs and other forms of identifiers. Publicly resolvable URLs can -facilitate ease of verification and interoperability, yet they might also inadvertently -grant access to potentially sensitive information if not used judiciously. +the `id` [=property=]. Similarly, special attention is to be given to the choice +between publicly resolvable URLs and other forms of identifiers. Publicly +resolvable URLs can facilitate ease of verification and interoperability, yet +they might also inadvertently grant access to potentially sensitive information +if not used judiciously.

id
@@ -1721,9 +1724,9 @@

Names and Descriptions

title="@direction is not required for single-language strings"> The `@direction` property in the examples below is not required for the associated single-language strings, as their default directions are the -same as those set by the `@direction` value. We include the `@direction` property here -for clarity of demonstration and to make copy+paste+edit deliver functional -results. Implementers are encouraged to read the section on +same as those set by the `@direction` value. We include the `@direction` +property here for clarity of demonstration and to make copy+paste+edit deliver +functional results. Implementers are encouraged to read the section on String Internationalization in the [[[JSON-LD11]]] specification.

@@ -1999,8 +2002,8 @@

Validity Period

the past. Note that this value represents the earliest point in time at which the information associated with the `credentialSubject` [=property=] becomes valid. If a `validUntil` value also exists, the -`validFrom` value MUST express a point in time that is temporally the same or earlier -than the point in time expressed by the `validUntil` value. +`validFrom` value MUST express a point in time that is temporally the same or +earlier than the point in time expressed by the `validUntil` value.
validUntil
@@ -4109,28 +4112,28 @@

Securing Mechanism Specifications

A securing mechanism specification that creates a new type of [=embedded proof=] -MUST specify a [=property=] that relates the [=verifiable credential=] or [=verifiable -presentation=] to a [=proof graph=]. +MUST specify a [=property=] that relates the [=verifiable credential=] or +[=verifiable presentation=] to a [=proof graph=]. The requirements on the securing mechanism are as follow:

  • -The securing mechanism MUST define all terms used by the [=proof graph=]. For example, -the mechanism could define vocabulary specifications and `@context` files -in the same manner as they are utilized by this specification. +The securing mechanism MUST define all terms used by the [=proof graph=]. For +example, the mechanism could define vocabulary specifications and `@context` +files in the same manner as they are used by this specification.
  • -The securing mechanism MUST secure all graphs in the [=verifiable credential=] or the [=verifiable -presentation=], except for any [=proof graphs=] securing the [=verifiable credential=] -or the [=verifiable presentation=] itself. +The securing mechanism MUST secure all graphs in the [=verifiable credential=] +or the [=verifiable presentation=], except for any [=proof graphs=] securing +the [=verifiable credential=] or the [=verifiable presentation=] itself.

-The last requirement means that the securing mechanism secures the [=default graph=] and, -for [=verifiable presentations=], each [=verifiable credential=] of the presentation, together with -their respective [=proof graphs=]. +The last requirement means that the securing mechanism secures the [=default +graph=] and, for [=verifiable presentations=], each [=verifiable credential=] +of the presentation, together with their respective [=proof graphs=]. See also [[[#info-graph-vp]]] or [[[#info-graph-vp-mult-creds]]].

@@ -4284,11 +4287,11 @@

Restrictions on JSON-LD

documents=] are advised that interoperability might be reduced if JSON-LD keywords in the `@context` value are used to globally affect values in a [=verifiable credential=] or [=verifiable presentation=], such as by -setting either or both of the `@base` or `@vocab` keywords. For example, setting these values -might trigger a failure in a mis-implemented JSON Schema test of the `@context` -value in an implementation that is performing [=type-specific credential -processing=] and not expecting the `@base` and/or `@vocab` value to be -expressed in the `@context` value. +setting either or both of the `@base` or `@vocab` keywords. For example, setting +these values might trigger a failure in a mis-implemented JSON Schema test of +the `@context` value in an implementation that is performing [=type-specific +credential processing=] and not expecting the `@base` and/or `@vocab` value to +be expressed in the `@context` value.

@@ -4323,9 +4326,9 @@

Restrictions on JSON-LD

While this specification cautions against the use of `@vocab`, there are legitimate uses of the feature, such as to ease experimentation, development, and localized deployment. If an application developer wants to use `@vocab` in -production, which is advised against to reduce term collisions and leverage the benefits -of semantic interoperability, they are urged to understand that any use of `@vocab` will -disable reporting of "undefined term" errors, and +production, which is advised against to reduce term collisions and leverage the +benefits of semantic interoperability, they are urged to understand that any use +of `@vocab` will disable reporting of "undefined term" errors, and later use(s) will override any previous `@vocab` declaration(s). Different values of `@vocab` can change the semantics of the information contained in the document, so it is important to understand whether and how these changes will affect the @@ -5802,11 +5805,11 @@

Issuer Cooperation Impacts on Privacy

[=Verifiable credentials=] rely on a high degree of trust in [=issuers=]. The degree to which a [=holder=] might take advantage of possible privacy protections often depends strongly on the support an [=issuer=] provides for -such features. In many cases, privacy protections which make use of zero-knowledge -proofs, data minimization techniques, bearer credentials, abstract claims, and -protections against signature-based correlation require active support by the -[=issuer=], who need to incorporate those capabilities into the [=verifiable -credentials=] they issue. +such features. In many cases, privacy protections which make use of +zero-knowledge proofs, data minimization techniques, bearer credentials, +abstract claims, and protections against signature-based correlation require +active support by the [=issuer=], who need to incorporate those capabilities +into the [=verifiable credentials=] they issue.

It is crucial to note that [=holders=] not only depend on [=issuer=] @@ -5847,38 +5850,38 @@

Issuer Cooperation Impacts on Privacy

Security Considerations

-There are a number of security considerations that [=issuers=], -[=holders=], and [=verifiers=] should be aware of when processing data -described by this specification. Ignoring or not understanding the implications -of this section can result in security vulnerabilities. +[=Issuers=], [=holders=], and [=verifiers=] should be aware of a number of +security considerations when processing data described by this specification. +Ignoring or not understanding the implications of this section can result in +security vulnerabilities.

-While this section attempts to highlight a broad set of security considerations, -it is not a complete list. Implementers are urged to seek the advice of security -and cryptography professionals when implementing mission critical systems using -the technology outlined in this specification. +While this section highlights a broad set of security considerations, it is a +partial list. Implementers of mission-critical systems using the technology +described in this specification are strongly encouraged to consult security and +cryptography professionals for comprehensive guidance.

Cryptography Suites and Libraries

-Some aspects of the data model described in this specification can be -protected through the use of cryptography. It is important for implementers to -understand the cryptography suites and libraries used to create and process -[=credentials=] and [=presentations=]. Implementing and auditing -cryptography systems generally requires substantial experience. Effective +Cryptography can protect some aspects of the data model described in this +specification. It is important for implementers to understand the cryptography +suites and libraries used to create and process [=credentials=] and +[=presentations=]. Implementing and auditing cryptography systems generally +requires substantial experience. Effective red teaming can also help remove bias from security reviews.

-Cryptography suites and libraries have a shelf life and eventually fall to -new attacks and technology advances. Production quality systems need to take +Cryptography suites and libraries have a shelf life and eventually succumb to +new attacks and technological advances. Production quality systems need to take this into account and ensure mechanisms exist to easily and proactively upgrade -expired or broken cryptography suites and libraries, and to invalidate -and replace existing [=credentials=]. Regular monitoring is important to +expired or broken cryptography suites and libraries, and to invalidate and +replace existing [=credentials=]. Regular monitoring is important to ensure the long term viability of systems processing [=credentials=].

@@ -5886,14 +5889,14 @@

Cryptography Suites and Libraries

Key Management

-The security of most digital signature algorithms, which are used to secure -[=verifiable credentials=] and [=verifiable presentations=], is dependent -on the quality and protection of their private signing keys. Guidance -in the management of cryptographic keys is a large subject and the reader is -referred to [[NIST-SP-800-57-Part-1]] for more extensive recommendations and -discussion. As strongly recommended in both [[FIPS-186-5]] and +The security of most digital signature algorithms, used to secure [=verifiable +credentials=] and [=verifiable presentations=], depends on the quality and +protection of their private signing keys. The management of +cryptographic keys encompasses a vast and complex field. For comprehensive +recommendations and in-depth discussion, readers are directed to +[[NIST-SP-800-57-Part-1]]. As strongly recommended in both [[FIPS-186-5]] and [[NIST-SP-800-57-Part-1]], a private signing key is not to be used for multiple -purposes, for example, a private signing key is not to be used for encryption +purposes; for example, a private signing key is not to be used for encryption as well as signing.

@@ -5902,8 +5905,8 @@

Key Management

a cryptoperiod is "the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect." [[NIST-SP-800-57-Part-1]] gives extensive -guidance on cryptoperiods for different key types under different situations, -and generally recommends a 1-3 year cryptoperiod for a private signing key. +guidance on cryptoperiods for different key types under various conditions +and recommends a one to three year cryptoperiod for a private signing key.

To deal with potential private key compromises, [[NIST-SP-800-57-Part-1]] @@ -5918,30 +5921,31 @@

Key Management

Content Integrity Protection

-[=Verifiable credentials=] often contain URLs to data that resides outside of -the [=verifiable credential=] itself. Linked content that exists outside a -[=verifiable credential=], such as images, JSON-LD extension contexts, -JSON Schemas, and other machine-readable data, are not protected by default +[=Verifiable credentials=] often contain URLs to data that resides outside +the [=verifiable credential=]. Linked content that exists outside a +[=verifiable credential=] — such as images, JSON-LD extension contexts, +JSON Schemas, and other machine-readable data — is not protected against tampering because the data resides outside of the protection of the securing mechanism on the [=verifiable credential=].

-This specification provides an optional mechanism, contained in Section -[[[#integrity-of-related-resources]]], that is capable of ensuring content -integrity for external resources. While this mechanism need not be utilized -for external resources that do not affect the security of the -[=verifiable credential=], it is strongly suggested for external resources -that could result in a security issue if the external content changes. +Section [[[#integrity-of-related-resources]]] of this specification provides an +optional mechanism for ensuring content integrity of external +resources. This mechanism is not necessary for external resources that do not +impact the [=verifiable credential=]'s security. However, its implementation +is crucial for external resources where content changes could potentially +introduce security vulnerabilities.

-Implementers are urged to understand how links to external machine-readable -content that are not content-integrity protected could result in successful -attacks against their applications, and utilize the content integrity -protection mechanism provided by this specification if a security issue could -occur if the external resource is changed. +Implementers need to recognize the potential security risks associated with +unprotected URLs of external machine-readable content. Such vulnerabilities +could lead to successful attacks on their applications. Where changes to +external resources might compromise security, implementers will benefit by +employing the content integrity protection mechanism outlined in this +specification.

@@ -5950,12 +5954,11 @@

Content Integrity Protection

Unsigned Claims

-This specification allows [=credentials=] to be produced that are not secured by -signatures or proofs of any kind. These classes of [=credential=] are often -useful for intermediate storage or self-asserted information, which is -analogous to filling out a form on a web page. Implementers ought to be aware -that these [=credential=] types are not [=verifiable=] because the -authorship either is not known or cannot be trusted. +This specification enables the creation of [=credentials=] without signatures +or proofs. These [=credential=] classes are often useful for intermediate +storage or self-asserted information, analogous to filling out a form on a web +page. Implementers ought to be aware that these [=credential=] types are not +[=verifiable=] because the authorship either is unknown or cannot be trusted.

@@ -5967,9 +5970,9 @@

Man-in-the-Middle (MITM), Replay, and Cloning Attacks

Man-in-the-Middle (MITM), replay, and spoofing attacks. -Both online and offline use cases might be susceptible to these types of -attacks, where an adversary intercepts, modifies, re-uses, and/or replicates the -[=verifiable credential=] data during transmission or storage. +Both online and offline use cases might be susceptible to these attacks, where +an adversary intercepts, modifies, re-uses, and/or replicates the [=verifiable +credential=] data during transmission or storage.

Man-in-the-Middle (MITM) Attack

@@ -5978,22 +5981,23 @@

Man-in-the-Middle (MITM) Attack

[=verifiable presentation=] and not the target of a man-in-the-middle attack. Some securing -mechanisms, like [[VC-JOSE-COSE]] or [[VC-DATA-INTEGRITY]], provide an -option to specify the intended audience or domain of a [=presentation=], -which can help reduce this risk. +mechanisms, like [[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]] and +[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]], provide an +option to specify a [=presentation=]'s intended audience or domain, which can +help reduce this risk.

-Alternate approaches such as token binding [[RFC8471]], which ties the request -for a [=verifiable presentation=] to the response, can secure the protocol. +Other approaches, such as token binding [[RFC8471]], which ties the request for +a [=verifiable presentation=] to the response, can help secure the protocol. Any unsecured protocol is susceptible to man-in-the-middle attacks.

Replay Attack

-A [=verifier=] might wish to ensure that a [=verifiable presentation=] is -not used more than a certain number of times. For example, a [=verifiable -credential=] representing an event ticket might allow entry to multiple -individuals if presented multiple times, undermining the purpose of the ticket +A [=verifier=] might wish to limit the number of times that +[=verifiable presentation=] can be used. For example, multiple individuals +presenting the same [=verifiable credential=] representing an event ticket +might be granted entry to the event, undermining the purpose of the ticket from the perspective of its [=issuer=]. To prevent such replay attacks, [=verifiers=] require [=holders=] to include additional security measures in their [=verifiable presentations=]. Examples include the following: @@ -6013,8 +6017,8 @@

Replay Attack

Spoofing Attack

-A [=verifier=] has a vested interest in knowing that a [=holder=] is -authorized to present the claims inside of a [=verifiable presentation=]. +[=Verifiers=] might have a vested interest in knowing that a [=holder=] is +authorized to present the [=claims=] inside of a [=verifiable presentation=]. While the data model outlines the structure and data elements necessary for a [=verifiable credential=], it does not include a mechanism to ascertain the authorization of presented [=credentials=]. To address this concern, @@ -6029,25 +6033,24 @@

Bundling Dependent Claims

It is considered best practice for [=issuers=] to atomize information in a -[=credential=], or use a signature scheme that allows for selective -disclosure. In the case of atomization, if it is not done securely by the -[=issuer=], the [=holder=] might bundle together different -[=credentials=] in a way that was not intended by the [=issuer=]. -

- -

-For example, a university might issue two [=verifiable credentials=] to a -person, each containing two [=properties=], which must be taken together -to designate the "role" of that person in a given "department", such as "Staff -Member" in the "Department of Computing", or "Post Graduate Student" in the -"Department of Economics". If these [=verifiable credentials=] are atomized -to put only one of these [=properties=] into each [=credential=] , then -the university would issue four [=credentials=] to the person, each -containing one of the following designations: "Staff Member", "Post Graduate -Student", "Department of Computing", and "Department of Economics". The -[=holder=] might then transfer the "Staff Member" and "Department of -Economics" [=verifiable credentials=] to a [=verifier=], which together -would comprise a false [=claim=]. +[=credential=] or use a signature scheme that allows for selective +disclosure. When atomizing information, if it is not done securely by the +[=issuers=], the [=holders=] might bundle together [=claims=] from different +[=credentials=] in ways that the [=issuers=] did not intend. +

+ +

+Consider a university issuing two [=verifiable credentials=] to an individual. +Each [=credential=] contains two properties that, when combined, indicate the +person's "role" in a specific "department." For instance, one [=credential=] +pair might designate "Staff Member" in the "Department of Computing," while +another could signify "Post Graduate Student" in the "Department of Economics." +Atomizing these [=verifiable credentials=] results in the university issuing +four separate [=credentials=] to the individual. Each [=credential=] contains +a single designation: "Staff Member", "Post Graduate Student", "Department of +Computing", or "Department of Economics". The [=holder=] might then present +the "Staff Member" and "Department of Economics" [=verifiable credentials=] to +a [=verifier=], which, together, would comprise a false [=claim=].

@@ -6055,16 +6058,15 @@

Bundling Dependent Claims

Highly Dynamic Information

-When [=verifiable credentials=] are issued for highly dynamic information, -implementers should ensure the validity periods are set appropriately. Validity -periods longer than the timeframe where the [=verifiable credential=] is -meant for use might create exploitable security vulnerabilities. Validity +When [=verifiable credentials=] contain highly dynamic information, careful +consideration of validity periods becomes crucial. Issuing [=verifiable +credentials=] with validity periods that extend beyond their intended use creates +potential security vulnerabilities that malicious actors could exploit. Validity periods shorter than the timeframe where the information expressed by the [=verifiable credential=] is expected to be used creates a burden on -[=holders=] and [=verifiers=]. It is therefore important to set validity -periods for [=verifiable credentials=] that are appropriate to the use case -and the expected lifetime for the information contained in the -[=verifiable credential=]. +[=holders=] and [=verifiers=]. It is, therefore, important to set validity +periods for [=verifiable credentials=] appropriate to the use case and the +expected lifetime of the information contained in the [=verifiable credential=].

@@ -6072,10 +6074,10 @@

Highly Dynamic Information

Device Theft and Impersonation

-When [=verifiable credentials=] are stored on a device and that -device is lost or stolen, it might be possible for an attacker to gain access -to systems using the victim's [=verifiable credentials=]. Ways to mitigate -this type of attack include: +Storing [=verifiable credentials=] on a device poses risks if the device is +lost or stolen. An attacker gaining possession of such a device potentially +acquires unauthorized access to systems using the victim's [=verifiable +credentials=]. Ways to mitigate this type of attack include:

    @@ -6101,47 +6103,45 @@

    Device Theft and Impersonation

    Furthermore, instances of impersonation can manifest in various forms, -including situations where an [=entity=] attempts to disavow their actions. -Elevating the level of trust and security within the realm of [=verifiable -credentials=] entails more than just averting impersonation; it involves the -implementation of non-repudiation mechanisms. These mechanisms solidify an -[=entity's=] responsibility for their actions or transactions, thereby -reinforcing accountability and deterring malicious behaviors. The attainment of -non-repudiation is a multifaceted endeavor, encompassing an array of techniques -ranging from securing mechanisms, proofs of -possession, and authentication schemes in a variety of protocols designed to -foster trust and reliability. +including situations where an [=entity=] attempts to disavow its actions. +Elevating trust and security within the realm of [=verifiable credentials=] +entails more than averting impersonation; it also involves implementing +non-repudiation mechanisms. These mechanisms solidify an [=entity's=] +responsibility for its actions or transactions, reinforcing accountability and +deterring malicious behavior. Attainment of non-repudiation is a +multifaceted endeavor, encompassing an array of techniques including +securing mechanisms, proofs of possession, +and authentication schemes in various protocols designed to foster trust and +reliability.

    Acceptable Use

    -Ensuring that there is alignment between an [=entity's=] actions, such as -[=presentation=], and the intended purpose of those actions, is of -importance. It involves having the authorization to make use of [=verifiable -credentials=] as well as using [=credentials=] in a manner that adheres to -their designated scope(s) and objective(s). Two critical aspects that arise -within this context are Unauthorized Use and Inappropriate Use. +Ensuring alignment between an [=entity's=] actions — such as [=presentation=], +and the intended purpose of those actions — is essential. It involves having the +authorization to use [=verifiable credentials=] and using [=credentials=] in a +manner that adheres to their designated scope(s) and objective(s). Two critical +aspects in this context are Unauthorized Use and Inappropriate Use.

    Unauthorized Use

    -Any attempt by entities to make use of [=verifiable credentials=] and -[=verifiable presentations=] outside of their intended use can be seen as -unauthorized. One class of unauthorized use is a confidentiality -violation. Consider an example where a [=holder=] shares a [=verifiable -presentation=] with a [=verifier=] to establish their age and residency -status. If the [=verifier=] then proceeds to exploit the [=holder's=] data -without proper consent, such as by selling the data to a data broker, that -would constitute an unauthorized use of the data, violating an expectation of -privacy that the [=holder=] might have in the transaction. +Entities using [=verifiable credentials=] and [=verifiable presentations=] +beyond their intended purpose are engaging in unauthorized activity. One class +of unauthorized use is a confidentiality violation. Consider a [=holder=] +that shares a [=verifiable presentation=] with a [=verifier=] +to establish their age and residency status. If the [=verifier=] then proceeds +to employ the [=holder's=] data without proper consent, such as by selling the +data to a data broker, that would constitute an unauthorized use of the data, +violating an expectation of privacy that the [=holder=] might have in the +transaction.

    -Similarly, an [=issuer=] could make use of a -termsOfUse property to stipulate how and when a -credential might be used. A [=holder=] using credentials outside of the -scopes defined in the `termsOfUse` would be considered unauthorized -use. +Similarly, an [=issuer=] can employ a termsOfUse +property to specify how and when a [=holder=] might be permitted and expected +to use a [=credential=]. A [=holder=] using [=credentials=] outside of the +scope(s) defined in the `termsOfUse` would be considered to be unauthorized.

    @@ -6153,15 +6153,15 @@

    Inappropriate Use

    While valid cryptographic signatures and successful status checks signify the reliability of [=credentials=], they do not signify that all [=credentials=] are interchangeable for all contexts. It is crucial that -[=verifiers=] also validate any claims which -might be relevant, considering the source and nature of the claim as well as -privilege or service for which the credential is presented. +[=verifiers=] also validate any relevant [=claims=], +considering the source and nature of the [=claim=] alongside the purpose +for which the [=holder=] presents the [=credential=].

    For instance, in scenarios where a certified medical diagnosis is required, a self-asserted [=credential=] carrying the necessary data might not suffice -because it lacks validity from an authoritative medical source. To ensure the -propriety of [=credential=] use, stakeholders are urged to assess the +because it lacks validity from an authoritative medical source. To ensure proper +[=credential=] use, stakeholders need to assess the credential's relevance and authority within the specific context of their intended application.

    @@ -6171,25 +6171,25 @@

    Inappropriate Use

    Code Injection

    -It is possible for data in [=verifiable credentials=] to include -executable code or scripting languages. Authors of verifiable credentials are -advised to avoid doing so, unless necessary, and the risks have been mitigated -to the extent possible. +Data in [=verifiable credentials=] can include injectable code or code from +scripting languages. Authors of [=verifiable credentials=] benefit from avoiding +such inclusions unless necessary and only after mitigating associated risks to +the fullest extent possible. +

    -For example, when a single natural language string contains multiple languages -or annotations, the contents of the string might require additional structure or -markup in order to be presented correctly. It is possible to use markup -languages, such as HTML, to label spans of text in different languages or to -supply string-internal markup needed for the proper display of [=bidirectional -text=]. It is also possible to use the `rdf:HTML` datatype to encode such values -accurately in JSON-LD. +For example, a single natural language string containing multiple languages or +annotations often requires additional structure or markup for correct +presentation. Markup languages, such as HTML, can label text spans in different +languages or supply string-internal markup needed to display [=bidirectional +text=] properly. It is also possible to use the `rdf:HTML` datatype to encode +such values accurately in JSON-LD.

    Despite the ability to encode information as HTML, implementers are strongly -discouraged from doing so, for the following reasons: +discouraged from doing so for the following reasons:

      @@ -6208,9 +6208,10 @@

      Code Injection

      If implementers feel they need to use HTML, or other markup languages capable of containing executable scripts, to address a specific use case, they are advised to analyze how an attacker could use the markup to mount injection attacks -against a consumer of the markup, and then deploy mitigations against the -identified attacks, such as running the HTML rendering engine in a sandbox with -no ability to access the network. +against a consumer of the markup. This analysis should be followed by the +proactive deployment of mitigations against the identified attacks, such as +running the HTML rendering engine in a sandbox with no ability to access the +network.