Skip to content
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

Add Use Cases and Requirements #103

Merged
merged 8 commits into from
Oct 20, 2024
Merged

Add Use Cases and Requirements #103

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
6e4a603
Add use cases to introduction.
msporny Oct 12, 2024
a2af418
Add requirements based on use cases.
jandrieu Oct 12, 2024
120dc1f
Refer to DID Use Cases for further commentary.
msporny Oct 12, 2024
db7281e
Focus intro on advantages of asymmetric cryptography.
msporny Oct 13, 2024
4b02bcd
Fix grammar and flow in use cases and requirements.
msporny Oct 20, 2024
6ad135b
Add use case for issuing and presenting claims.
msporny Oct 20, 2024
8dac975
Add section on cryptographic verification.
msporny Oct 20, 2024
7a2f27d
Make introductory paragraph use simpler language.
msporny Oct 20, 2024
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
167 changes: 162 additions & 5 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -312,20 +312,177 @@

<section class="informative">
<h2>Introduction</h2>

<p>
Digital signatures, based on
<a href="https://en.wikipedia.org/wiki/Public-key_cryptography">asymmetric
cryptography</a>, can be used to make [=authentication=] and [=authorization=]
schemes more difficult for adversaries to compromise. However, one shortcoming
of digital signatures is the challenge in distributing necessary information,
such as public cryptographic keys and revocation information, to those who need
to verify the security of a digital signature.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
to verify the security of a digital signature.
to verify the security of a digital signature. Another potential shortcoming is notifying the holder of a public key when it should no longer be used.

Either this or the above, since the problem is not only disseminating the public keys. It is the whole management lifecycle of them.

Copy link
Member

Choose a reason for hiding this comment

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

I don't understand how this is "another" "potential" shortcoming. I don't see any other (potential or definite) shortcomings discussed in the prior text. This suggestion needs more work before it should be considered ready to merge.

Copy link
Member Author

Choose a reason for hiding this comment

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

I attempted to make the language simpler in 7a2f27d.

</p>

<p>
A [=controller document=] is a set of data that specifies one or more
relationships between a [=controller=] and a set of data, such as a set of
public cryptographic keys. The [=controller document=] contains [=verification
relationships=] that explicitly permit the use of certain [=verification
methods=] for specific purposes.
relationships between an identifier that is controlled by a [=controller=] and a
Copy link
Contributor

Choose a reason for hiding this comment

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

There's another PR out there #102 that has text that conflicts with this (I think).

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this text will just re-use what's in #102 eventually.

set of data, such as a set of public cryptographic keys. The [=controller
document=] contains [=verification relationships=] that explicitly permit the
use of certain [=verification methods=] for specific purposes.
</p>

<p>
It is expected that other specifications, such as [[[?DID-CORE]]], will profile
the features that are defined in this specification, requiring and/or
recommending the use of some and prohibiting and/or deprecating the use of
others.
</p>

<section>
<h3>Use Cases</h3>
<p>
The use cases below illustrate the need for this specification.
While many other related use cases exist, such as those in [[[DID-USE-CASES]]]
and [[[VC-USE-CASES]]], those described below are the main scenarios that this
specification is designed to address.
</p>

<section class="notoc">
<h4>Globally Unique Identifiers</h4>

<p>
Lemmy runs multiple enterprise portals that manage large amounts of sensitive
data submitted by people working for a variety of organizations. He would like
to use identifiers for entities in the databases that are provided by
his customers and do not depend on easily phishable information such as
email addresses and passwords.
</p>
</section>

<section class="notoc">
<h4>Cryptographic Verification</h4>

<p>
Lemmy would like to ensure that his customers prove control over their
identifiers &mdash; for example, by using public/private key cryptography
&mdash; in order to increase security related to who is allowed to access and
update each organization's data.
</p>
</section>

<section class="notoc">
<h4>Cryptographic Purpose</h4>

