Skip to content

Edit Privacy and Considerations sections #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open

Edit Privacy and Considerations sections #37

Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
2c38594
Edit Privacy and Considerations sections
clehner Nov 30, 2021
26b848b
Improve wording about third-party tracking
clehner Dec 3, 2021
5c7153e
Adjust technology comparison regarding privacy
clehner Dec 3, 2021
c9d2bc6
More consistency with standards and specifications
clehner Dec 3, 2021
5f088c6
Improve reference to laws
clehner Dec 3, 2021
b5dc795
Reduce use of metonymy
clehner Dec 3, 2021
287afe9
Attribute feature rarity to support
clehner Dec 3, 2021
c539bca
Positively characterize prevalence
clehner Dec 3, 2021
45d8529
Adjust key/identifier rotation encouragement
clehner Dec 10, 2021
5b85935
Add comma after link
clehner Dec 10, 2021
009bb6a
Reword sentence about tracking
clehner Dec 21, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
139 changes: 71 additions & 68 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1161,8 +1161,8 @@ <h2>Benefits</h2>
<h2>Privacy Considerations</h2>

<p>
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.
</p>
Expand All @@ -1179,7 +1179,7 @@ <h3>
</p>

<p>
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.
</p>
Expand All @@ -1192,33 +1192,31 @@ <h3>
</p>

<p>
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.
</p>

<p>
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.
</p>
</section>

<section class="informative">
<h3>Avoid correlation</h3>

<p class="advisement">
Avoid reusing verification methods across DID Methods.
Avoid reusing verification methods across DID methods.
</p>

<p class="advisement">
Avoid reusing services with unique parameters across DID Methods.
Avoid reusing services with unique parameters across DID methods.
</p>

<p>
Expand All @@ -1230,9 +1228,9 @@ <h3>Avoid correlation</h3>
</p>

<p>
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.
</p>
</section>

Expand All @@ -1241,14 +1239,14 @@ <h3>Anonymity</h3>

<p>
Consider formally modeling the privacy implications associated with
your implementation using
your DID method and/or implementation using
<a href="https://en.wikipedia.org/wiki/T-closeness">t-closeness</a> or
other mechanisms.
</p>

<p>
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.
</p>
Expand All @@ -1258,17 +1256,20 @@ <h3>Anonymity</h3>
<h3>Compliance</h3>

<p>
Review any applicable local law when considering developing or
operating a decentralized identifier method.
</p>

<p>Consider <a href="https://gdpr.eu/">GDPR</a>.</p>

<p>Consider <a href="https://oag.ca.gov/privacy/ccpa">CCPA</a>.</p>

<p>Consider <a
href="https://www.bis.doc.gov/index.php/policy-guidance/encryption">EAR</a>.
</p>
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:
</p>

<ul>
<li><a href="https://gdpr.eu/">General Data Protection Regulation
(GDPR)</a></li>
<li><a href="https://oag.ca.gov/privacy/ccpa">California Consumer
Privacy Act (CCPA)</a></li>
<li><a
href="https://www.bis.doc.gov/index.php/policy-guidance/encryption">
Encryption and Export Administration Regulations (EAR)</a></li>
</ul>
</section>
</section>

Expand All @@ -1285,7 +1286,7 @@ <h2>Security Considerations</h2>
<p>
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.
</p>

<p>
Expand All @@ -1295,28 +1296,30 @@ <h2>Security Considerations</h2>
</p>

<p class="advisement">
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 <em>de facto</em> standards based on
particular implementations but lacking open standard technical
specifications.
</p>

<p class="advisement">
Support for legacy cryptography systems such as
Consider support for widely supported and historically prevalent
cryptography systems such as
<a href="https://www.iana.org/assignments/jose/jose.xhtml">JOSE</a>
and <a href="https://www.openpgp.org/">OpenPGP</a> should be considered
due to their prevalence in existing systems.
and <a href="https://www.openpgp.org/">OpenPGP</a>.
</p>

<section class="informative">
<h3>Vendor Lock In</h3>
<p>
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.
</p>

<p>
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.
</p>

<p>
Expand All @@ -1327,21 +1330,19 @@ <h3>Vendor Lock In</h3>

