- Decentralized Identifiers, like any other technology, can be used to - enhance privacy as well as harm privacy. This section speaks to topics + Decentralized Identifiers, like many other technologies, can be used to + enhance privacy as well as to harm privacy. This section speaks to topics that implementers might consider when thinking about the privacy characteristics of their software systems.
@@ -1179,7 +1179,7 @@- It is the DID method implementer's responsibility to think about and + It is a DID method implementer's responsibility to think about and identify the extent to which personal data may be included in a DID document.
@@ -1192,21 +1192,19 @@- A DID method specification should have a section dedicated to personal - data covering the extent to + DID method specifiers are encouraged to include a specification section + dedicated to personal data, covering the extent to which information published on the corresponding ledger can be updated or deleted. - It should provide specific instructions of how to do so, if it is - possible. + Such a section could provide specific instructions of how to do so, + if it is possible. Otherwise, it should clearly state that it is not possible.
A DID method should avoid "phone home" or tracking characteristics that - would - permit tracing of a user in manner not understood or authorized by the - user - by some third party. + would enable a third party to track a user, in a manner not + understood and/or not authorized by the user.
@@ -1214,11 +1212,11 @@- Avoid reusing verification methods across DID Methods. + Avoid reusing verification methods across DID methods.
- Avoid reusing services with unique parameters across DID Methods. + Avoid reusing services with unique parameters across DID methods.
@@ -1230,9 +1228,9 @@
- A DID method implementer should rotate keys and identifiers as often as - possible - to avoid correlation + DID method implementations are encouraged to rotate keys and + identifiers as often as practical, + to avoid compromise and correlation, respectively.
@@ -1241,14 +1239,14 @@Consider formally modeling the privacy implications associated with - your implementation using + your DID method and/or implementation using t-closeness or other mechanisms.
- If your DID Method supports global enumeration and indexing, consider - exposing this information publicly. You may wish to provide alerts + If your DID method supports global enumeration and indexing, consider + exposing this fact publicly. You may wish to provide alerts similar to services that watch version control systems for sensitive information that is accidentally leaked.
@@ -1258,17 +1256,20 @@- Review any applicable local law when considering developing or - operating a decentralized identifier method. -
- -Consider GDPR.
- -Consider CCPA.
- -Consider EAR. -
+ Review any applicable local laws when considering developing or + operating a decentralized identifier method. Such local laws may + include, but are not limited to, the following: + + +Pay very close attention to the defense, cryptographic agility, and political - acceptability of any cryptography you rely on for DID Method security. + acceptability of any cryptography you rely on for DID method security.
@@ -1295,15 +1296,17 @@
- Avoid open source implementations that are declared a "defacto - standard", but lack open standard technical specifications. + Prefer technologies based on open standard technical specifications. + Avoid technologies declared de facto standards based on + particular implementations but lacking open standard technical + specifications.
- Support for legacy cryptography systems such as + Consider support for widely supported and historically prevalent + cryptography systems such as JOSE - and OpenPGP should be considered - due to their prevalence in existing systems. + and OpenPGP.
Competition, direct substitutability, interoperability, and mutual feature support are key to reducing the barriers to adoption of, and - increasing confidence in, your DID Method. + increasing confidence in, your DID method.
Avoid inventing "new features". Work with others to find a common way - to express any new features that are not unique to your DID Method. + to express any new features that are not unique to your DID method.
@@ -1327,7 +1330,7 @@
Transparency and openness in approaches related to security not only - lead to greater security, but promote interoprability and adoption. + lead to greater security, but promote interoperability and adoption.
- We recommend the user review - safecurves.cr.yp.to before - selecting elliptic curve types. A key note however, is that several - items on safecurves are less frequently updated. - In addition to safecurves you should always check the top level - standards - and any docs which superseed referenced standards in safecurves, + When selecting elliptic curve types, consider reviewing + SafeCurves. + However, note that some items on SafeCurves may be infrequently updated. + In addition to SafeCurves, check the top-level standards + and any documents which supercede referenced standards in SafeCurves, especially FIPS 186-4 and @@ -1369,27 +1370,27 @@
When in doubt in selection of a hashing algorithm, consult the - NIST documentation related to hash function selection, + NIST documentation related to hash function selection. + For new implementations, consider - SHA-3 as described in FIPS 202 - should be strongly considered for new implementations + SHA-3 as described in FIPS 202.
Consider using @@ -1400,33 +1401,34 @@
- The IETF document on + When selecting curves and other parameters for zero-knowledge proofs, + consider consulting the IETF document on - Pairing Friendly Curves - should be consulted when selecting curves for usage with zero - knowledge proofs, + href="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves"> + Pairing-Friendly Curves, especially to ensure that appropriate embedding degrees are selected, and that the resulting equivalent bit characteristics are sufficient.
- Avoid zero knowledge proofs as described in the + Avoid zero-knowledge proofs as described in the AnonCredDerivedCredentialv1. This proof format is coupled to specific ledger technologies, - similar to the concept of an ethereum virtual machine smart contract - only running on EVM compatible ledgers. Ledger-specific technologies + similar to the concept of an Ethereum Virtual Machine (EVM) + smart contract + only running on EVM-compatible ledgers. Ledger-specific technologies should be avoided when designing for portable, interoperable, and - open-standards–based zero knowledge proofs. + open-standards–based zero-knowledge proofs.
- Avoid storing credential schemas on ledgers. Many DID methods cannot - store information other than a DID Document, which reduces the direct + Avoid requiring credential schemas to be stored on ledgers. Many DID + methods cannot + store information other than a DID document, which reduces the direct interoperability, substitutability, and cost effectiveness of - solutions that make use of rare or poorly supported features such as + solutions that make use of rarely or poorly supported features such as credential schema definition storage.
- The addition of biometrics to other techniques can aid in certain tasks + The addition of biometrics to other techniques can aid certain tasks such as reauthentication. NIST SP - 800-63B - deals directly with digital identity and has several useful sections + 800-63B ("Digital Identity Guidelines: Authentication and + Lifecycle Management") + has several useful sections that address appropriate language for describing biometrics usage as well as techniques for incorporating biometrics into an approach for solving