Describing presentation and clarifying its relationship to a credential. #217

lovesh · 2018-08-16T11:46:22Z

Signed-off-by: lovesh harchandani lovesh.bond@gmail.com

davidlehn · 2018-08-21T17:53:08Z

index.html

        </li>
        <li>
-The <a>subject</a> trusts the <a>issuer</a> to issue true (i.e., not false)
+The <a>subject</a> trusts (since only the holder can verify) the <a>issuer</a> to issue true (i.e. not false)


add comma after i.e.

davidlehn · 2018-08-21T17:56:30Z

index.html

@@ -445,15 +445,17 @@ <h3>Claims</h3>

      <p>
 The data model for <a>claims</a> described above is powerful and can be used to
-express a large variety of statements. For example, whether or not someone is
-over the age of 21 may be expressed as follows:
+express a large variety of statements. For example, a claim specifying the data of birth of a subject


data => date

davidlehn · 2018-08-21T18:01:14Z

index.html

      </p>

      <figure>
        <img style="margin: auto; display: block;"
          width="50%" src="diagrams/claim-example.svg">
        <figcaption style="text-align: center;">
-An example of a basic claim that expresses that Pat is over the age of 21.
+An example of a basic claim that expresses that Pat's date of birth is 1534417926548 milliseconds from epoch.


This should use an ISO8601 dateTime string like other examples. Probably also just use schema.org "birthDate" property too. Also the new SVG is styled different than the other images and the subtext is wrapped oddly.

The dateTime string is intentionally formatted since the exact encoiding of the value is defined in a schema.

Updated the SVG but it is still different from some other SVGs since i could not edit those SVGs. Any recommended editors?

This is an introductory document. I think it should be using easy to understand examples. We should avoid an arbitrary UNIX timestamp that requires an explanation in both the caption and graphic. Yes, that is a possible value, but it seems like something that could be in a more advanced example. In this case using https://schema.org/birthDate with a readable ISO8601 date makes more sense. The value could just be "1985-10-26" without the subtext and people will likely understand without introducing concepts like the epoch.

