Re: Authorized Issuer Lists

In case someone finds this resource useful:
https://www.tse.go.cr/descarga_padron.htm

Download the national electoral register, updated to July 31, 2022
The Supreme Electoral Tribunal, with the purpose of strengthening our
democratic system, publishes the National Electoral Register monthly by
this means, the download can be done in three modalities:

complete register
Register by provinces and voting abroad
Register by cantons
Each of the above are offered in a compressed .ZIP file, which contains the
following files:

PADRON.TXT: This contains the voters duly registered on the date indicated,
the name of this file varies depending on the data that you decide to
download, whether it is a complete padron, by province or by canton, for
more details on this, please read the file readme.txt that is supplied with
each download.
DISTELEC.TXT: Includes the names of the country's electoral districts,
which allow you to effectively determine where the voter is registered.
README.TXT: Describes in detail how to interpret the information contained
in the downloaded files:
Statistical data of the Electoral Register:

By province: Word / PDF
By province and canton: Word / PDF
By province, canton and electoral district: Word / PDF




--
Eduardo Chongkan



On Tue, Aug 16, 2022 at 3:59 PM Eduardo A. Chongkan Líos <
e.chongkan@gmail.com> wrote:

> +1 to Snorre. For voting there is a special VC issued by the Authority of
> the election.
>
> I was thinking while reading the inputs from everyone during the last 2
> days. Here are my thoughts:
>
> - Anyone can be an issuer of their own VCs, like a soccer club, or any
> organization or agrupation in a neighborhood, etc. VCs can also be handled
> with NTFs envelopes and web3.
> - Users can decide what Issuers they associate to and to what Issuers they
> authorize to handle their KYC data as Data Agents. The only requisite for a
> Data Agent or Issuer to become cone, is to adhere to the VC standards and
> provide standardized endpoints for other Validators or GateKeepers to
> validate data, VCs and DIDs against. This makes it super flexible.
>
> - Issuers partner up with their respectives ecosystems to allow for
> multi-site acceptance and to establish their own use cases based on their
> own sets of VCs and DIDs.
>
> - The most important thing I need to resolve is:
>
> -- A) Data Governance and Usage Delegation. e.g. who is authorized to
> access the data and who is delegated to act as gatekeeper for the data.
> Data Agents. This is because UX is getting worse and worse when you have to
> do KYC everywhere once a year. I was thinking to use IPFS and blockchain to
> handle privacy and access and charge the requestors of the KYC data, the
> Insurance and Financial Entities for accessing it, so I could pay for the
> cost of the service and reward the data owners for the usage of their data
> to facilitate compliance by X company. Right now my KYC data is being
> requested over and over and there are countless copies of the same data
> floating around the internet.
> -- B) Needs to work seamlessly with Entities for full integration of KYC
> for AML. Individuals + Entities
> -- C) I would like to propose to invite persons from all major financial
> companies and the US Trade Agency so everyone can catch up and add up on
> time, like Stripe, Circle, Wise, Plaid, Skyflow, and SWIFT. So they can
> start aligning and we can come to a global solution for improved trade and
> commerce along with increased trust for any kind of credentials.
>
> D) I want to make the adoption faster and easier, or have the option
> myself: for public schools, a dashboard where first, they Register as
> entities with say, LEIS, and then they can Issue their own VCs to their
> students, perhaps wrapped as NTFs, with nice Certificate Templates that are
> generated on the fly. Courses Certificates, so for example Platzi or
> LinkedIn or Udemy are Issuers as long as these Certs include a DID or LEI,
> etc. that one can check for validity.
>
> e.g. E) How can I issue a Financial Statement as a VC?
>
> Stripe prints a Financial Statement that contains an ID for a blockchain
> verifiable PK. so the Requester can validate Authenticity and the
> Transaction holds the checksum, or the PDF gets wrapped in an NFT that only
> the Requested can Open, presenting their PK. ( like an ebook protected by a
> PK on web3, for certifying validity of a VC)
>
> Question: Can VCs be compared to NFTs or Wrapped? Are there any members of
> a Web3 organization in the forum?
>
> [image: image.png]
>
> Regards,
>
> --
> Eduardo Chongkan
> Founder of Attestto.com
>
>
> On Tue, Aug 16, 2022 at 5:52 AM Snorre Lothar von Gohren Edwin <
> snorre@diwala.io> wrote:
>
>> The right of vote would be dependent on KYC probably. And I guess this is
>> an ever evolving nest of new trusted layers.
>>
>> Thanks for the input on the direction i proposed.
>> But let this be its own subject and not clutter this list to much with
>> trying to solve my suggestion.
>>
>> And potentially be added to the rwot as point for discussion or further
>> discussion
>>
>> ᐧ
>>
>> On Tue, Aug 16, 2022 at 12: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>*
>>>>
>>>
>>
>> --
>>
>> *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>*
>>
>