- From: Kyano Kashi <kyanokashi2@gmail.com>
- Date: Tue, 16 Aug 2022 13:04:18 +0300
- To: Steve Capell <steve.capell@gmail.com>
- Cc: Daniel Buchner <dbuchner@squareup.com>, Dmitri Zagidulin <dzagidulin@gmail.com>, "Joosten, H.J.M. (Rieks)" <rieks.joosten@tno.nl>, Manu Sporny <msporny@digitalbazaar.com>, Mike Prorock <mprorock@mesur.io>, Snorre Lothar von Gohren Edwin <snorre@diwala.io>, Tomislav Markovski <tomislav@trinsic.id>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAJQyhj5mZ=M0fA91Cbaj3CsGS3Wfm+_TzvYchYYm47uxphQcCw@mail.gmail.com>
The question is whether what you suggested is Sybil Resistant. Voting structures must be Sybil Resistant in order to be trusted in my opinion. On Tue, Aug 16, 2022 at 1:01 PM Steve Capell <steve.capell@gmail.com> wrote: > Wouldn’t the right to vote be controlled by proving you are the owner of a > DID that is mentioned in a VC? For example a commercial invoice VC issued > by DID 1 (seller) that references DID 2 (buyer) - means that the verified > owner of DID 2 can vote / rate DID 1 > > i.e. to have a say about anyone in a trust graph you need to be part of > the trust graph. Just like to rate an Amazon supplier you need to buy > something from the supplier > > Steven Capell > Mob: 0410 437854 > > On 16 Aug 2022, at 7:48 pm, Kyano Kashi <kyanokashi2@gmail.com> wrote: > > > > Snorre voting definitely makes sense in the long run. Right now it isn't > really implementable until we are able to ensure unique identity to avoid > bad actors voting using different DIDs. > > > On Tue, Aug 16, 2022 at 12:36 PM Snorre Lothar von Gohren Edwin < > snorre@diwala.io> wrote: > >> +1 to Joostens suggestion. Lets think Self Soverign Trust. Just like we >> can think mobile first and the go desktop. Lets think about the complex >> part first and then broaden the case for potential centralized registries. >> >> I also want to chime in the potential of democratic lists. This is a >> concept that is used alot in the blockchain cryptocurrency ecosystem to let >> the community vote or "rate" a set of actors, or add actors. To allow them >> to be apart of a accepted list. Not going to go into the details of what is >> happening on these lists, but it is a potential to think about. That can be >> lists hosted by IPFS and a decentralized storage, where you use your did to >> authenticate your vote or contribution. That way one has let it free to >> roam on its own. Might not be suiting for all cases, such as doctors, but >> it is worth bringing in the people as an important factor to catch those >> really hard cases of bad actors. >> ᐧ >> >> On Mon, Aug 15, 2022 at 8:57 AM Joosten, H.J.M. (Rieks) < >> rieks.joosten@tno.nl> wrote: >> >>> +1 to Steve and Kyano. >>> >>> >>> >>> The paper "Decentralized SSI Governance >>> <https://docs.google.com/document/d/1FQTxzQ9z9Tv-WA_UYyfF8AgvEfBYBWRgGvSdjsQof4s/edit#heading=h.cj0pu3kcmf2q>" >>> may be relevant for this discussion. It not only discusses some >>> non-technical matters, but also proposes Accreditation Credentials >>> <https://docs.google.com/document/d/1FQTxzQ9z9Tv-WA_UYyfF8AgvEfBYBWRgGvSdjsQof4s/edit#heading=h.hux9h6fycnah> >>> (to be issued to trusted issuers), are accompanied with “Trustworthy >>> Credentials >>> <https://docs.google.com/document/d/1FQTxzQ9z9Tv-WA_UYyfF8AgvEfBYBWRgGvSdjsQof4s/edit#heading=h.k8deowmyz3h8>”, >>> that can be proven to be issued by an accredited (trusted) issuer (without >>> a requirement that the identity of trusted issuer must be revealed). >>> >>> >>> >>> While I can see the use of trust lists, I also think they are an >>> artifact of “centralized authority >>> <https://essif-lab.github.io/framework/docs/terms/authority>” thinking: >>> they do not recognize that verifiers (relying parties) are the ones that >>> get to decide whom (not) to trust. We really should to start thinking about >>> “trust <https://essif-lab.github.io/framework/docs/terms/trust>” as >>> something that is very subjective. We need “*Self-Sovereign Trust*”, >>> i.e. every party (individuals as well as organizations) controls its own >>> trust (trust decisions), which is very much related to the RWOT >>> advance-readings paper on validation >>> <https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/validation-the-missing-link.md> >>> . >>> >>> >>> >>> Rieks >>> >>> >>> >>> -----Original Message----- >>> From: Steve Capell <steve.capell@gmail.com> >>> Sent: zondag 14 augustus 2022 23:38 >>> To: Manu Sporny <msporny@digitalbazaar.com> >>> Cc: Mike Prorock <mprorock@mesur.io>; Tomislav Markovski < >>> tomislav@trinsic.id>; Dmitri Zagidulin <dzagidulin@gmail.com>; Daniel >>> Buchner <dbuchner@squareup.com>; W3C Credentials CG < >>> public-credentials@w3.org> >>> Subject: Re: Authorized Issuer Lists >>> >>> >>> >>> Completely agree about the problem - just not the solution >>> >>> >>> >>> The question of whether a VC issuer is authorised to make the claim is a >>> concern for every VC that Is not issued by a trusted authority >>> >>> - is the issuer of that iso-9000 certificate really accredited to do so? >>> >>> - is the issuer of that animal health certificate really a registered >>> vet? >>> >>> - is the issuer of that invoice really who they say they are? >>> >>> >>> >>> One solution is to ask the authority of a list of who is authorised - but >>> >>> - for large groups it can be a fast changing list >>> >>> - for large groups the list would be huge >>> >>> - half of the uses cases would essentially be revealing private >>> information like customer lists >>> >>> - the verifier may have no relationship with the authority and no way to >>> ask for the list >>> >>> >>> >>> Isn’t a better solution to the same problem to use linked credentials ? >>> >>> - the certificate VC includes a hash link to the accreditation VC (and >>> the certificate issued DID is the same as the accreditation subject DID. >>> >>> - the animal health vc contains a hash link to the vetinarian’s current >>> qualification / professional body registration vc >>> >>> - the invoice contains a hash link to the business registration vc >>> >>> - and so on >>> >>> >>> >>> Verifiers must not only verify the presented vc but must also follow >>> linked vcs until they find a trust anchor vc >>> >>> >>> >>> There are tricky semantics around this - for example it’s not enough >>> just to verify that the subject DID of the accreditation vc is the same as >>> the issuer did of the certificate vc - because the accreditation could be >>> about something entirely different. One solution might be that any trust >>> anchor VC must enumerate the vc types thst the subject is authorised to >>> issue. >>> >>> >>> >>> Despite the challenges, I think that finding a standard solution to the >>> issuing of linked credentials and the verification of trust chains is a >>> better approach (although not mutually exclusive) than asking trust anchors >>> to issue lists. In the invoice linked to Australian business registration >>> example, that list would contain around 10 million entries and would change >>> roughly every 2 minutes >>> >>> >>> >>> Kind regards >>> >>> >>> >>> Steven Capell >>> >>> Mob: 0410 437854 >>> >>> >>> >>> > On 15 Aug 2022, at 5:34 am, Manu Sporny <msporny@digitalbazaar.com> >>> wrote: >>> >>> > >>> >>> > On Sun, Aug 14, 2022 at 3:12 PM Mike Prorock <mprorock@mesur.io> >>> wrote: >>> >>> >> Want us to write up some of the Food Safety and Agriculture use cases >>> we have? If so is that a good doc to PR against? >>> >>> > >>> >>> > Yes please, and yes. >>> >>> > >>> >>> > The Authorized Issuers List was meant to be a sharply focused VC (not >>> >>> > attempting to tackle the breadth of what "trust registries" are trying >>> >>> > to do. Though, at this point, we should be concerned about significant >>> >>> > work happening in multiple places -- ToIP, RWoT, VCWG, DIF, and ESSIF. >>> >>> > As we've all experienced over the last several years, this seems >>> >>> > almost unavoidable, so perhaps we can optimize for something each of >>> >>> > those venues needs? >>> >>> > >>> >>> > Perhaps what we should do is turn the RWoT exercise into a use cases >>> >>> > and requirements gathering/refinement exercise, perhaps with some >>> >>> > exploration wrt. what technologies/approaches already exist. Perhaps >>> >>> > the discussion of what is out of scope is almost as important as what >>> >>> > is in scope... and then we can feed that work back into at least the >>> >>> > five venues above and go from there? >>> >>> > >>> >>> > Does anyone know if ToIP, DIF, or ESSIF have a use cases and >>> >>> > requirements document for authorized issuer lists / trust registries >>> >>> > (in general)? >>> >>> > >>> >>> > -- manu >>> >>> > >>> >>> > -- >>> >>> > Manu Sporny - https://www.linkedin.com/in/manusporny/ >>> >>> > Founder/CEO - Digital Bazaar, Inc. >>> >>> > News: Digital Bazaar Announces New Case Studies (2021) >>> >>> > https://www.digitalbazaar.com/ >>> >>> > >>> >>> >>> >>> >>> >>> This message may contain information that is not intended for you. If >>> you are not the addressee or if this message was sent to you by mistake, >>> you are requested to inform the sender and delete the message. TNO accepts >>> no liability for the content of this e-mail, for the manner in which you >>> use it and for damage of any kind resulting from the risks inherent to the >>> electronic transmission of messages. >>> >>> >> >> -- >> >> *Snorre Lothar von Gohren Edwin* >> Co-Founder & CTO, Diwala >> +47 411 611 94 >> www.diwala.io >> <http://www.diwala.io/> >> *Stay on top of Diwala news on social media! **Facebook >> <https://www.facebook.com/diwalaorg>** / **LinkedIn >> <https://www.linkedin.com/company/diwala>** / **Instagram >> <https://www.instagram.com/diwala_/>** / **Twitter >> <https://twitter.com/Diwala>* >> >
Received on Tuesday, 16 August 2022 10:04:43 UTC