Editorial changes: a bit of wordsmithing #10

dhh1128 · 2021-07-19T16:59:53Z

No description provided.

Signed-off-by: Daniel Hardman <[email protected]>

mitfik

Looks good, the comments we can take into consideration in separate PR if needed.

mitfik · 2021-08-02T14:26:01Z

docs/index.md


-The last of these examples deserves special comment. There is a tension between the decentralization that we want in a verifiable credential ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like--but we know that verifiers care very much about the reputation of the parties that make those attestations.
+The last of these examples deserves special comment. There is a tension between the decentralization that we want in a verifiable data ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like &mdash; but we know that verifiers care deeply about the reputation of the parties that make those attestations.


should we use instead of verifiable data -> authentic data ?
verifiable is not explicit which verification we are talking here about.

mitfik · 2021-08-02T14:30:50Z

docs/index.md


-We could say that verifiers will choose which issuers they trust. This is exactly what most practioners of VCs recommend, and it works in early pilots. However, this places a heavy burden on verifiers, over the long haul--verifiers can't afford to vet every potential issuer of credentials they might encounter. The result will be a tendency to accept credentials only from a short list of issuers, which leads back to centralization.
+We could say that verifiers will choose which issuers they trust. This is exactly what most practitioners of verifiable credentials recommend, and it works fine in early pilots. However, as the complexity of a data ecosystem grows, it doesn't scale; verifiers simply can't afford to vet every potential issuer of credentials they might encounter. (Consider a timely example. Tens of thousands of labs are now issuing COVID test results. No verifier can possibly know them all.) One obvious remedy is to accept credentials only from a short list of issuers, which leads back to centralization. Another remedy is to create a trust registry, where vetted issuers can be looked up. This introduces centralization in a different way.



"This introduces centralization in a different way"

I would suggest to talk more about federated approach or as we call it fractal governance where you decide how this federation can be build up and bridge between governance authority. This could give a feeling that on highest level you have sort of centralization (to bridge) but it does not impact local governance at all. So would not call it centralization in that case.

Signed-off-by: Daniel Hardman <[email protected]>

Daniel Hardman added 2 commits July 19, 2021 18:58

Wordsmith for clarity and better motivation

fcac1ad

Signed-off-by: Daniel Hardman <[email protected]>

Wordsmith for clarity and better motivation

5f78044

Signed-off-by: Daniel Hardman <[email protected]>

mitfik approved these changes Aug 2, 2021

View reviewed changes

Merge remote-tracking branch 'upstream/main' into editorial

8a64e40

Signed-off-by: Daniel Hardman <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editorial changes: a bit of wordsmithing #10

Editorial changes: a bit of wordsmithing #10

dhh1128 commented Jul 19, 2021

mitfik left a comment

mitfik Aug 2, 2021

mitfik Aug 2, 2021


		The last of these examples deserves special comment. There is a tension between the decentralization that we want in a verifiable credential ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like--but we know that verifiers care very much about the reputation of the parties that make those attestations.
		The last of these examples deserves special comment. There is a tension between the decentralization that we want in a verifiable data ecosystem, and the way that trust tends to centralize because knowledge and reputation are unevenly distributed. We want anyone to be able to attest to anything they like — but we know that verifiers care deeply about the reputation of the parties that make those attestations.


		We could say that verifiers will choose which issuers they trust. This is exactly what most practioners of VCs recommend, and it works in early pilots. However, this places a heavy burden on verifiers, over the long haul--verifiers can't afford to vet every potential issuer of credentials they might encounter. The result will be a tendency to accept credentials only from a short list of issuers, which leads back to centralization.
		We could say that verifiers will choose which issuers they trust. This is exactly what most practitioners of verifiable credentials recommend, and it works fine in early pilots. However, as the complexity of a data ecosystem grows, it doesn't scale; verifiers simply can't afford to vet every potential issuer of credentials they might encounter. (Consider a timely example. Tens of thousands of labs are now issuing COVID test results. No verifier can possibly know them all.) One obvious remedy is to accept credentials only from a short list of issuers, which leads back to centralization. Another remedy is to create a trust registry, where vetted issuers can be looked up. This introduces centralization in a different way.

Editorial changes: a bit of wordsmithing #10

Are you sure you want to change the base?

Editorial changes: a bit of wordsmithing #10

Conversation

dhh1128 commented Jul 19, 2021

mitfik left a comment

Choose a reason for hiding this comment

mitfik Aug 2, 2021

Choose a reason for hiding this comment

mitfik Aug 2, 2021

Choose a reason for hiding this comment