From 2c3859498c080ab0acba81b6daed2163568d023f Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner"
Decentralized Identifiers, like any other technology, can be used to
- enhance privacy as well as harm privacy. This section speaks to topics
+ 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.
Privacy Considerations
- 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 specifications are encouraged to have a 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 permit tracing of a user by a third party + in manner not understood or 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 possible, + to avoid correlation.
@@ -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.
@@ -1259,16 +1257,18 @@Review any applicable local law when considering developing or - operating a decentralized identifier method. -
- -Consider GDPR.
- -Consider CCPA.
- -Consider EAR. -
+ operating a decentralized identifier method. Consider 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,14 +1295,15 @@
- 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 standard based on + particular implementations but lacking open standards.
- Support for legacy cryptography systems such as + Consider support for legacy cryptography systems such as JOSE - and OpenPGP should be considered + and OpenPGP, due to their prevalence in existing systems.
@@ -1311,12 +1312,12 @@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 +1328,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.
@@ -1335,13 +1336,11 @@- 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 +1368,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,31 +1399,32 @@
- 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 credential schema definition storage. @@ -1442,11 +1442,12 @@
- 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
From 26b848ba9e49008e1fc8860b08a46f4fc6404eaa Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner"
A DID method should avoid "phone home" or tracking characteristics that
- would permit tracing of a user by a third party
+ would enable tracking of a user, without consent, by a third party
in manner not understood or authorized by the user.
- Decentralized Identifiers, like any other technology, can be used to
+ 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.
From c9d2bc6d460c8bf1615d5426b3b8d48bf9b262c5 Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner"
Prefer technologies based on open standard technical specifications.
- Avoid technologies declared de facto standard based on
- particular implementations but lacking open standards.
+ Avoid technologies declared de facto standards based on
+ particular implementations but lacking open standard technical
+ specifications.
From 5f088c6c253d37b0f7635fc81a1ab02c4781c902 Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner"
- Review any applicable local law when considering developing or
- operating a decentralized identifier method. Consider the following:
+ 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:
- DID method specifications are encouraged to 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.
Such a section could provide specific instructions of how to do so,
From 287afe9d2920b60d8c1867cf0bf977d0f3108abd Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner" Security Considerations
Anonymity
Compliance
From b5dc79571ed8382216870c9bcfe2f035a272c1a5 Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner"
Zero-Knowledge Proofs
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.
Security Considerations
- Consider support for legacy cryptography systems such as + Consider support for widely supported and historically prevalent + cryptography systems such as JOSE - and OpenPGP, - due to their prevalence in existing systems. + and OpenPGP.
DID method implementations are encouraged to rotate keys and - identifiers as often as possible, - to avoid correlation. + identifiers as often as practical, + to avoid compromise and correlation, respectively.
A DID method should avoid "phone home" or tracking characteristics that - would enable tracking of a user, without consent, by a third party - in manner not understood or authorized by the user. + would enable a third party to track a user, in a manner not + understood and/or not authorized by the user.