Re: Authorized Issuer Lists

Maybe I’m missing something 

But if the rule is that did2 can’t vote on did1 unless did2 is the subject of or mentioned in a vc issued by did1, then where is the Sybil attack vector?  Sybil can create did3, did4 and a hundred more - but they can’t vote on did1 because only did2 is referenced by vcs issued by did1

Steven Capell
Mob: 0410 437854

> On 16 Aug 2022, at 8:04 pm, Kyano Kashi <kyanokashi2@gmail.com> wrote:
> 
> 
> 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" may be relevant for this discussion. It not only discusses some non-technical matters, but also proposes Accreditation Credentials (to be issued to trusted issuers), are accompanied with “Trustworthy Credentials”, 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” 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” 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.
>>>>> 
>>>>>  
>>>>> 
>>>>> 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
>>>> 
>>>> Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter