Replace identifier registry with Verifiable data registry. Clarify … #214

lovesh · 2018-08-14T10:05:17Z

…that the verifiable data repositrory does not store subject identifiers or credentials but issuer identifiers, keys and some other data

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

Preview | Diff

…that the verifiable data repositrory does not store subject identifiers or credentials but issuer identifiers, keys and some other data Signed-off-by: lovesh harchandani <lovesh.bond@gmail.com>

msporny

The PR suggests that we change the "identifier registry" terminology to "verifiable data repository".

Examples of "identifier registry" include: DID Ledgers and DNS/URLs. The concept being described by the PR is the "verifiable credential repository", which the holder typically uses. The group decided a long time ago to hide this detail as it's not necessary to understand /where/ the verifaible credentials are being stored other than "by the holder".

I suggest closing this PR as I think it misunderstands the model that we are currently working with in the group.

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

lovesh · 2018-08-21T09:53:42Z

@msporny We did not intend verifiable data repository to contain credentials. It is meant to hold DIDs, public keys, schema, revocation registries and similar public data. We find the term identifier registry to be narrow

msporny · 2018-08-21T13:48:24Z

We did not intend verifiable data repository to contain credentials. It is meant to hold DIDs, public keys, schema, revocation registries and similar public data. We find the term identifier registry to be narrow

Ahhh got it, thanks; that's definitely not clear from the PR.

Perhaps we need to rename it to cryptographic material registries, which includes supporting material that are used to cryptographically verify credentials (e.g., DID Ledgers, public key repositories, cryptographic schemas, and revocation lists)? Thoughts?

msporny

We need to be careful when changing this terminology. We'll need WG approval for this as it's not an editorial change... we're expanding the scope of the registry, which is fine, but I can't just process this as editorial without running it by the group.

msporny · 2018-08-21T13:50:18Z

index.html

@@ -253,11 +253,12 @@ <h3>Ecosystem Overview</h3>
 <a>verifiable credentials</a> for processing.
 Examples of verifiers include employers, security personnel, and websites.
        </dd>
-        <dt><a>identifier registry</a></dt>
+        <dt><a>Verifiable data repository</a></dt>


This should be changed to something like "cryptographic material registry"

I think schema is not a cryptographic material, neither are identifiers like a DID, do you agree? Can we call it public data regsitry so that it is clear that it contains no holder specific data

@msporny Do you agree?

Public data registry is too vague. Schemas are cryptographic material -- they are used as input to cryptographic functions to perform calculations. Specifically, schemas enable byte streams to be created in a deterministic fashion, so yes, I would classify schemas as cryptographic material for the purposes of the VC Data Model and ecosystem.

I am re-inclining to Verifiable Data Repository. Verifiable communicates the intent, cryptographic seems like a blanket term. As an example, seed to a PRF is a cryptographic data but not something we want to put in the repository

msporny · 2018-08-21T13:50:28Z

index.html

-A role a system may perform by mediating the creation and verification of
-<a>subject</a> identifiers. Examples of identifier registries include
-corporate employee databases, government ID databases, and distributed ledgers.
+Mediates the creation and verification of <a>issuer</a> identifiers, keys and


The registry is not only for issuers, it's for subjects in general of which issuers are a subtype.

msporny · 2018-08-21T13:52:25Z

index.html

        </li>
        <li>
 The <a>subject</a> trusts the <a>issuer</a> to issue true (i.e., not false)
 <a>credentials</a> about the subject, and to revoke them quickly when
 appropriate.
        </li>
-        <li>
-The <a>holder</a> trusts the <a>repository</a> to store the


This shouldn't be removed. This is talking about the holder's 'credential repository'... not the cryptographic material registry.

Thanks, added back

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

dlongley · 2018-09-04T13:51:14Z

index.html

@@ -602,8 +603,9 @@ <h1>Trust Model</h1>
 risk assessment of the verifier.
        </li>
        <li>
-All entities trust the <a>identifier registry</a> to be incorruptible and
-to be a correct record of which identifiers belong to which <a>entities</a>.
+All entities trust the <a>Public data repository</a> to be un-corruptible and


typo un-corruptible => incorruptible ... or maybe just use tamper-evident instead like we do elsewhere?

Done, tamper-evident it is

dlongley · 2018-09-04T13:51:45Z

index.html

@@ -254,11 +254,12 @@ <h3>Ecosystem Overview</h3>
 <a>verifiable presentations</a> for processing.
 Examples of verifiers include employers, security personnel, and websites.
        </dd>
-        <dt><a>identifier registry</a></dt>
+        <dt><a>Public data repository</a></dt>


Public => public (throughout)

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

brentzundel · 2018-10-09T15:20:59Z

Can this PR move forward? @msporny has requested it be discussed by the group before it can be merged:

I can't just process this as editorial without running it by the group.

What is the next step here?

David-Chadwick · 2018-10-09T17:27:35Z

One minor comment I have is what is the difference between repository and registry?
Of the top of my head, I would say that a repository is less restrictive than a registry in that the former might allow duplication (e.g. two different entities to store the same ID), whereas the latter would not as it is registering them.
I would therefore prefer the term verifiable data registry, as @lovesh said it would be in his comment above. But the current PR text uses repository instead.

msporny · 2018-10-16T01:21:35Z

Still no significant discussion among the group. Perhaps we can discuss this at W3C TPAC 2018?

jandrieu · 2018-10-16T15:51:17Z

We use repositories for where data is stored, such as identity hubs or wallets.

Maybe there is a better choice than registries for recording the unique namespacing of identifiers, but repositories definitely conflates registries with storage locations.

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

changed repository to registry

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

change 'owned' to 'controlled'

msporny · 2018-10-26T06:54:54Z

The result of the discussion at W3C TPAC 2018 was that we pull the PR in after no more than 7 days of bike shedding on the word "schema".

msporny

Minor bike shedding changes that I hope will work for everyone.

msporny · 2018-11-01T12:48:39Z

index.html

@@ -257,10 +257,10 @@ <h3>Ecosystem Overview</h3>
 <a>verifiable presentation</a> that proves the holder possesses the required verifiable credentials with certain characteristics.
 Examples of verifiers include employers, security personnel, and websites.
        </dd>
-        <dt><a>identifier registry</a></dt>
+        <dt><a>Verifiable data registry</a></dt>


Concrete suggestion: Change to "Cryptographic Data Registry"

Reasoning: The data isn't always verifiable (e.g. federated or DHT-style systems). In almost every case, the registry does contain data that is used in cryptographic processes of one kind or another.

unless there is significant consensus for "Cryptographic Data Registry," or a lot of opposition to "Verifiable data registry" I would prefer to keep "Verifiable data registry" for now.

This would mean that a "DID Ledger" is a type of "Verifiable Data Registry"... which conflates the way "Verifiable" is used in the VC data model spec, and the general usage of the word. It doesn't feel quite right to me because some DID Ledgers, like Veres One, store data (like service descriptions, that aren't "Verifiable" in the "Verifiable Credentials" sense of the word, so it's a strange fit.

