Skip to content

Clean up use-cases summary #1166

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

Merged
msporny merged 7 commits into from
Jun 30, 2023
Merged

Clean up use-cases summary #1166

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
81266a6
fix C vs VC in use cases and requirements summary
brentzundel Jun 21, 2023
bcb61ce
fix C vs VC in use cases and requirements summary - 2
brentzundel Jun 21, 2023
5c68f62
Update index.html
brentzundel Jun 23, 2023
212305a
Update index.html
brentzundel Jun 23, 2023
d4894b9
Update index.html
brentzundel Jun 23, 2023
8d724ab
Update index.html
brentzundel Jun 23, 2023
ce55d57
remove non-normative, editorial description of a verifiable presentat…
brentzundel Jun 27, 2023
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
26 changes: 8 additions & 18 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -425,20 +425,12 @@ <h3>Use Cases and Requirements</h3>
<!-- requirement list start -->
<ul>
<li>
<a>Credentials</a> represent statements made by an <a>issuer</a>.
</li>
<li>
<a>Verifiable credentials</a> represent statements made by an <a>issuer</a> in
a tamper-evident and privacy-respecting manner.
</li>
<li>
<a>Holders</a> assemble collections of <a>credentials</a> and/or
<a>verifiable credentials</a> from different <a>issuers</a> into a single
artifact, a <a>presentation</a>.
</li>
<li>
Holders transform <a>presentations</a> into <a>verifiable presentations</a>
to render them tamper-evident.
<a>Holders</a> can assemble collections of <a>verifiable credentials</a> from
different <a>issuers</a> into a single artifact, a <a>verifiable presentation</a>.
</li>
<li>
<a>Issuers</a> can issue <a>verifiable credentials</a> about any <a>subject</a>.
Expand Down Expand Up @@ -510,14 +502,12 @@ <h3>Use Cases and Requirements</h3>
<a>Issuers</a> can issue revocable <a>verifiable credentials</a>.
</li>
<li>
The processes of cryptographically protecting <a>credentials</a> and
<a>presentations</a>, and verifying <a>verifiable credentials</a> and
<a>verifiable presentations</a>, have to be deterministic, bi-directional, and
lossless. Any verification of a <a>verifiable credential</a> or
<a>verifiable presentation</a> has to be transformable to the generic data model
defined in this document in a deterministic process, such that the resulting
<a>credential</a> or <a>presentation</a> is semantically and syntactically
equivalent to the original construct, so that it can be processed in an
The processes of cryptographically protecting and verifying
<a>verifiable credentials</a> and <a>verifiable presentations</a> have to be
deterministic, bi-directional, and lossless. Any
<a>verifiable credential</a> or <a>verifiable presentation</a> 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
Copy link
Contributor

@OR13 OR13 Jun 29, 2023

Choose a reason for hiding this comment

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

@brentzundel I am still struggling with this part. I know you didn't create this text, you are just trying to clean it up.... but the whole paragraph is problematic.

Many digital signatures are not deterministic, some datetime conversions are always lossy....

DataIntegrityProofs can be lossy ( order issues, context integrity issues, etc...)... Even assuming this paragraph was meant to only apply to data integrity proofs, I am not sure it is accurate.

Copy link
Member Author

@brentzundel brentzundel Jun 29, 2023

Choose a reason for hiding this comment

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

I think there a numerous problems with the whole use cases section, which is non-normative but feels very official. I've opened #1169 to have a conversation about removing it.

interoperable fashion.
</li>
<li>
Expand Down