+
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
@@ -1392,7 +1392,7 @@ Identifiers
-
{
"@context": [
@@ -1463,7 +1463,7 @@ Types
-
{
"@context": [
@@ -1684,7 +1684,7 @@ Names and Descriptions
{
"@context": [
@@ -1732,7 +1732,7 @@ Names and Descriptions
+ title="Use of the name and description properties">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
@@ -1835,7 +1835,7 @@ Issuer
-
{
"@context": [
@@ -1862,7 +1862,7 @@ Issuer
{
"@context": [
@@ -1921,7 +1921,7 @@ Credential Subject
{
"@context": [
@@ -2020,7 +2020,7 @@ Validity Period
{
"@context": [
@@ -2094,7 +2094,7 @@ Status
+ title="Use of the status property">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
@@ -2127,7 +2127,7 @@ Status
+ title="Use of multiple entries for the status property">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
@@ -2253,7 +2253,7 @@ Data Schemas
+ title="Using the credentialSchema property to perform JSON schema validation">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
@@ -2321,7 +2321,7 @@ Securing Mechanisms
+ title="A verifiable credential using an embedded proof">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
@@ -3212,7 +3212,7 @@ Integrity of Related Resources
+ title="Use of the relatedResource and digestSRI properties">
"relatedResource": [{
"id": "https://www.w3.org/ns/credentials/v2",
"digestSRI":
@@ -3225,7 +3225,7 @@ Integrity of Related Resources
+ title="Use of the relatedResource and digestMultibase properties">
"relatedResource": [{
"id": "https://www.w3.org/ns/credentials/v2",
"digestMultibase": "uEres1usWcWCmW7uolIW2uA0CjQ8iRV14eGaZStJL73Vz"
@@ -3280,7 +3280,7 @@ Refreshing
+ title="Use of the refreshService property by an issuer">
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
@@ -3325,7 +3325,7 @@ Refreshing
Terms of Use
-Terms of use can be utilized by an [=issuer=] or a [=holder=] to
+Terms of use can be used by an [=issuer=] or a [=holder=] to
communicate the terms under which a [=verifiable credential=] or
[=verifiable presentation=] was issued. The [=issuer=] places their terms
of use inside the [=verifiable credential=]. The [=holder=] places their
@@ -3374,7 +3374,7 @@
Terms of Use
+ title="Use of the termsOfUse property by an issuer">
{
{
"@context": [
@@ -3432,9 +3432,9 @@ Terms of Use
This feature is expected to be used by government-issued [=verifiable
credentials=] to instruct digital wallets to limit their use to similar
-government organizations in an attempt to protect citizens from unexpected usage
+government organizations in an attempt to protect citizens from unexpected use
of sensitive data. Similarly, some [=verifiable credentials=] issued by private
-industry are expected to limit usage to within departments inside the
+industry are expected to limit use to within departments inside the
organization, or during business hours. Implementers are urged to read more
about this evolving feature in the appropriate section of the Verifiable
Credentials Implementation Guidelines [[?VC-IMP-GUIDE]] document.
@@ -3544,7 +3544,7 @@
Evidence
The `evidence` [=property=] provides information that is different from and
-information to the securing mechanism utilized. The `evidence` [=property=] is
+information to the securing mechanism used. The `evidence` [=property=] is
used to express supporting information, such as documentary evidence, related to
the [=verifiable credential=]. In contrast, the securing mechanism is used to
express machine-verifiable mathematical proofs related to the authenticity of
@@ -3800,7 +3800,7 @@
Representing Time
This specification attempts to increase the number of universally recognized
combinations of dates and times, and reduce the potential for
-misinterpretation of time values, by utilizing the
+misinterpretation of time values, by using the
`dateTimeStamp` construction first established by the [XMLSCHEMA11-2] specification. In
order to reduce misinterpretations between different time zones, all time values
@@ -3993,7 +3993,7 @@
Ecosystem Compatibility
a [=conforming document=].
-SHOULD ensure that all semantics utilized in the transformed
+SHOULD ensure that all semantics used in the transformed
[=conforming document=] follow best practices for Linked Data. See
Section [[[#getting-started]]], Section
[[[#extensibility]]], and Linked Data Best Practices [[?LD-BP]]
@@ -4004,7 +4004,7 @@ Ecosystem Compatibility
Readers are advised that a digital credential is only considered compatible with
the W3C Verifiable Credentials ecosystem if it is a [=conforming document=]
-and it utilizes at least one securing mechanism, as described by their
+and it uses at least one securing mechanism, as described by their
respective requirements in this specification. While some communities might call
some digital credential formats that are not [=conforming documents=]
"verifiable credentials", doing so does NOT make that digital credential
@@ -4273,10 +4273,10 @@
Notable JSON-LD Features
Restrictions on JSON-LD
-In order to increase interoperability, this specification restricts the usage of
+In order to increase interoperability, this specification restricts the use of
JSON-LD representations of the data model. JSON-LD compacted document
-form MUST be utilized for all representations of the data model using the
+form MUST be used for all representations of the data model using the
`application/vc` or `application/vp` media type.
@@ -4545,7 +4545,7 @@ Type-Specific Credential Processing
-General JSON-LD processing is defined as a mechanism that utilizes a
+General JSON-LD processing is defined as a mechanism that uses a
JSON-LD software library to process a [=conforming document=] by performing
various transformations.
Type-specific credential processing is defined as a lighter-weight
@@ -4628,7 +4628,7 @@
Algorithms
This section contains algorithms that can be used by implementations to perform
common operations, such as [=verification=]. Conformance requirements phrased as
-algorithms utilize normative concepts from the [[[INFRA]]] [[INFRA]]. See the
+algorithms use normative concepts from the [[[INFRA]]] [[INFRA]]. See the
section on Algorithm Conformance
in the [[[INFRA]]] for more guidance on implementation requirements.
@@ -5018,7 +5018,7 @@ Identifier-Based Correlation
Similarly, disclosing the [=credential=] identifier (as in
-[[[#example-usage-of-the-id-property]]]) can lead to situations where multiple
+[[[#example-use-of-the-id-property]]]) can lead to situations where multiple
[=verifiers=], or an [=issuer=] and a [=verifier=], can collude to correlate the
[=holder=].
@@ -5308,7 +5308,7 @@ Bearer Credentials
{
"@context": [
@@ -5593,11 +5593,11 @@ Patterns of Use
even compatible with necessary use. Sometimes, correlation is a requirement.
-For example, in some prescription drug monitoring programs, usage monitoring is
-a requirement. Enforcement entities need to be able to confirm that individuals
+For example, in some prescription drug monitoring programs, monitoring prescription
+use is a requirement. Enforcement entities need to be able to confirm that individuals
are not cheating the system to get multiple prescriptions for controlled
-substances. This statutory or regulatory need to correlate usage overrides
-individual privacy concerns.
+substances. This statutory or regulatory need to correlate prescription
+use overrides individual privacy concerns.
@@ -5609,8 +5609,8 @@
Patterns of Use
-Privacy violations of [=verifiable credential=] usage occur when unintended or
-unexpected correlation arises from the presentation of those
+Privacy violations related to the use of [=verifiable credentials=] occur when
+unintended or unexpected correlation arises from the presentation of those
[=verifiable credentials=].
@@ -6198,7 +6198,7 @@ Code Injection
processing language and base direction information.
-It increases the security attack surface when utilizing this data model,
+It increases the security attack surface when using this data model,
because naively processing HTML could result in the execution of a `script`
tag that an attacker injected at some point during the data production process.
@@ -6227,13 +6227,13 @@ Accessibility Considerations
makes this information unusable by a large subset of the population. It is
important to follow accessibility guidelines and standards, such as [[WCAG21]],
to ensure that all people, regardless of ability, can make use of this data.
-This is especially important when establishing systems utilizing cryptography,
+This is especially important when establishing systems using cryptography,
which have historically created problems for assistive technologies.
This section details the general accessibility considerations to take into
-account when utilizing this data model.
+account when using this data model.
@@ -6247,7 +6247,7 @@ Data First Approaches
-When utilizing this data model to create [=verifiable credentials=], it is
+When using this data model to create [=verifiable credentials=], it is
suggested that data model designers use a data first approach. For
example, given the choice of using data or a graphical image to depict a
[=credential=], designers should express every element of the image, such as
@@ -6285,7 +6285,7 @@
Internationalization Considerations
This section outlines general internationalization considerations to take into
-account when utilizing this data model and is intended to highlight specific
+account when using this data model and is intended to highlight specific
parts of the Strings on the Web: Language and Direction Metadata
document [[STRING-META]] that implementers might be interested in reading.
@@ -6441,9 +6441,9 @@ Validation
While this specification does not provide conformance criteria for the process
of the [=validation=] of [=verifiable credentials=] or
[=verifiable presentations=], readers might be curious about how the
-information in this data model is expected to be utilized by [=verifiers=]
+information in this data model is expected to be used by [=verifiers=]
during the process of [=validation=]. This section captures a selection of
-conversations held by the Working Group related to the expected usage of the
+conversations held by the Working Group related to the expected use of the
properties in this specification by [=verifiers=].
@@ -6781,7 +6781,7 @@ Base Context
It is strongly advised that all JSON-LD Context URLs used by an
-application utilize the same mechanism, or a functionally equivalent mechanism,
+application use the same mechanism, or a functionally equivalent mechanism,
to ensure end-to-end security. Implementations are expected to throw errors
if a cryptographic hash value for a resource does not match the expected hash
value.
@@ -7055,7 +7055,7 @@
Differences between Contexts, Types, and CredentialSchemas
value could make it more difficult for verifiers to inform the holder which
[=verifiable credential=] they require. When a [=verifiable credential=]
has multiple subtypes, listing all of them in the `type`
-property is sensible. The usage of the `type` property in a
+property is sensible. The use of the `type` property in a
[[JSON-LD11]] representation of a [=verifiable credential=] enables to enforce
the semantics of the [=verifiable credential=] because the machine is able to
check the semantics. With [[JSON-LD11]], the technology is not only describing the
@@ -7462,7 +7462,7 @@ Revision History
Ensure that `dateTimeStamp` is used for time values. Provide further guidance
-on proper usage of time values and timezones.
+on proper use of time values and timezones.
Make `validFrom` optional.
@@ -7560,7 +7560,7 @@ Revision History
Update previous normative references that pointed to RFC3339 for date-time
details to now normatively reference the date-time details described in
-XMLSCHEMA11-2 which more accurately reflects the usage in examples and
+XMLSCHEMA11-2 which more accurately reflect date-time use in examples and
libraries.