<p>
Stef, who operates a high security service, would like to ensure that certain
cryptographic keys used by his customers can only be used for specific purposes
(such as encryption, authorization, and/or authentication) to enable different
levels of access and protection for each type of cryptographic key.
</p>
</section>

<section class="notoc">
<h4>Service Engagement</h4>

<p>
Marge, a software developer, would like to publicly advertise ways in which
other people on the Web can reach her through various communication services she
uses based on her globally unique identifier(s).
</p>
</section>

<section class="notoc">
<h4>Extensibility</h4>

<p>
Cory, a systems architect, would like to extend the use cases described in this
section in a way that provides new functionality without creating conflicts
with extensions being added by others.
</p>
</section>

<section class="notoc">
<h4>Issue and Present Claims</h4>

<p>
Neru would like to issue digital credentials on behalf of her company that
contain claims about their employees. The claims that are made need to use
identifiers that are cryptographically attributable back to Neru's company and
need to allow for the holder's of those credentials to be able to
cryptographically authenticate themselves when they present the credential.
</p>
</section>

</section>

<section>
<h3>Requirements</h3>

<p>
The following requirements are derived from the use cases described earlier in
this specification. Additional requirements which could lead to a more
decentralized solution can be found in [[[DID-USE-CASES]]].
</p>

<dl>
<dt>1. Guaranteed Unique Identifier</dt>
<dd>
Identifiers are globally unique with no possibility of duplication.
</dd>
<dt>2. Proof of Control</dt>
<dd>
It is possible to prove that the entity claiming control over the identifier is
indeed its controller.
</dd>
<dt>3. Associated cryptographic material</dt>
<dd>
The identifier is tightly coupled with cryptographic material that an entity
can use to prove control over that identifier.
</dd>
<dt>4. Streamlined key rotation</dt>
<dd>
Entities denoted by designated identifiers can update authentication materials
without direct intervention by requesting parties and with minimal individual
interaction.
</dd>
<dt>5. Service endpoint discovery</dt>
<dd>
These identifiers allow requesting parties to look up available service
endpoints for interacting with the subject of the identifier.
</dd>
<dt>6. Delegation of control</dt>
<dd>
The controller of the identifier is able to delegate that control, in full
and/or in part, to a third party.
</dd>
<dt>7. Cryptographically future-proof</dt>
<dd>
These identifiers and associated information are capable of being updated
as technology evolves. Current cryptographic techniques are known to be
susceptible to quantum computational attacks. Future-proofed identifiers
provide a means by which to continue using the same identifier with updated,
advanced authentication and/or authorization technologies.
</dd>
<dt>8. Cryptographic authentication and communication</dt>
<dd>
These identifiers enable the use of cryptographic techniques that can be employed
to authenticate individuals and/or to secure communications with the subject of
the identifier, typically using public-private key pairs.
</dd>
<dt>9. Legally recognizable identification</dt>
<dd>
These identifiers can be used as a basis for credentials and transactions that
can be recognized as legally valid under one or more jurisdictions.
</dd>
<dt>10. Human-centered interoperability</dt>
<dd>
Decentralized identifiers need to be easy to use by people with no technical
expertise or specialist knowledge.
</dd>
</dl>

</section>

<section id="conformance">
<p>
A <dfn>conforming controller document</dfn> is any concrete expression of the
Expand Down Expand Up @@ -3129,7 +3286,7 @@ <h2>Keep Personal Data Private</h2>
If a [=controller document=] is about a specific individual and is
public-facing, it is <em>critical</em> that [=controller documents=] contain
no personal biometric or biographical data. While it is true that personal data
might include pseudonymous information, such as a public cryptographic key or an IP address,
might include pseudonymous information, such as a public cryptographic key or an IP address,
publishing that sort of information does not create the same immediate privacy
dangers as publishing an individual's full name, profile photo, or social media
account in a [=controller document=]. A better alternative is to transmit
Expand Down