|
267 | 267 | <body>
|
268 | 268 | <section id='abstract'>
|
269 | 269 | <p>
|
270 |
| -This specification provides normative and non-normative guidance on |
271 |
| -implementing and managing [=verifiable credentials=] and associated |
272 |
| -cryptographic practices. It emphasizes the importance of understanding and |
273 |
| -updating cryptographic systems and managing private signing keys with limited |
274 |
| -cryptoperiods. It discusses mechanisms for ensuring content integrity of |
275 |
| -linked external resources and highlights the risks of unsigned claims. |
276 |
| -Strategies are provided to mitigate man-in-the-middle (MITM), replay, and |
277 |
| -spoofing attacks, and to address issues related to credential atomization, |
278 |
| -validity periods, and device security. This specification also covers |
279 |
| -acceptable use of credentials, warns against code injection risks, and |
280 |
| -underscores the need for accessibility and internationalization |
281 |
| -considerations, advocating for a data-first approach and adherence to |
282 |
| -internationalization standards to ensure correct rendering of |
283 |
| -multilingual text. |
| 270 | +[=Credentials=] are integral to our daily lives: driver's licenses confirm |
| 271 | +our capability to operate motor vehicles; university degrees assert our level |
| 272 | +of education; and government-issued passports attest to our citizenship when |
| 273 | +traveling between countries. This specification provides a mechanism for |
| 274 | +expressing these sorts of [=credentials=] on the Web in a way that is |
| 275 | +cryptographically secure, privacy respecting, and machine verifiable. These |
| 276 | +[=credentials=] provide benefits to us when used in the physical world, but |
| 277 | +their use on the Web continues to be elusive. |
284 | 278 | </p>
|
285 | 279 | </section>
|
286 | 280 |
|
@@ -312,8 +306,8 @@ <h2>Introduction</h2>
|
312 | 306 |
|
313 | 307 | <p>
|
314 | 308 | [=Credentials=] are integral to our daily lives: driver's licenses confirm
|
315 |
| -our capability to operate motor vehicles, university degrees assert our level |
316 |
| -of education, and government-issued passports attest to our citizenship when |
| 309 | +our capability to operate motor vehicles; university degrees assert our level |
| 310 | +of education; and government-issued passports attest to our citizenship when |
317 | 311 | traveling between countries. This specification provides a mechanism for
|
318 | 312 | expressing these sorts of [=credentials=] on the Web in a way that is
|
319 | 313 | cryptographically secure, privacy respecting, and machine verifiable. These
|
@@ -4870,9 +4864,9 @@ <h3>Spectrum of Privacy</h3>
|
4870 | 4864 | For example, many people would prefer to remain anonymous when purchasing
|
4871 | 4865 | alcohol because the regulation is only to verify whether a purchaser is
|
4872 | 4866 | above a specific age. In contrast, when filling prescriptions written by
|
4873 |
| -a medical professional for a patient, the pharmacy must more strongly |
4874 |
| -identify both the prescriber and the patient. No single approach to |
4875 |
| -privacy works for all use cases. |
| 4867 | +a medical professional for a patient, the pharmacy is legally required |
| 4868 | +to more strongly identify both the prescriber and the patient. No single |
| 4869 | +approach to privacy works for all use cases. |
4876 | 4870 | </p>
|
4877 | 4871 |
|
4878 | 4872 | <p class="note"
|
@@ -4980,7 +4974,7 @@ <h3>Personally Identifiable Information</h3>
|
4980 | 4974 | [=Issuers=] are strongly advised to provide privacy-protecting [=verifiable
|
4981 | 4975 | credentials=] when possible — for example, by issuing `ageOver` [=verifiable
|
4982 | 4976 | credentials=] instead of `dateOfBirth` [=verifiable credentials=] for use when a
|
4983 |
| -[=verifier=] wants to determine whether an [=entity=] is 18 years of age. |
| 4977 | +[=verifier=] wants to determine whether an [=entity=] is at least 18 years of age. |
4984 | 4978 | </p>
|
4985 | 4979 |
|
4986 | 4980 | <p>
|
@@ -5095,7 +5089,7 @@ <h3>Signature-Based Correlation</h3>
|
5095 | 5089 | </li>
|
5096 | 5090 | <li>
|
5097 | 5091 | cryptographic material associated with the digital signature, such as
|
5098 |
| -a public key identifier. |
| 5092 | +a public key identifier |
5099 | 5093 | </li>
|
5100 | 5094 | </ul>
|
5101 | 5095 |
|
@@ -5519,7 +5513,7 @@ <h3>Aggregation of Credentials</h3>
|
5519 | 5513 | <p>
|
5520 | 5514 | The solution to the privacy implications of correlation or aggregation tends
|
5521 | 5515 | not to be technological in nature, but policy-driven instead. Therefore, if a
|
5522 |
| -[=holder=] wishes to avoid the aggregation of their information, they must |
| 5516 | +[=holder=] wishes to avoid the aggregation of their information, they need to |
5523 | 5517 | express this in the [=verifiable presentations=] they transmit, and
|
5524 | 5518 | by the [=holders=] and [=verifiers=] to whom they transmit their
|
5525 | 5519 | [=verifiable presentations=].
|
@@ -5728,17 +5722,17 @@ <h3>Data Theft</h3>
|
5728 | 5722 | transaction.
|
5729 | 5723 | </p>
|
5730 | 5724 | <p>
|
5731 |
| -Regulators are advised to reconsider audit requirements such that mechanisms |
5732 |
| -that better preserve privacy can be used to achieve similar enforcement and |
5733 |
| -audit capabilities. For example, audit-focused regulations that insist on the |
5734 |
| -collection and long-term retention of personally identifiable information can |
5735 |
| -cause harm to individuals and organizations if that same information is later |
5736 |
| -compromised and accessed by an attacker. The technologies |
5737 |
| -described by this specification enable [=holders=] to prove properties about |
5738 |
| -themselves and others more readily, reducing the need for long-term data |
5739 |
| -retention by [=verifiers=]. Alternatives include keeping logs that the |
5740 |
| -information was collected and checked, as well as random tests to ensure |
5741 |
| -that compliance regimes are operating as expected. |
| 5725 | +Regulators are advised to reconsider existing audit requirements such that |
| 5726 | +mechanisms that better preserve privacy can be used to achieve similar |
| 5727 | +enforcement and audit capabilities. For example, audit-focused regulations |
| 5728 | +that insist on the collection and long-term retention of personally |
| 5729 | +identifiable information can cause harm to individuals and organizations |
| 5730 | +if that same information is later compromised and accessed by an attacker. |
| 5731 | +The technologies described by this specification enable [=holders=] to |
| 5732 | +prove properties about themselves and others more readily, reducing the |
| 5733 | +need for long-term data retention by [=verifiers=]. Alternatives include |
| 5734 | +keeping logs that the information was collected and checked, as well as |
| 5735 | +random tests to ensure that compliance regimes are operating as expected. |
5742 | 5736 | </p>
|
5743 | 5737 | </section>
|
5744 | 5738 |
|
@@ -5823,7 +5817,7 @@ <h3>Issuer Cooperation Impacts on Privacy</h3>
|
5823 | 5817 | such features. In many cases, privacy protections which make use of zero-knowledge
|
5824 | 5818 | proofs, data minimization techniques, bearer credentials, abstract claims, and
|
5825 | 5819 | protections against signature-based correlation require active support by the
|
5826 |
| -[=issuer=], who must incorporate those capabilities into the [=verifiable |
| 5820 | +[=issuer=], who need to incorporate those capabilities into the [=verifiable |
5827 | 5821 | credentials=] they issue.
|
5828 | 5822 | </p>
|
5829 | 5823 | <p>
|
@@ -6741,8 +6735,8 @@ <h3>"Artificial Intelligence" and "Machine Learning"</h3>
|
6741 | 6735 | and/or "machine learning" might be capable of performing complex tasks at a
|
6742 | 6736 | level that meets or exceeds human performance. This might include tasks such as
|
6743 | 6737 | the acquisition and use of [=verifiable credentials=]. Using such tasks to
|
6744 |
| -distinguish between human and automated "bot" activity, as is |
6745 |
| -commonly done today with a <a href="https://en.wikipedia.org/wiki/CAPTCHA">CAPTCHA</a>, |
| 6738 | +distinguish between human and automated "bot" activity, as is commonly done |
| 6739 | +today with a <a href="https://en.wikipedia.org/wiki/CAPTCHA">CAPTCHA</a>, |
6746 | 6740 | for instance, might thereby cease to provide adequate or acceptable protection.
|
6747 | 6741 | </p>
|
6748 | 6742 |
|
|
0 commit comments