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

Jump to bottom

Add "author" and "party" to terminology, rewrite "claim" terminology #1172

Closed
wants to merge 35 commits into from
Closed

Add "author" and "party" to terminology, rewrite "claim" terminology #1172

Changes from 11 commits
Commits
Show all changes
35 commits
Select commit Hold shift + click to select a range
a215692
update definition of 'claim'
RieksJ Jun 27, 2023
6008f7f
typo fixed
RieksJ Jun 27, 2023
96c7d2d
Added 'party' and updated texts with that term
RieksJ Jun 27, 2023
40129a3
added 'author' and modified some descriptions with it
RieksJ Jun 27, 2023
dbab47d
Addressed all (current) comments.
RieksJ Jun 28, 2023
08a4972
fixed comments by TallTed
RieksJ Jun 29, 2023
ea91405
accommodated Orie's suggestion
RieksJ Jun 29, 2023
da030bb
Addressed TallTed's comments
RieksJ Jun 30, 2023
4221fe4
clarification of issuance
RieksJ Jun 30, 2023
bb780b8
Addressed comment of OR13
RieksJ Jun 30, 2023
17c4421
thanks @davidlehn for spotting typo
RieksJ Jul 3, 2023
06ce351
Update terms.html
RieksJ Jul 4, 2023
a9d8bb9
Addressed Manu's comments
RieksJ Jul 4, 2023
5b9597c
addressed wip-abramson's comments
RieksJ Jul 6, 2023
1b213b1
addressed Ted's comment
RieksJ Jul 7, 2023
8b61aa4
Fix mismatched <UL> in terminology.
msporny Jul 8, 2023
31077c6
addressed TallTeds comment
RieksJ Jul 11, 2023
a09a793
addressed @dlongley's comment
RieksJ Jul 14, 2023
f1ec45c
addressed @brentzundel's suggested change
RieksJ Jul 17, 2023
f900903
Addressed comment by @decentralgabe
RieksJ Jul 18, 2023
abf21e3
Addressed @brentzundel's comment
RieksJ Jul 24, 2023
ec89f9e
removed 'author' as term
RieksJ Jul 24, 2023
e287f14
removed 'party' - should accommodate @brentzundel's and @OR13s comments
RieksJ Jul 25, 2023
d22da0a
comments by @brentzundel and @TallTed
RieksJ Jul 27, 2023
571ae86
comment by @TallTed
RieksJ Jul 31, 2023
a4fb1a4
comments by OR13 and TallTed resolved
RieksJ Aug 1, 2023
3f4448c
addressed comments by @jandrieu and @OR13
RieksJ Aug 2, 2023
788fb36
suggestion by @TallTed
RieksJ Aug 3, 2023
af626d8
attempt to resolve some discussions by various people
RieksJ Aug 5, 2023
16572a9
minor update @TallTed
RieksJ Aug 10, 2023
9172267
Re-used the RDF 'resource' concept to resolve discussions
RieksJ Aug 10, 2023
653c80d
@OR13 comments
RieksJ Aug 11, 2023
246efc4
IRI --> URL
RieksJ Aug 11, 2023
fdecac0
Addressed various comments
RieksJ Aug 14, 2023
c78aeb4
Removed `resource`
RieksJ Aug 14, 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
51 changes: 37 additions & 14 deletions terms.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,14 +3,23 @@
</p>

<dl class="termlist">
<dt><dfn data-lt="author|authors|authored|author's|author(s)|authoring">author</dfn></dt>
<dd>
A role that a <a>party</a> performs as it expresses an assertion about a particular <a>entity</a>, i.e., creates a <a>claim</a>.
</dd>
<dt><dfn data-lt="claims">claim</dfn></dt>
<dd>
An assertion made about a <a>subject</a>.
A digital representation of an assertion made about an <a>entity</a> by a specific <a>party</a>.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
The entity is called the <a>subject</a> of the claim.
The <a>party</a> is referred to as the <a>author</a> of the claim, i.e. the one that has expressed the claim.
The meaning of the claim (its semantics) is determined by its <a>author</a>.
Different <a>authors</a> can reuse the same semantics for claims through the
use of author-independent, shared vocabularies.
</dd>
<dt><dfn data-lt="credential|credentials">credential</dfn></dt>
<dt><dfn data-lt="credential|credentials">credential</dfn></dt>
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
<dd>
A set of one or more <a>claims</a> made by an <a>issuer</a>.
The <a>claims</a> in a credential can be about different <a>subjects</a>.
A set of one or more <a>claims</a> <a>authored</a> by a single <a>party</a>, that is constructed for the purpose of transferring it to some other <a>party</a>.
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does an implementer need to understand the difference between an author and an issuer?

Copy link
Author

@RieksJ RieksJ Jun 30, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

An implementer may not need to understand the difference between an author and an issuer. However, in my opinion, standards such as these should not limit their audience to implementers. They should also enable non-implementers to learn (precisely) what they're talking about.

I am not an implementer, but I do contribute to architectures, systems designs, etc., so I need to know what I'm talking about to help projects make the right decisions. Texts that 'sort of' say what VCs are do not help me. I need texts that precisely state the facts of the matter, in order to avoind making mistakes. That particular characteristic determines the effectiveness of specifications as a vehicle for briding the gap between implementers and non-implementers.

