Re: Authorized Issuer Lists

+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>*