Skip to content

Presentations #1181

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
merged 11 commits into from
Jul 8, 2023
Merged

Presentations #1181

Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
7fdb272
rewrite Presentations section
brentzundel Jun 30, 2023
93bc8a6
edit presentations intro
brentzundel Jun 30, 2023
adf1ceb
Apply suggestions from code review
brentzundel Jul 3, 2023
b62bb00
Update index.html
brentzundel Jul 5, 2023
3264f74
Update index.html
brentzundel Jul 5, 2023
9eaf43e
Apply suggestions from code review
brentzundel Jul 5, 2023
29f5cc9
modify description to address Orie and Gabe's comments.
brentzundel Jul 5, 2023
75bfa7d
point normatively to guidance elsewhere.
brentzundel Jul 5, 2023
e5b8dd0
let holder copy issuer
brentzundel Jul 5, 2023
6a7c14e
Apply suggestions from code review
brentzundel Jul 7, 2023
b1119cb
Update index.html
brentzundel Jul 7, 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
106 changes: 46 additions & 60 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -789,13 +789,11 @@ <h3>Presentations</h3>
</p>

<p>
A <a>verifiable presentation</a> expresses data from one or more
<a>verifiable credentials</a>, and is packaged in such a way that the
authorship of the data is <a>verifiable</a>. If <a>verifiable credentials</a>
are presented directly, they become <a>verifiable presentations</a>. Data
Copy link
Contributor

Choose a reason for hiding this comment

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

I like some of this text, don't think it should all be removed.

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'm open to suggestions. My attempt to adjust this section did not find consensus.

Copy link
Contributor

Choose a reason for hiding this comment

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

can we keep

<a>verifiable credentials</a>, and is packaged in such a way that the
authorship of the data is <a>verifiable</a>. If <a>verifiable credentials</a>
are presented directly, they become <a>verifiable presentations</a>.

Copy link
Member Author

Choose a reason for hiding this comment

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

Now that we've introduced media types, I don't think it is true that a verifiable credential (vc+ld+json) becomes a verifiable presentation (vp+ld+json).

What about a sentence like: "It is also possible to present verifiable credentials directly."

Copy link
Contributor

Choose a reason for hiding this comment

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

sure I think that's a good sentence

Copy link
Member Author

@brentzundel brentzundel Jul 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Re-worded in 29f5cc9

formats derived from <a>verifiable credentials</a> that are cryptographically
<a>verifiable</a>, but do not of themselves contain
<a>verifiable credentials</a>, might also be <a>verifiable presentations</a>.
A <a>verifiable presentation</a> can express data from multiple
<a>verifiable credentials</a> and contain arbitrary additional data encoded as
JSON-LD. They are used by a <a>holder</a> to present <a>claims</a> to a
<a>verifier</a>. It is also possible to present <a>verifiable credentials</a>
directly.
</p>

<p>
Expand Down Expand Up @@ -1899,65 +1897,68 @@ <h3>Status</h3>
<h3>Presentations</h3>

<p>
<a>Presentations</a> MAY be used to combine and present <a>credentials</a>.
They can be packaged in such a way that the authorship of the data is
<a>verifiable</a>. The data in a <a>presentation</a> is often all about the same
<a>subject</a>, but there is no limit to the number of <a>subjects</a> or
<a>issuers</a> in the data. The aggregation of information from multiple
<a>verifiable credentials</a> is a typical use of
<a>verifiable presentations</a>.
<a>Verifiable presentations</a> MAY be used to aggregate information from
multiple <a>verifiable credentials</a>.
</p>
<p>
<a>Verifiable presentations</a> SHOULD be extremely short-lived, and
bound to a challenge provided by a <a>verifier</a>. Details for accomplishing
this depend on the securing mechanism, the transport protocol, and
<a>verifier</a> policies. Unless additional requirements are defined by the
particular securing mechanism or embedding protocol, a <a>verifier</a> cannot
generally assume that the <a>verifiable presentation</a> has any correlation
with the presented <a>verifiable credentials</a>.
<a>Verifiable presentations</a> SHOULD be extremely short-lived, and bound to a
challenge provided by a <a>verifier</a>. Details for accomplishing this depend
on the securing mechanism, the transport protocol, and <a>verifier</a> policies.
Unless additional requirements are defined by the particular securing mechanism
or embedding protocol, a <a>verifier</a> cannot generally assume that the
<a>verifiable presentation</a> has any correlation with the presented
<a>verifiable credentials</a>.
</p>
<p>
A <a>verifiable presentation</a> is typically composed of the following
properties:
The following properties are defined for a <a>verifiable presentation</a>:
</p>