Regarding the terms 'author' and 'issuer': as (I think) @dlongley pointed out, there is no such thing as the issuer of a claim, because they can exist without there being a credential that contains them. Having 'author' for a claim allows us to talk about the source of the claim. This is also helpful when talking about claims that are part of presentations. It makes it easier (for non-implementers) to understand the necessity of having proofs of authorship of claims therein. Also, it makes it easier to explain (to non-implementers) what the difference is between credentials (a (signed) set of claims, where the issuer is the author of each of them) and presentations (a (signed) set of claims, where the claims can have different authors and there is no implied link between the party that created (and signed) the presentation and the authorship of the claims).

Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding the terms 'author' and 'issuer': as (I think) @dlongley pointed out, there is no such thing as the issuer of a claim, because they can exist without there being a credential that contains them. Having 'author' for a claim allows us to talk about the source of the claim.

I'm curious where @dlongley pointed out that there is no such this as an issuer of a claim. I would argue that such a distinction is a distinction without a difference.

I would argue that the issuer is the author.

Full stop.

Signing the claim means that the authority who is signing it is attesting to that truth of the claims. They are the author of those claims in that they are making that statement and attesting to their veracity. Whether or not they are the only author or the original author is irrelevant.

You could define an author that is different from the issuer, but that would have no impact on the meaning of the VC. Perhaps if the VC is itself a statement of authorship by someone other than the issuer of the VC.

In that case, you're just adding another claim asserted by the issuer, which verifiers will interpret in some way. That is, a VC issued by BobCo (using a DID we believe is associated with BobCo for attestations) could say "AuthorDan wrote that the sky is blue", i.e., "AuthorDan is the author of the claim that the sky is blue"

However, the VC can only validate that BobCo says "AuthorDan is the author of the claim that the sky is blue". Whether or not AuthorDan is, in fact, the author of those claims is opaque to the VC data model.

In contrast, the fact that the DID known to be associated with BobCo has an attestationMethod that can cryptographically verify the message is not tampered with is concrete evidence that the statement is made/authored/attested by BobCo.

In short, the only meaning of "author" that applies to a VC is the issuer. While that doesn't preclude the issuer making claims about authorship, we do not have any mechanism to deal with "author" of a VC as anything other than the Issuer.

Copy link
Author

Choose a reason for hiding this comment

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

You're right. I thought I remembered what @dlongley said, but didn't.

I agree with you that its author is its issuer, but only in the context of VCs.

In the context of VPs, it's another matter. It is possible that a VP contains claims that are authored by the party that performs the role of the holder that creates the VP. Since such claims were never part of a VC, there is no issuer for them, but there is authorship. In fact, the very definition of 'verifiable presentation' talks about authorship, saying: "A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification."

Copy link
Author

Choose a reason for hiding this comment

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

@jandrieu, @OR13: given the explanations above, is there anything concrete that you would like me to address so that the PR can proceed?

Copy link
Author

Choose a reason for hiding this comment

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

@brentzundel: I cannot understand your argument because the terms you use do not seem to mean what the VCDM says they do. The term 'issuer', for example, is defined by the VCDM specifically in relation to the creation of a VC. So, your thinking that a holder could create a VP that includes claims that were never part of a VC is inconsistent with how VCDM defines 'issuer, so such a holder would not be acting as an issuer.

This may seem nit-picking, but it is an example of how many discussions/issues that we have get lengthy and aren't resolved in a satisfactory way. It would help so much if we could get ourselves to use terms that are defined only in the way in which they are defined, which is the start of having/creating a single understanding of what it is we're talking about, that we then all all share/commit to use.

The current set of terms does not allow us to properly describe the situation you refer to, in which a holder creates a VP which includes claims that were never part of a VC. This is a relevant use-case. In order to be able to talk about this, we might, e.g., modify the term 'issuer' to accommodate for that, introduce 4 roles rather than the current 3 by splitting up the 'holder' role, and I wouldn't be surprised if there are more ways to do this. I remember various discussions/issues about this which didn't lead anywhere.

The term 'author' is really nothing very special. It is just a generic way to refer to the party that created some data (and might be held accountable for its truth, trustworthiness, or the fact that it has created it). It is a simple concept that can be used to refer to the party that has created an individual claim, VC, VP, presentation request, etc. The roles of issuer, holder and verifier are specializations, where an issuer authors VCs for the purpose of sending them to a holder, a holder authors VPs (that includes VCs and/or claims authored by itself or other parties), and a verifier authors presentation requests (in which it seeks to obtain VPs that contain VCs and/or claims that are authored by particular parties). The term 'author' makes it much simpler to say these things than if I had to use the terminology as currently defined, and it is also easier to understand for those that use VCDM terminology rather than their own).

Copy link
Contributor

Choose a reason for hiding this comment

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

@RieksJ,

