Distinguish credentials from presentations #220
Conversation
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
index.html
Outdated
| @@ -238,8 +238,8 @@ <h3>Ecosystem Overview</h3> | |||
| <dt><a>holder</a></dt> | |||
| <dd> | |||
| A role an <a>entity</a> may perform by possessing one or more | |||
| <a>verifiable credentials</a>. Examples of holders include students, | |||
| employees, and customers. | |||
| <a>verifiable credentials</a> and generationg <a>presentations</a> from them | |||
There was a problem hiding this comment.
Make sure to update these definitions in the terms.html document as well. https://github.com/w3c/vc-data-model/blob/gh-pages/terms.html
There was a problem hiding this comment.
Yes, I believe I did this.
index.html
Outdated
| <a>Verifiable credentials</a> are independently issued, stored, | ||
| and verified. | ||
| Issuers independently issue <a>verifiable credentials</a>, and holders store them. | ||
| Holders independently offer <a>verifiable presentations</a>, and verifiers |
There was a problem hiding this comment.
High density use of "independently"... don't know if there is alternate language that is less awkward. Fine to keep it as is...
There was a problem hiding this comment.
Will try to reword on Monday.
index.html
Outdated
| @@ -458,6 +466,12 @@ <h3>Claims</h3> | |||
| </figcaption> | |||
| </figure> | |||
|
|
|||
| <p> | |||
| If a presentation supports predicates, a claim about birthdate (not true or false, but tied to | |||
There was a problem hiding this comment.
"predicate" needs to be defined and linked to. It's not clear what "a claim about birthdate" means. Needs an example.
There was a problem hiding this comment.
Will refine on Monday.
index.html
Outdated
| @@ -531,8 +545,15 @@ <h2>Presentations</h2> | |||
| </p> | |||
|
|
|||
| <p> | |||
| A <a>verifiable presentation</a> is a collection of one or more | |||
| <a>verifiable credentials</a> that are often about the same <a>subject</a> that | |||
| A <a>verifiable presentation</a> is data from one or more <a>verifiable | |||
There was a problem hiding this comment.
"is" is problematic... what about "contains" or "expresses"?
There was a problem hiding this comment.
Absolutely. Will improve on Monday.
index.html
Outdated
| A <a>verifiable presentation</a> is data from one or more <a>verifiable | ||
| credentials</a>, packaged in such a way that the authorship of the data | ||
| is verifiable. If credentials are directly presented, they become a | ||
| presentation. Profiles are presentations. Data formats derived from |
There was a problem hiding this comment.
We've removed the concept of "profile" from the spec... any remaining discussion of "profile" is a bug and needs to be removed.
| @@ -552,7 +573,7 @@ <h2>Presentations</h2> | |||
|
|
|||
| <p class="note"> | |||
| It is possible to have a <a>presentation</a>, such as a business persona, | |||
| that contains multiple <a>credentials</a> about different <a>subjects</a> | |||
| that draws upon multiple <a>credentials</a> about different <a>subjects</a> | |||
There was a problem hiding this comment.
"draws upon" is good... trying to find language that makes it possible to either directly include, or include derived information...
index.html
Outdated
| @@ -584,7 +605,7 @@ <h1>Trust Model</h1> | |||
| to be a correct record of which identifiers belong to which <a>entities</a>. | |||
| </li> | |||
| <li> | |||
| The <a>subject</a> trusts the <a>issuer</a> to issue true (i.e. not false) | |||
| The <a>subject</a> trusts the <a>issuer</a> to issue true | |||
There was a problem hiding this comment.
"true" is problematic here. I think this is language that @David-Chadwick inserted at some point. We should probably say something along the lines of "to assert certain types of information about the subject"...
There was a problem hiding this comment.
We're in the section about how trust works. We don't trust a credential because the issuer "asserts certain types of information about the subject" -- we trust the credential because, after verifying authorship, we think it's likely that the issuer's assertions are actually true. The verification of a credential does not, of course, test the truth value of assertions--only the authorship of them--but as a description of how trust works, merely stating that we trust a party to make assertions is not going far enough, I think.
index.html
Outdated
| @@ -605,7 +626,7 @@ <h1>Trust Model</h1> | |||
| repository</a>, and | |||
| </li> | |||
| <li> | |||
| the <a>issuer</a> does not need to trust the <a>verifier</a>. | |||
| the <a>issuer</a> does not need to trust (or even know) the <a>verifier</a>. | |||
There was a problem hiding this comment.
Try to avoid the parenthetical... maybe "does not need to trust or know"...
There was a problem hiding this comment.
Will revise on Monday.
terms.html
Outdated
| Data derived from one or more credentials, fitted to the needs of sharing | ||
| with a particular verifier, and encoded in such a way that the verifier may | ||
| trust authorship of the data after a process of cryptographic verification. A | ||
| credential itself may be presented, in which case the credential becomes a |
There was a problem hiding this comment.
The following three sentences are problematic. Can we strike them entirely? Over-specifying things will make it more difficult for us to support broader use cases in the future.
There was a problem hiding this comment.
Can you give me the first few words and the last few words of the sentences you're talking about? I'm not sure what "the following 3 sentences" means because of the way github is showing me the map between comment and lines...
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
index.html
Outdated
| </p> | ||
|
|
||
| <pre class="example nohighlight" title="Basic structure of a presentation"> |
There was a problem hiding this comment.
I'm guessing that the deletion of the majority of the content in this section was an error?
There was a problem hiding this comment.
No, it was not a mistake. I was proposing that we omit any example of a presentation, because the example shown is SO different from the one that ZKPs have to use. I could submit a PR with a second example of a presentation (this one ZKP-style), but with little in common between the two examples, it's not clear to me what value there would be in pairing them.
Perhaps this needs to be the subject of a different PR.
index.html
Outdated
| the <a>presentation</a> before it is converted into a | ||
| <a>verifiable presentation</a>.</p> | ||
| their terms of use inside the <a>credential</a> before it is converted into a | ||
| <a>verifiable credential</a>. The <a>holder</a> places issuer terms |
There was a problem hiding this comment.
This is not how the data model is designed. The presentation is something created by the holder. The holder can put credentials (which may or may not contain issuer termsOfUse) into the presentation in the verifiableCredential property. The holder may also place holder termsOfUse into the presentation.
There was a problem hiding this comment.
Okay. I will look for a way to revise. Where do subject termsOfUse go?
There was a problem hiding this comment.
For now, I am removing the idea of a holder adding issuer terms of use to a presentation. However, I have logged #224 to track a conceptual mismatch that needs to be resolved.
There was a problem hiding this comment.
@dhh1128 I think you have misunderstood the current model. The holder is not adding issuer terms of use to a presentation, but rather his/her own terms of use to the presentation. The issuer terms of use are visible in the credential.
Now I do understand your problem with anonymous credentials, in that the VC is opaque. But I would argue that the way to resolve this is not to alter the structure of the VP, but rather, when the holder asserts what the opaque VC contains, that the issuer terms of use are also asserted as well. I suspect this is a protocol issue rather than a data model issue. I realise that a holder may wish to hide certain issuer terms of use, but again, this is a problem that anonymous credentials has to resolve (in its protocol), rather than in the VC data model.
index.html
Outdated
| @@ -1282,6 +1241,7 @@ <h2>Terms of Use</h2> | |||
| The group is currently exploring a variety of ways of expressing the terms of | |||
| use associated with a Verifiable Credential, namely, the | |||
| <a href="http://w3c.github.io/poe/model/">Open Digital Rights Language</a>. | |||
| A related initiative is the one at customercommons.org. | |||
There was a problem hiding this comment.
Change customercommons.org to <a href="https:// customercommons.org">Customer Commons</a>
index.html
Outdated
| } | ||
| </pre> | ||
|
|
||
| <p class="issue" data-number=133> |
There was a problem hiding this comment.
We can't remove issues from the spec that are not resolved.
There was a problem hiding this comment.
this was a mistake on my part. Will revise.
index.html
Outdated
| </p> | ||
|
|
||
| <p> | ||
| The contents of the <code>verifiableCredential</code> property are |
There was a problem hiding this comment.
We can't remove spec text that has previously achieved consensus unless we go back to the group and request that the text be removed... and I doubt that will happen for this paragraph.
| A <a>verifiable credential</a> is expressed in one or more standard, | ||
| machine-readable data formats which can also be extended with minimal | ||
| coordination. | ||
| <a>Holders</a> in <a>presentations</a> can either disclose the attributes or satisfy <a>predicates</a> |
There was a problem hiding this comment.
predicates are linked to here, but not defined. If we are going to introduce that new term, we'll have to define it in terms.html
There was a problem hiding this comment.
Thinking about it a bit more, do we need to introduce the "predicate" term? It's just another attribute isn't it? Can't we just provide an example of an attribute that is a predicate w/o increasing the cognitive burden of the reader to have to learn a new term?
There was a problem hiding this comment.
The way I've been using it, a "predicate" (I've now renamed to "derived predicate" in latest incarnation of PR) is NOT an attribute in a credential. It is an attribute in a presentation that is derived from an attribute in a credential.
There was a problem hiding this comment.
hmm, ok... we can model that, but haven't yet. I don't expect it'll be that difficult to do... there are a couple of options there... but will need a new PR for a new example using derived predicates.
index.html
Outdated
| <p> | ||
| If a presentation supports predicates, a claim about birthdate (not true or false, but tied to | ||
| a specific date value) can become the basis of proof that at an arbitrary point in time, the | ||
| age of a subject did or will lie within an arbitrary interval. |
There was a problem hiding this comment.
I misread "lie" to mean "will not tell the truth" because my mind was in "verifiable credentials land" where some things have a true/false nature. Can we change the language to "the age of the subject has or will be within the specified interval." ... don't even know if that does it. It's hard to understand what's being said here.
Maybe: "Predicates may be used in presentations to increase privacy by specifying things in a more coarse grained manner, such as the subject being over the age of 65 without exposing their exact birthday."
That feels like it's easier to read... but again, I question the need to introduce the term "predicate" to the document's vocabulary.
index.html
Outdated
| <a>verifiable credentials</a> and one or more proofs that are appropriate | ||
| for the presentation. The basic structure of a <a>verifiable presentation</a> | ||
| is provided below: | ||
| Credentials MAY be used to make a <a>verifiable presentation</a>. The presentation |
There was a problem hiding this comment.
The specification makes a distinction between presentations (which are not verifiable) and verifiable presentations (which are verifiable). The modified language goes back and forth between these definitions, which muddies the waters. What about this:
Credentials MAY be used to create presentations, which are composed of information from one or more credentials. A verifiable presentation is a presentation that is composed of information from one or more verifiable credentials and is thus cryptographically verifiable. The information in a verifiable presentation may be directly or indirectly derived from one or more verifiable credentials. The basic structure of a verifiable presentation is provided below:
There was a problem hiding this comment.
Yes, I see how I muddied the distinction. I will revise, using your language as a guide.
terms.html
Outdated
| @@ -15,20 +15,21 @@ | |||
| A set of one or more <a>claims</a> made by the issuer. | |||
| A <dfn data-lt="verifiable credentials">verifiable credential</dfn> | |||
| is a credential that is tamper-resistant and whose authorship can be | |||
| cryptographically verified. | |||
| cryptographically verified. Credentials can be used to build | |||
| <a>presentations</a>, which can also be cryptographically verified. | |||
There was a problem hiding this comment.
We need to be careful with the language here. A credential and a presentation are not cryptographically verifiable. A verifiable credential and a verifiable presentation are cryptographically verifiable.
terms.html
Outdated
| <dd> | ||
| The process that cryptographically demonstrates the authenticity of a | ||
| <a>credential</a>. | ||
| <a>credential</a> or a <a>presentation</a>. |
There was a problem hiding this comment.
The original text is wrong... we should say "verifiable credential" and "verifiable presentation"
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
index.html
Outdated
| predicate</a>, plus a "not expired" <a>derived predicate</a>. Notice that | ||
| claims are clustered by subject, with some claims about "this" (the credential | ||
| itself), and others about a subject named "person." | ||
| </p> |
There was a problem hiding this comment.
Sorry, I wasn't clear on the TGB call. Can we do this in a separate PR? This PR is almost ready to go and adding extra discussion around the formatting of the ZKP style credential will slow this PR down. Let's discuss this addition to the spec (specifically the data format) in another issue/PR so we can get the current one into the spec. There is agreement to have two examples, so I'm fine if you allude to the 2nd example in this PR (or keep the text, but leave the example blank for the time being until we lock the data model for ZKPs as VCs down).
| </dd> | ||
| <dt><dfn data-lt="presentation">verifiable presentation</dfn></dt> | ||
| <dd> | ||
| Data derived from one or more verifiable credentials, fitted to the needs of sharing |
There was a problem hiding this comment.
Not exactly accurate, but I can clean this up later. We need to start out by defining what a presentation is, then layer the 'verifiable' part on top by defining that in a second/third sentence.
We can merge the PR w/o the fix.
| A <a>verifiable credential</a> is expressed in one or more standard, | ||
| machine-readable data formats which can also be extended with minimal | ||
| coordination. | ||
| <a>Holders</a> in <a>presentations</a> can either disclose the attributes or satisfy <a>predicates</a> |
There was a problem hiding this comment.
hmm, ok... we can model that, but haven't yet. I don't expect it'll be that difficult to do... there are a couple of options there... but will need a new PR for a new example using derived predicates.
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
|
@msporny I have removed the example of a ZKP-style presentation. |
index.html
Outdated
| </span> | ||
| } | ||
| </pre> | ||
| We are currently working on an example of a ZKP-style verifiable presentation that contains |
There was a problem hiding this comment.
I'm pulling in this PR, but for future reference. You can do this:
<p class="issue">Text explaining a work in progress item that will be highlighted appropriately in the spec</p>
... and the text will get special treatment via ReSpec instead of seeming like it's spec text.
|
Good PR, aligned w/ VCWG consensus as of the call today. Merged. |
Signed-off-by: Daniel Hardman daniel.hardman@gmail.com
This embodies item #4 from https://docs.google.com/document/d/10e6lcsX0kiXkWX4_79hD1fb4p_AbFGsRm90eJJKFayI/edit -- chiefly, defining presentation and clarifying its relationship to a credential.
Preview | Diff