@msporny: do you recall what tools created these figures? (I'm guessing google docs or inkscape)
@lovesh: The figures need to all match up with the same style. There's only a few figures, but if one changes style, they all should change. In addition to style, the figure after this one is combining the previous two. So if the ageOver part is changing, it should change in both places.

Yeah, Google Docs. Specifically, Google Draw. Originals are here: https://drive.google.com/drive/u/1/folders/0BwQ7X2CScoA-emRfSmVfSU4xNTg

@davidlehn Ok, i will update the birthDate to show ISO8601 format and clarify that format needs to be specified in the schema.

msporny

There are a number of items that are problematic with this PR. I've suggested some changes, let's get through those and see where we end up.

msporny · 2018-08-28T14:05:39Z

index.html

        </li>
        <li>
-The <a>subject</a> trusts the <a>issuer</a> to issue true
+The <a>subject</a> trusts (since only the holder can verify) the <a>issuer</a> to issue true (i.e., not false)


I don't understand what "since only the holder can verify" means in this sentence.

We wanted to emphasize that the subject cannot verify the credential, no one apart from holder can. Subject can only verify if he is the holder

I reject this proposed change, because verification is nothing to do with this trust statement.
This trust statement is stating a fact, namely, that the subject trusts the issue to issue true statements about him or her. Period.
Verification is not within the scope of this sentence and is irrelevant.

msporny · 2018-08-28T14:06:21Z

index.html

      </ol>

      <p>
-This trust model differentiates itself from other trust models by ensuring that:
+This trust model differentiates itself from other trust models by ensuring that
+the <a>issuer</a> does not need to trust (or even know) the <a>verifier</a>.


This text as in @dhh1128's PR, wasn't it? I feel like there are multiple sentences in this PR that were in the other PR.

msporny · 2018-08-28T14:38:05Z

index.html

-express a large variety of statements. For example, whether or not someone is
-over the age of 21 may be expressed as follows:
+express a large variety of statements. For example, a claim specifying the date of birth of a subject
+can be used to prove that its age lies in an interval or is greater or less than a some value which is


@dhh1128, this already went into the spec, didn't it?

We also need to use simpler language here to make the concepts more accessible to readers. Suggestion:

For example, a claim related to the date of birth of a subject is useful for use cases like proving that the subject is above the legal drinking age or able to get age-related discounts at retail stores. This data model enables the holder to have the flexibility to express their date of birth directly, or indirectly (e.g., under the age of 15, over the age of 65):

I've been bikeshedding this over in #213 too.

msporny · 2018-08-28T14:54:30Z

index.html

-credential, as well as metadata that describes properties of the credential
-itself such as: the <a>issuer</a>, the expiry time, a representative image,
-etc. A <a>verifiable credential</a> is a set of claims and metadata that are
+same <a>entity</a>. It includes a holder generated almost-always unique identifier


This is not accurate, we have credentials that will use the issuer supplied identifier. The previous text covered this case... it says "may include an identifier", as in it's optional. I suggest we use the original text.

msporny · 2018-08-28T14:57:18Z

index.html

-etc. A <a>verifiable credential</a> is a set of claims and metadata that are
+same <a>entity</a>. It includes a holder generated almost-always unique identifier
+as well as metadata that describes properties of the credential itself such as: the <a>issuer</a>,
+the public key to use, the revocation mechanism to use etc. This metadata can


"the public key to use" for what? Verification? Why would it specify this. I know the answer, but a reader that knows nothing about ZKPs will be confused by this language. It's also not clear that introducing this concept this early on is going to help the reader get a good grounding in the basic concepts before moving on to ZKP concepts.

msporny · 2018-08-28T14:59:44Z

index.html

+same <a>entity</a>. It includes a holder generated almost-always unique identifier
+as well as metadata that describes properties of the credential itself such as: the <a>issuer</a>,
+the public key to use, the revocation mechanism to use etc. This metadata can
+either be signed by the issuer or not, more on that later. The credential identifier


You want to avoid statements like "more on that later" in specifications as they don't give the reader a good understanding of where to go next. You should link to a specific section in the specification if you want to refer the reader to a more detailed explanation. However, the preference is to not require linking to a more detailed explanation and establish the concept fully without needing to point elsewhere.

msporny · 2018-08-28T15:02:13Z

index.html

+as well as metadata that describes properties of the credential itself such as: the <a>issuer</a>,
+the public key to use, the revocation mechanism to use etc. This metadata can
+either be signed by the issuer or not, more on that later. The credential identifier
+is never revealed to the verifier to prevent the issuer and verifier from


This is not accurate. In some cases, the credential identifier is revealed because you are operating in a non-pseudonymous mode.

msporny · 2018-08-28T15:02:30Z

index.html

+either be signed by the issuer or not, more on that later. The credential identifier
+is never revealed to the verifier to prevent the issuer and verifier from
+colluding to correlate the holder.
+A <a>verifiable credential</a> is a set of claims and meta data that are


Again, @dhh1128 -- didn't this go in?

msporny · 2018-08-28T15:03:17Z

index.html

      </p>

-      <ul>
-        <li>
-The <a>issuer</a> and the <a>verifier</a> do not need to trust the


This is an important part of the VC Data Model... we can't just remove it.

dlongley · 2018-08-28T15:22:36Z

We need to figure out what's going on between this PR and #213 ... there's a lot of overlap. Are they meant to be based on one another?

dlongley · 2018-09-04T13:48:47Z

This PR needs rebasing now that #213 has been merged.

dlongley · 2018-09-11T14:23:33Z

index.html

+express a large variety of statements. For example, a claim specifying the date of birth of a subject
+can be used to prove that its age lies in an interval or is greater or less than a some value which is
+needed in use cases like proving drinking age or teenager discount or elderly discount;
+the holder has the flexibility to use the claim in any way that is applicable to that claim:


I think the point of this statement (before the edit) was to indicate that an unbounded number of claims can be made using this model. It was not about how, for a given claim, additional statements can be proved. In fact, that is not a property of the model at all, but a property of a certain technology that can be used on top of the model (the model enables such technologies but does not provide the tech itself, it's just a model).

Therefore, we should change this section back to what it said before -- and then move these new edits just below the old text and talk about this additional powerful feature that is also compatible with (builds on top of) the model. So something like:

Additionally, selective disclosure schemes may also use claims expressed in this model to prove additional statements about those claims. For example, a claim specifying the date of birth of a subject can be used to prove that its age lies...

dlongley · 2018-09-11T14:29:13Z

index.html

-set of claims and meta data that are tamper-evident and that cryptographically
-prove who issued it.
+The credential identifier should not be revealed to the verifier if the holder
+wants to avoid coorelation. This metadata may be signed by the issuer.


coorelation => correlation

I'm not sure if this is best said this way. It suggests only one of the two anti-correlation mechanisms and may fool the reader into thinking that they won't be correlated if they merely omit a credential identifier. Perhaps:

Credential identifiers can be used for correlation. A holder that wants to help minimize correlation should consider using a selective disclosure scheme that does not reveal the credential identifier and/or a terms of use policy requiring the verifier not to correlate their information with any third parties.

It seems like this sort of statement should be in the privacy section, though.

cc: @msporny ... thoughts on where this statement should go?

burnburn · 2018-10-18T15:50:13Z

What is the status of this PR? Hard to tell from the spate of commits and outstanding reviews. A summary would be nice in case we are able to discuss at TPAC.

brentzundel · 2018-10-29T17:50:33Z

Discussed at TPAC.
General consensus for the changes.
Will be ready for review after modifying one of the images.

msporny · 2018-10-30T16:09:28Z

@msporny to review and pull in after Nov 1st.

msporny · 2018-11-01T13:13:35Z

LGTM, modulo some minor editorial nits that will be caused by other PRs. I'll clean those up in another pass. Please resolve conflicts and we'll pull this in.

msporny · 2018-11-07T15:26:14Z

I'll try to do the rebase/merge ... it'll result in this branch being closed w/o merge, but a new PR will take it's place that will merge the changes in.

brentzundel · 2018-11-07T18:42:45Z

If you've got time for a quick rebase tutorial, I'm happy to attempt it 😄
On the non-editorial view, github only says "This branch has no conflicts with the base branch"
There isn't any indication that rebasing is necessary.

msporny · 2018-11-07T19:00:10Z

If you've got time for a quick rebase tutorial, I'm happy to attempt it

The only one I know involves eating glass and walking on nails... it's always a painful process... but if you want to give it a shot, try this one:

git checkout gh-pages
git pull
git checkout anoncred-3
git rebase gh-pages

There will be a number of conflicts that you will have to merge... there may be some squashing you need to do via git rebase -i

On the non-editorial view, github only says "This branch has no conflicts with the base branch"
There isn't any indication that rebasing is necessary.

Strange... it says this for me:

This branch cannot be rebased due to conflicts
Rebasing the commits of this branch on top of the base branch cannot be performed automatically due to conflicts encountered while reapplying the individual commits from the head branch.

brentzundel · 2018-11-07T20:14:25Z

Does it need to be rebased before merging? I thought there was a "Squash and merge" option.

Signed-off-by: lovesh harchandani <lovesh.bond@gmail.com>

Signed-off-by: Brent <brent.zundel@gmail.com>

brentzundel · 2018-11-07T21:53:41Z

attempted rebasing (yum broken glass). Let me know if there is more to do.

davidlehn · 2018-11-08T18:06:36Z

That rebase left a bunch of garbage in the PR. Some of those commits should probably just be backed out and a rebase done again. All that .idea junk needs to be removed from the history. And the current diff has lots of merge conflict markers in it. Hard to tell which changes are intended. This may require a git expert to get involved.

msporny · 2018-11-09T20:00:12Z

Merged via #271 ... closing.

davidlehn reviewed Aug 21, 2018

View reviewed changes

lovesh changed the title ~~Core data model~~ Describing presentation and clarifying its relationship to a credential. Aug 22, 2018

msporny requested changes Aug 28, 2018

View reviewed changes

lovesh mentioned this pull request Aug 28, 2018

First draft of editorial changes for privacy preserving credentials #213

Merged

dlongley suggested changes Sep 11, 2018

View reviewed changes

lovesh and others added 8 commits November 7, 2018 14:37

core data model

e1bc1a1

Signed-off-by: lovesh harchandani <lovesh.bond@gmail.com>

update image

1107e39

Signed-off-by: lovesh harchandani <lovesh.bond@gmail.com>

update images

3f68fb3

Signed-off-by: lovesh harchandani <lovesh.bond@gmail.com>

adjustments in response to feedback

ab4a6fa

Signed-off-by: Brent <brent.zundel@gmail.com>

changed picture back

29f856e

Signed-off-by: Brent <brent.zundel@gmail.com>

modified credential image

2e06ef2

Signed-off-by: Brent <brent.zundel@gmail.com>

clarified minimal correlation section

dde7726

Signed-off-by: Brent <brent.zundel@gmail.com>

Modified credential and presentation images to reflect TPAC discussion

a94c46f

Signed-off-by: Brent <brent.zundel@gmail.com>

brentzundel force-pushed the anoncred-3 branch from a3f80ed to a94c46f Compare November 7, 2018 21:52

brentzundel mentioned this pull request Nov 9, 2018

Rebased 217 - Describing presentation and clarifying its relationship to a credential #271

Merged

msporny closed this Nov 9, 2018

Describing presentation and clarifying its relationship to a credential. #217

Describing presentation and clarifying its relationship to a credential. #217

Conversation

lovesh commented Aug 16, 2018 • edited by pr-preview bot

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lovesh Aug 22, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lovesh Sep 4, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlongley commented Aug 28, 2018

dlongley commented Sep 4, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burnburn commented Oct 18, 2018 • edited

brentzundel commented Oct 29, 2018

msporny commented Oct 30, 2018

msporny commented Nov 1, 2018 • edited

msporny commented Nov 7, 2018

brentzundel commented Nov 7, 2018

msporny commented Nov 7, 2018 • edited

brentzundel commented Nov 7, 2018

brentzundel commented Nov 7, 2018

davidlehn commented Nov 8, 2018

msporny commented Nov 9, 2018

lovesh commented Aug 16, 2018 •

edited by pr-preview bot

lovesh Aug 22, 2018 •

edited

lovesh Sep 4, 2018 •

edited

burnburn commented Oct 18, 2018 •

edited

msporny commented Nov 1, 2018 •

edited

msporny commented Nov 7, 2018 •

edited