Skip to content

Commit

Permalink
Add link to Use Cases doc, remove use cases section.
Browse files Browse the repository at this point in the history 
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
  • Loading branch information
@brentzundel @TallTed
brentzundel and TallTed authored Feb 10, 2024
1 parent 3d2993e commit 267dee5
Showing 1 changed file with 4 additions and 163 deletions.
167 changes: 4 additions & 163 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -259,10 +259,11 @@ <h2>Introduction</h2>
An ecosystem where [=verifiable credentials=] and
[=verifiable presentations=] are expected to be useful
</li>
<li>
The use cases and requirements that informed this specification.
</li>
</ul>
<p>
The use cases and requirements that informed this specification can be found
in [[[VC-USE-CASES]]] [[?VC-USE-CASES]].
</p>

<section class="informative">
<h3>What is a Verifiable Credential?</h3>
Expand Down Expand Up @@ -427,166 +428,6 @@ <h3>Ecosystem Overview</h3>
</p>
</section>

<section class="informative">
<h3>Use Cases and Requirements</h3>

<p>
The Verifiable Credentials Use Cases document [[VC-USE-CASES]] outlines a number
of key topics that readers might find useful, including:
</p>

<ul>
<li>
A more thorough explanation of the
<a href="https://www.w3.org/TR/vc-use-cases/#user-roles">roles</a>
introduced above
</li>
<li>
The
<a href="https://www.w3.org/TR/vc-use-cases/#user-needs">needs</a>
identified in market verticals, such as education, finance, healthcare, retail,
professional licensing, and government
</li>
<li>
Common
<a href="https://www.w3.org/TR/vc-use-cases/#user-tasks">tasks</a>
performed by the roles in the ecosystem, as well as their associated
requirements
</li>
<li>
Common
<a href="https://www.w3.org/TR/vc-use-cases/#user-sequences">sequences
and flows</a> identified by the Working Group.
</li>
</ul>

<p>
As a result of documenting and analyzing the use cases document, the following
desirable ecosystem characteristics were identified for this specification:
</p>
<!-- requirement list start -->
<ul>
<li>
[=Verifiable credentials=] represent statements made by an [=issuer=] in
a tamper-evident and privacy-respecting manner.
</li>
<li>
[=Holders=] can assemble collections of [=verifiable credentials=] from
different [=issuers=] into a single artifact, a [=verifiable presentation=].
</li>
<li>
[=Issuers=] can issue [=verifiable credentials=] about any [=subject=].
</li>
<li>
Acting as [=issuer=], [=holder=], or [=verifier=] requires neither
registration nor approval by any authority, as the trust involved is bilateral
between parties.
</li>
<li>
[=Verifiable presentations=] allow any [=verifier=] to [=verify=] the
authenticity of [=verifiable credentials=] from any [=issuer=].
</li>
<li>
[=Holders=] can receive [=verifiable credentials=] from anyone.
</li>
<li>
[=Holders=] can interact with any [=issuer=] and any [=verifier=]
through any user agent.
</li>
<li>
[=Holders=] can share [=verifiable presentations=], which can then be
[=verified=] without revealing the identity of the [=verifier=] to the
[=issuer=].
</li>
<li>
[=Holders=] can store [=verifiable credentials=] in any location, without
affecting their [=verifiability=] and without the [=issuer=] knowing
anything about where they are stored or when they are accessed.
</li>
<li>
[=Holders=] can present [=verifiable presentations=] to any
[=verifier=] without affecting authenticity of the claims and without
revealing that action to the [=issuer=].
</li>
<li>
A [=verifier=] can [=verify=] [=verifiable presentations=] from any
[=holder=], containing proofs of [=claims=] from any [=issuer=].
</li>
<li>
[=Verification=] should not depend on direct interactions between
[=issuers=] and [=verifiers=].
</li>
<li>
[=Verification=] should not reveal the identity of the [=verifier=] to
any [=issuer=].
</li>
<li>
The specification must provide a means for [=issuers=] to issue
[=verifiable credentials=] that support selective disclosure, without
requiring all conformant software to support that feature.
</li>
<li>
[=Issuers=] can issue [=verifiable credentials=] that support
selective disclosure.
</li>
<li>
If a single [=verifiable credential=] supports selective disclosure, then
[=holders=] can present proofs of [=claims=] without revealing the entire
[=verifiable credential=].
</li>
<li>
[=Verifiable presentations=] can either disclose the attributes of a
[=verifiable credential=], or satisfy [=derived predicates=] requested by
the [=verifier=]. [=Derived predicates=] are Boolean conditions, such as
greater than, less than, equal to, is in set, and so on.
</li>
<li>
[=Issuers=] can issue revocable [=verifiable credentials=].
</li>
<li>
The processes of cryptographically protecting and verifying
[=verifiable credentials=] and [=verifiable presentations=] have to be
deterministic, bi-directional, and lossless. Any
[=verifiable credential=] or [=verifiable presentation=] has to be
transformable to the JSON-LD data model defined in this document via a
deterministic process so that its verification can be processed in an
interoperable fashion.
</li>
<li>
[=Verifiable credentials=] and [=verifiable presentations=] have to be
serializable in one or more machine-readable data formats. The process of
serialization and/or de-serialization has to be deterministic, bi-directional,
and lossless. Any serialization of a [=verifiable credential=] or
[=verifiable presentation=] needs to be transformable to the generic data
model defined in this document in a deterministic process such that the
resulting [=verifiable credential=] can be processed in an interoperable
fashion. The serialized form also needs to be able to be generated from the data
model without loss of data or content.
</li>
<li>
The data model and serialization must be extendable with minimal coordination.
</li>
<li>
Revocation by the [=issuer=] should not reveal any identifying information
about the [=subject=], the [=holder=], the specific
[=verifiable credential=], or the [=verifier=].
</li>
<li>
[=Issuers=] can disclose the revocation reason.
</li>
<li>
[=Issuers=] revoking [=verifiable credentials=] should distinguish between
revocation for cryptographic integrity (for example, the signing key is
compromised) versus revocation for a status change (for example, the driver's
license is suspended).
</li>
<li>
[=Issuers=] can provide a service for refreshing a
[=verifiable credential=].
</li>
</ul>
</section>

<section id="conformance" class="normative">
<p>
A <dfn>conforming document</dfn> is a
Expand Down

0 comments on commit 267dee5

Please sign in to comment.