<dl>
<dt><var>id</var></dt>
<dd>
The <code>id</code> <a>property</a> is optional and MAY be used to provide a
unique identifier for the <a>presentation</a>. For details related to the use of
this property, see Section <a href="#identifiers"></a>.
The <code>id</code> <a>property</a> is optional. It MAY be used to provide a
unique identifier for the <a>verifiable presentation</a>. If present, the
normative guidance in Section <a href="#identifiers"></a> MUST be followed.
Comment on lines +1920 to +1921
Copy link
Member

Choose a reason for hiding this comment

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

Just noting that we don't need the normative statement on identifiers, as all identifiers must follow that guidance anyway. This normative statement doesn't make the implementation do anything above and beyond what's stated in the #identifiers section. I think we can safely remove this statement (in a future PR).

</dd>
<dt><var>type</var></dt>
<dd>
The <code>type</code> <a>property</a> is required and expresses the
type of <a>presentation</a>, such as <code>VerifiablePresentation</code>. For
details related to the use of this property, see Section <a href="#types"></a>.
The <code>type</code> <a>property</a> MUST be present. It is used to express the
type of <a>verifiable presentation</a>. One value of this property MUST be
<code>VerifiablePresentation</code>, but additional types MAY be included. The
related normative guidance in Section <a href="#types"></a> MUST be followed.
Comment on lines +1927 to +1928
Copy link
Member

Choose a reason for hiding this comment

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

Just noting that we don't need the normative statement on types, as all types must follow that guidance anyway. This normative statement doesn't make the implementation do anything above and beyond what's stated in the #types section. I think we can safely remove this statement (in a future PR).

</dd>
<dt><var>verifiableCredential</var></dt>
<dd>
If present, the value of the <code>verifiableCredential</code> <a>property</a>
MUST be constructed from one or more <a>verifiable credentials</a>, or of data
The <code>verifiableCredential</code> <a>property</a> MAY be present. The value
Copy link
Contributor

Choose a reason for hiding this comment

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

if its present, can it be empty?

Copy link
Member Author

Choose a reason for hiding this comment

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

What is better:

  1. required and can be empty, or
  2. not required but has to have at least one value?

Copy link
Contributor

@OR13 OR13 Jul 7, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

2 is better... this is a perfect case of "many different JSONs" produce the same "graph"... and proof mechanisms might not preserve all of them the same way...

We have the exact same problem come up with credentialSubject.

we said it MUST be present and it MUST NOT be empty.

Doing that for Verifiable Presentations would destroy "DID Auth" which use data integrity proofs to prove possession of a private key for a holder, but does not communicate any credentials.

So my reasoning for 2 is to allow for that behavior to continue to be legal, while removing equivalent JSON syntax for the same RDF Graph.

Copy link
Member Author

Choose a reason for hiding this comment

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

excellent. 2 is how it's currently worded, so I won't make any changes.