<p class="advisement">
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.
</p>
</section>

<section class="informative">
<h3>Digital Signatures</h3>

<p class="advisement">
We recommend the user review
<a href="https://safecurves.cr.yp.to/">safecurves.cr.yp.to</a> 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
<a href="https://safecurves.cr.yp.to/">SafeCurves</a>.
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
<a href="https://csrc.nist.gov/publications/detail/fips/186/4/final">
FIPS 186-4</a> and
Expand Down Expand Up @@ -1369,27 +1370,27 @@ <h3>Hashing Algorithms</h3>
<p class="advisement">
When in doubt in selection of a hashing algorithm, consult the
<a href="https://csrc.nist.gov/projects/hash-functions">
NIST documentation</a> related to hash function selection,
NIST documentation</a> related to hash function selection.
For new implementations, consider
<a href="https://csrc.nist.gov/publications/detail/fips/202/final">
SHA-3 as described in FIPS 202</a>
should be strongly considered for new implementations
SHA-3 as described in FIPS 202</a>.
</p>
</section>

<section class="informative">
<h3>Randomness</h3>
When making an implemention carefully consider how you are sourcing
When making an implemention, carefully consider how you are sourcing
random numbers. Consult
<a href="https://datatracker.ietf.org/doc/html/RFC4086">RFC 4086:
Randomness Requirements for Security</a>
when selecting an approach to get random bits, and pay careful attention
to the platform and any underlying hardware that may be in use as multiple
when selecting an approach to get random bits. Pay careful attention
to the platform and any underlying hardware that may be in use. Multiple
attacks have been performed in the wild due to improper selection of
random values in key material and other aspects of cryptography.
</section>

<section class="informative">
<h3>Zero Knowledge Proofs</h3>
<h3>Zero-Knowledge Proofs</h3>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not a comment on @clehner 's excellent editorial work.

Why does the DID Implementation Guide talk about zero-knowledge proofs at all? Perhaps to the extent that an issuer may wish to use a DID Document to publish the verification key for a zero-knowledge proof–capable VC, but beyond that, the information in this section seems to relate little to DIDs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DID documents are to contain such crypto material as may be necessary to communicate with the entity identified by that DID. DID method specifiers and implementers may use ZKPs for these purposes, which possibility I think makes this section just as relevant as any of the others here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really, my concern with the section is not that it talks about ZKPs and how they may be used with DIDs, my concern is that it doesn't.

The guidance here is to 1) use proper curves for ZKPs, 2) not use ZKP proof formats tied to specific ledger technology, and 3) not store schemas on ledgers.
What does this guidance have to do with DIDs?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brentzundel -- This should perhaps become a new issue of its own?


<p>
Consider using
Expand All @@ -1400,33 +1401,34 @@ <h3>Zero Knowledge Proofs</h3>
</p>

<p class="advisement">
The IETF document on
When selecting curves and other parameters for zero-knowledge proofs,
consider consulting the IETF document on
<a
href="https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-10.txt">
Pairing Friendly Curves
</a> 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</a>,
especially to ensure that appropriate embedding degrees are selected,
and that
the resulting equivalent bit characteristics are sufficient.
</p>

<p>
Avoid zero knowledge proofs as described in the
Avoid zero-knowledge proofs as described in the
<a
data-cite="VC-DATA-MODEL#example-25-a-verifiable-presentation-that-supports-cl-signatures">AnonCredDerivedCredentialv1</a>.
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&ndash;based zero knowledge proofs.
open-standards&ndash;based zero-knowledge proofs.
</p>

<p>
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.
</p>
</section>
Expand All @@ -1442,11 +1444,12 @@ <h3>Biometrics</h3>
</p>

<p class="advisement">
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.
<a href="https://pages.nist.gov/800-63-3/sp800-63b.html">NIST SP
800-63B</a>
deals directly with digital identity and has several useful sections
800-63B ("Digital Identity Guidelines: Authentication and
Lifecycle Management")</a>
has several useful sections
that address appropriate language for describing biometrics usage as
well
as techniques for incorporating biometrics into an approach for solving
Expand Down