My understanding is that some people are objecting to this PR because author is being introduced as a separate and explicit role at the same level of issuer, holder, and verifier. I wonder if you could make the clarifications in terminology you'd like to see by not making it an explicit separate role, but by still talking about the existing roles performing authoring actions, etc. This would be my suggestion to try and move this PR toward consensus.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks @dlongley for the suggestion. I am confused about people objecting to a term they also use in daily life. In the context of books, there is an author, and you have publishers (issuers if you will), stores, libraries and other roles that can be performed and from where you can request for and obtain books. People tend to be interested to learn who the author of a book is, and not so much the path that the book went to end up with the reader/user. I have made some changes to the definition to clarify this aspect.

Copy link
Member

Choose a reason for hiding this comment

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

the re-wording of author makes me dislike it less.

Copy link
Author

Choose a reason for hiding this comment

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

@brentzundel That sounds as an improvement. Unless there are concrete suggestions for changes, I guess it is acceptable.

The <a>claims</a> in a <a>credential</a> can be about different <a>subjects</a>.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
</dd>
<dt><dfn>data minimization</dfn></dt>
<dd>
Expand Down Expand Up @@ -61,8 +70,8 @@
</dd>
<dt><dfn data-lt="holders|holder's|holders'">holder</dfn></dt>
<dd>
A role an <a>entity</a> might perform by possessing one or more
<a>verifiable credentials</a> and generating <a>presentations</a> from them.
A role an <a>party</a> might perform by possessing one or more
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
<a>verifiable credentials</a> and generating <a>verifiable presentations</a> from them.
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
<a>verifiable credentials</a> and generating <a>verifiable presentations</a> from them.
<a>verifiable credentials</a> and, optionally, generating <a>verifiable presentations</a> from them.

RieksJ marked this conversation as resolved.
Show resolved Hide resolved
A holder is usually, but not always, a <a>subject</a> of the <a>verifiable
credentials</a> they are holding. Holders store their <a>credentials</a> in
<a>credential repositories</a>.
Expand Down Expand Up @@ -91,12 +100,23 @@
specifications. This specification decouples the <a>identity provider</a>
concept into two distinct concepts: the <a>issuer</a> and the <a>holder</a>.
</dd>
<dt><dfn data-lt="issuers|issuer's">issuer</dfn></dt>
<dt><dfn data-lt="issuers|issuer's|issuer(s)|issuing|issued">issuer</dfn></dt>
<dd>
A role a <a>party</a> can perform as it constructs a <a>verifiable credential</a>
from a set of <a>claims</a> it has <a>authored</a>, meta-data, and proofs,
typically for the purpose of transferring that to a <a>holder</a>.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
</dd>
<dt><dfn data-lt="party|parties|party's">party</dfn></dt>
<dd>
A role an <a>entity</a> can perform by asserting <a>claims</a> about one or
more <a>subjects</a>, creating a <a>verifiable credential</a> from these
<a>claims</a>, and transmitting the <a>verifiable credential</a> to a
<a>holder</a>.
An <a>entity</a> that has 'a mind of its own', which means, amongst other things, that it autonomously (sovereignly)
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
<ul>
<li>sets the objectives it aims to pursue</li>
<li>creates and maintains (<a>authors</a>) data, including <a>identifiers</a>, <a>claims</a>, and <a>credentials</a></li>
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
<li>decides on the semantics of all data that it <a>authors</a> (i.e., what the data means)</li>
<li>gathers, stores, processes, and disseminates data</li>
<li>manages its own logic, deciding what is, and what is not, true, valid, trustworthy, what to reuse (e.g., in terms of shared vocabularies and contexts that other <a>parties</a> have produced), etc.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
</ol>
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
Typical examples include people and organizations.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
</dd>
<dt><dfn data-lt="presentation|presentations">presentation</dfn></dt>
<dd>
Expand All @@ -114,9 +134,12 @@
The ability of a <a>holder</a> to make fine-grained decisions about what
information to share.
</dd>
<dt><dfn data-lt="subjects|subject's">subject</dfn></dt>
<dt><dfn data-lt="subjects|subject's|subject(s)">subject</dfn></dt>
<dd>
A thing about which <a>claims</a> are made.
The <a>entity</a> about which a <a>claim</a> is made.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
The common practice of speaking about "the <a>subject</a> of a <a>credential</a>" SHOULD imply
that such a <a>credential</a> contains one or more <a>claims</a> about precisely one <a>entity</a>,
i.e., that the <a>subject</a> of every <a>claim</a> in the <a>credential</a> is that same <a>entity</a>.
RieksJ marked this conversation as resolved.
Show resolved Hide resolved
</dd>
<dt><dfn class="lint-ignore">user agent</dfn></dt>
<dd>
Expand Down Expand Up @@ -168,7 +191,7 @@
</dd>
<dt><dfn data-lt="verifier|verifiers|verifier's|credential verifiers|credential verifier's">verifier</dfn></dt>
<dd>
A role an <a>entity</a> performs by receiving one or more
A role a <a>party</a> performs by receiving one or more
<a>verifiable credentials</a>, optionally inside a
<a>verifiable presentation</a> for processing. Other specifications might refer
to this concept as a <dfn data-lt="relying parties">relying party</dfn>.
Expand Down