MUST be an array of one or more <a>verifiable credentials</a>, or of data
derived from <a>verifiable credentials</a> in a cryptographically
<a>verifiable</a> format.
</dd>
<dt><var>holder</var></dt>
<dd>
If present, the value of the <code>holder</code> <a>property</a>
is expected to be a <a>URL</a> for the entity that is generating the
<a>presentation</a>.
The <a>verifiable presentation</a> MAY include a <code>holder</code>
<a>property</a>. If present, the value MUST be either a <a>URL</a> or an object
containing an <code>id</code> <a>property</a>. It is RECOMMENDED that the
<a>URL</a> in the <code>holder</code> or its <code>id</code> be one which, if
dereferenced, results in a document containing machine-readable information
about the <a>holder</a> that can be used to <a>verify</a> the information
expressed in the <a>verifiable presentation</a>.
If the <code>holder</code> <a>property> is absent, information about the
<a>holder</a> is expected to either be obtained via the securing mechanism, or
to not pertain to the <a>validation</a> of the <a>verifiable presentation</a>.
</dd>
<dt><var>proof</var></dt>
<dd>
If present, the value of the <code>proof</code> <a>property</a> ensures that
the <a>presentation</a> is <a>verifiable</a>. For details related to the use of
this property, see Section <a href="#proofs-signatures"></a>.
The <a>verifiable presentation</a> MAY include a <code>proof</code>
<a>property</a>. If present, the value SHOULD be used to express a securing
mechanism such as [[?VC-DATA-INTEGRITY]]. A <a>verifiable presentation</a> MAY
be secured using an external proof such as [[?VC-JWT]]. For details related to
the use of this property, see Section <a href="#securing-verifiable-credentials"></a>.
</dd>
</dl>

<p>
The example below shows a <a>verifiable presentation</a> that embeds
<a>verifiable credentials</a>.
The example below shows a <a>verifiable presentation</a>:
</p>

<pre class="example nohighlight" title="Basic structure of a presentation">
Expand Down Expand Up @@ -1989,18 +1990,14 @@ <h4>Presentations Using Derived Credentials</h4>
<p>
Some zero-knowledge cryptography schemes might enable <a>holders</a> to
indirectly prove they hold <a>claims</a> from a <a>verifiable credential</a>
without revealing the <a>verifiable credential</a> itself. In these schemes, a
<a>claim</a> from a <a>verifiable credential</a> might be used to derive a
presented value, which is cryptographically asserted such that a <a>verifier</a>
can trust the value if they trust the <a>issuer</a>.
without revealing all claims in that <a>verifiable credential</a>. In these schemes,
a <a>verifiable credential</a> might be used to derive presentable data, which is
cryptographically asserted such that a <a>verifier</a> can trust the value if
they trust the <a>issuer</a>.
</p>

<p>
For example, a <a>verifiable credential</a> containing the <a>claim</a>
<code>date of birth</code> might be used to derive the presented value
<code>over the age of 15</code> in a manner that is cryptographically
<a>verifiable</a>. That is, a <a>verifier</a> can still trust the derived value
if they trust the <a>issuer</a>.
Some selective disclosure schemes can share a subset of <a>claims</a>
derived from a <a>verifiable credential</a>.
</p>

<p class="note">
Expand All @@ -2009,17 +2006,6 @@ <h4>Presentations Using Derived Credentials</h4>
Section <a href="#zero-knowledge-proofs"></a>.
</p>

<p>
Selective disclosure schemes using zero-knowledge proofs can use <a>claims</a>
expressed in this model to prove additional statements about those <a>claims</a>.
For example, a <a>claim</a> specifying a <a>subject's</a> date of birth can be
used as a predicate to prove the <a>subject's</a> age is within a given range,
and therefore prove the <a>subject</a> qualifies for age-related discounts,
without actually revealing the <a>subject's</a> birthdate. The <a>holder</a>
has the flexibility to use the <a>claim</a> in any way that is applicable to
the desired <a>verifiable presentation</a>.
</p>

<figure>
<img style="margin: auto; display: block; width: 50%;"
src="diagrams/claim-example-2.svg" alt="Pat has a property
Expand Down