I think the bigger issue is that a federated/mirrored corporate system would also be a "Verifiable Data Registry", but some of that information is not verifiable (i.e., it is only valid because the corporation says it's valid)... but the fact that all of these systems hold cryptographic data in one form or another is the common denominator here.

Keep in mind that this started out as an "Identifier Registry" because the block had a specific purpose. We are now expanding that purpose and have to be careful to not expand too far, or pick the wrong word.

We need more input on this, perhaps on a call (because I don't think the people that may have something to say about this are paying attention to code commit comments), perhaps via a run off poll because we're bike shedding at this point and it'll go on forever w/o some finality to the name change. We had to bike shed this name early on and did an IRV poll to get finality that time. We should do this again so we can get this PR sorted quickly and into the spec.

Verifiable Data Registry is inaccurate. The credential itself contains the verifiable data.

I think this registry potentially contains a broad variety of data that is used for verification, such as service descriptions, schemas, credential definitions, DIDs, revocation information, etc.

How does the name Verification Material Registry sound? I think it reflects the scope and intent for which it will be used.

"Verification Material Registry" is probably the most accurate thing so far, so I'd be fine w/ that ... and now we're squarely in "we need to ask the WG" territory. I'll try to draft up an Instant Runoff Vote for this... We have:

Verification Material Registry

Cryptographic Data Registry

Verification Data Registry

Cryptographic Material Registry

Verifiable Data Registry (do we still want to keep this option for the vote?)

... any other contenders that folks want to put forward?

Verification material registry is fine with me as well.

I'm a little concerned that we're perhaps losing the original main intent for the registry which was to be an identifier registry. I understand that there are other registry needs as well (e.g. Sovrin credential schemas) -- and that many of them are related to verification. We want to include those, but not at the expense of others. Perhaps we can just call this system component "Registries" and then talk about what different types of registries might be out there in the prose?

What's important, IMO, is that they are seen as independent components in the ecosystem, i.e. they are not tightly coupled to the issuer, verifier, or holder, allowing for agility and greater decentralization.

msporny · 2018-11-01T12:49:41Z

index.html

        <dd>
 A role a system may perform by mediating the creation and verification of <a>issuer</a> identifiers,
-keys and other relevant data required to use verifiable credentials. Some configurations may require correlatable
+keys and other relevant data like schemas, revocation registries, etc. required to use verifiable credentials. Some configurations may require correlatable


Concrete suggestion: Change "schemas" to "data validation schemas"

Reasoning: The term "schema" is too broad and has led to confusion in the group.

terms.html

David-Chadwick · 2018-11-01T16:35:26Z

LGTM

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

Anoncred 2

msporny · 2018-11-27T03:35:43Z

There is now a document that is collecting options for an Instant Run-off Vote that starts in ~60 hours:

https://docs.google.com/document/d/1dCPGKiW9uqVd1X_Ye6BCFt4qzRRGjPNfTuYEQKIZk6k/edit#

I hope that everyone is happy with themselves, this is why we can't have nice things. 😜

brentzundel · 2018-12-07T16:52:50Z

@msporny from what I can see, there are no more merge conflicts. Let me know if there are any more thing I should resolve.

msporny · 2018-12-12T09:11:19Z

I tried to resolve the merge conflicts here, but failed miserably. Lots of merges and edits. Let me know if you get this fixed @brentzundel ... if not, a new PR would probably be easier to merge in.

dlongley · 2018-12-12T16:41:21Z

@brentzundel -- I took care of it, we're good here.

Replace identifier registry with verifiable data repository. Clarify …

ad99ea9

…that the verifiable data repositrory does not store subject identifiers or credentials but issuer identifiers, keys and some other data Signed-off-by: lovesh harchandani <lovesh.bond@gmail.com>

lovesh mentioned this pull request Aug 15, 2018

Privacy: Anonymous credentials #125

Closed

msporny requested changes Aug 20, 2018

View reviewed changes

resolve merge conflicts

5b636ac

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

msporny requested changes Aug 21, 2018

View reviewed changes

lovesh added 4 commits August 23, 2018 18:31

Merge branch 'gh-pages' into anoncred-2

4d3de55

rename Verifiable data repository to Public data repository

a19a8f6

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

add content back

4960fa0

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

expand role

9b50608

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

lovesh changed the title ~~Replace identifier registry with verifiable data repository. Clarify …~~ Replace identifier registry with Public data regsitry. Clarify … Aug 27, 2018

dlongley reviewed Sep 4, 2018

View reviewed changes

lovesh added 3 commits September 4, 2018 21:07

merge resolve conflicts

ba1bb70

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

consistent wording

2701313

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

changing back to verifiable data repo

933da47

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

lovesh changed the title ~~Replace identifier registry with Public data regsitry. Clarify …~~ Replace identifier registry with Verifiable data registry. Clarify … Sep 4, 2018

Merge branch 'gh-pages' into anoncred-2

ac4d89c

brentzundel added 2 commits October 17, 2018 14:12

changed repository to registry

070ad77

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

Merge pull request #3 from brentzundel/anoncred-2

97e4ea1

changed repository to registry

stonematt added the Discuss label Oct 18, 2018

brentzundel added 3 commits October 23, 2018 22:58

change 'owned' to 'controlled'

9fe7f2a

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

Merge pull request #7 from brentzundel/anoncred-2

994abd3

change 'owned' to 'controlled'

Merge branch 'gh-pages' of github.com:w3c/vc-data-model into anoncred-2

286c8ab

msporny requested changes Nov 1, 2018

View reviewed changes

brentzundel added 5 commits November 7, 2018 11:24

Merge branch 'gh-pages' of github.com:w3c/vc-data-model into anoncred-2

6dea696

expanded definition in terms

2358546

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

Merge pull request #11 from brentzundel/anoncred-2

6afbf39

Anoncred 2

Merge branch 'gh-pages' into anoncred-2

b2ad9cb

Merge branch 'gh-pages' into anoncred-2

e338f5a

Merge branch 'gh-pages' into anoncred-2

96ed437

Merge branch 'gh-pages' into anoncred-2

4cdb01b

dlongley merged commit bdd4d99 into w3c:gh-pages Dec 12, 2018

Replace identifier registry with Verifiable data registry. Clarify … #214

Replace identifier registry with Verifiable data registry. Clarify … #214

Conversation

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

msporny left a comment • edited

Choose a reason for hiding this comment

lovesh commented Aug 21, 2018 • edited

msporny commented Aug 21, 2018 • edited

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

msporny Aug 28, 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

lovesh Sep 4, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brentzundel commented Oct 9, 2018

David-Chadwick commented Oct 9, 2018

msporny commented Oct 16, 2018

jandrieu commented Oct 16, 2018

msporny commented Oct 26, 2018

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

msporny Nov 8, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlongley Nov 9, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

David-Chadwick commented Nov 1, 2018

msporny commented Nov 27, 2018 • edited

brentzundel commented Dec 7, 2018

msporny commented Dec 12, 2018

dlongley commented Dec 12, 2018

lovesh commented Aug 14, 2018 •

edited by pr-preview bot

msporny left a comment •

edited

lovesh commented Aug 21, 2018 •

edited

msporny commented Aug 21, 2018 •

edited

msporny Aug 28, 2018 •

edited

lovesh Sep 4, 2018 •

edited

msporny Nov 8, 2018 •

edited

dlongley Nov 9, 2018 •

edited

msporny commented Nov 27, 2018 •

edited