🚀

Voyager Identity #9

Last Edited Time
Jun 13, 2022
Created time
May 6, 2022
Participants
Created By
Type
Identity WG
Created
May 6, 2022
Property
Property 1
Attendees
  1. Mendes
  1. Ryan Gill
  1. Balazs Nemethi
  1. Andrei Taranu
  1. Mateusz Rzeszow
  1. Pion
  1. James Brennan
Resources
Meeting Primer
🚀
Voyager Identity #5 Meeting Summary
 
Agenda
  1. Introductions
 
from last meeting this is still outsanding
  • Bring in Isaac to discuss security issues
Meeting Minutes
Introductions
  • James from metagove
  • Mat from Polygon
  • Pion from Justiceproject
 
Recapping Membership Primer
  • Fernando
    • What is the next step with this work?
  • Mendes
    • recap from the previous meeting
    • introducing a scema how the flow of verification would go
    • 2-3 dao-s to implement a usecase to test the service
      • daostarone could be one potentially
    • go into exploring the implementation in IRL between the dao-s
  • proposal from last time:
    • Josh
      • In addition to the three DAO we want to service providers consuming information from each of the three DAO, and a set of users
        • Govern and Closer
          • A list of users and the DAOs they belong to
          • See the IssuerURI as part of:
  • James
    • questin:
    • 100 first users drop their eth address on twitter would work as safelist
  • Fernando:
    • the issuer (dao) would point to a trusted uri to select the service it will trust for creating safelist
  • James
    • q: job of the issuer to connect X event to ethereum wallet/address?
      • most restrictive: eth address, but it can be extended
  • F:
    • job of the issuer is to connect address to the
    • we might need proxy for the contract
      • to verify signed attestation about ownership (in case of onchain asset )
  • Andrei:
    • using twitter replies as example
    • fungibles would not represent membereship?
    • but the dao would point to an other resource that might be centralized?
    • Why is it better then using offchain service?
  • F:
    • the twitter is centralized data store usecase but most usecases will likely be onchain related
    • checking contract to check attestion allows more composable ruleset
  • James
    • it means: whitelist power for the dao
      • there could be a blacklist too
      • gives more power then safelist
  • Pion
    • what is the essence of issuer?
      • can it be a trusted member of a dao
        • or it has to be a dao member
  • B: we decided earlier that we stay at DAO level to be able to deliver an actual service
  • F:
    • if you give that power to indiviaudls in a dao then you need to get issuers be available
      • this is beyond single individual
    • having list of trusted issuers could be useful
  • There are 3 daos:
    • daostar voyager
    • daostar one
  • what the contract for each
 
Usecase exploration here
 
  • Let’s try to set up a real world usecase that might get complicated
  • what the attestation
    • this topic has been left out for definition later not as part of this process
    • first just use the first usecase to break down the IRL issues and keep extending
James
  • make is simpler for the API to produce a minimum and then each project can go beyond
  • metagov → strike team to host an API
  • contract to basically work as a REST API
A:
  • would not having the membership mechanism in the credential is basically the same as what’s already on the chain?
M
is there a mechanism for that?
A
  • dao tooling uses the contract info
M
  • the proposal is to tying attestations to an ethereum address
  • privacy question about privacy and richer metadata points
    • issue attestations to members will start to get specific
F
  • might not want to reveal all the info I have
  • I just want to reveal that I meet the requirements and not just
M
  • many eth addresses that solve for
  • web2 users might not be able to manage the complexity
  • use ZK tech to provide soverignity
  • identity wallet solves a few problems
 
James
 
Discussion on Polygon ID solution around ZK
    but claims are still bound to an address, no?
     
     
     
     
     
     
     
     
     
    🚀

    Voyager Identity #9

    Last Edited Time
    Jun 13, 2022
    Created time
    May 6, 2022
    Participants
    Created By
    Type
    Identity WG
    Created
    May 6, 2022
    Property
    Property 1
    Attendees
    1. Mendes
    1. Ryan Gill
    1. Balazs Nemethi
    1. Andrei Taranu
    1. Mateusz Rzeszow
    1. Pion
    1. James Brennan
    Resources
    Meeting Primer
    🚀
    Voyager Identity #5 Meeting Summary
     
    Agenda
    1. Introductions
     
    from last meeting this is still outsanding
    • Bring in Isaac to discuss security issues
    Meeting Minutes
    Introductions
    • James from metagove
    • Mat from Polygon
    • Pion from Justiceproject
     
    Recapping Membership Primer
    • Fernando
      • What is the next step with this work?
    • Mendes
      • recap from the previous meeting
      • introducing a scema how the flow of verification would go
      • 2-3 dao-s to implement a usecase to test the service
        • daostarone could be one potentially
      • go into exploring the implementation in IRL between the dao-s
    • proposal from last time:
      • Josh
        • In addition to the three DAO we want to service providers consuming information from each of the three DAO, and a set of users
          • Govern and Closer
            • A list of users and the DAOs they belong to
            • See the IssuerURI as part of:
    • James
      • questin:
      • 100 first users drop their eth address on twitter would work as safelist
    • Fernando:
      • the issuer (dao) would point to a trusted uri to select the service it will trust for creating safelist
    • James
      • q: job of the issuer to connect X event to ethereum wallet/address?
        • most restrictive: eth address, but it can be extended
    • F:
      • job of the issuer is to connect address to the
      • we might need proxy for the contract
        • to verify signed attestation about ownership (in case of onchain asset )
    • Andrei:
      • using twitter replies as example
      • fungibles would not represent membereship?
      • but the dao would point to an other resource that might be centralized?
      • Why is it better then using offchain service?
    • F:
      • the twitter is centralized data store usecase but most usecases will likely be onchain related
      • checking contract to check attestion allows more composable ruleset
    • James
      • it means: whitelist power for the dao
        • there could be a blacklist too
        • gives more power then safelist
    • Pion
      • what is the essence of issuer?
        • can it be a trusted member of a dao
          • or it has to be a dao member
    • B: we decided earlier that we stay at DAO level to be able to deliver an actual service
    • F:
      • if you give that power to indiviaudls in a dao then you need to get issuers be available
        • this is beyond single individual
      • having list of trusted issuers could be useful
    • There are 3 daos:
      • daostar voyager
      • daostar one
    • what the contract for each
     
    Usecase exploration here
     
    • Let’s try to set up a real world usecase that might get complicated
    • what the attestation
      • this topic has been left out for definition later not as part of this process
      • first just use the first usecase to break down the IRL issues and keep extending
    James
    • make is simpler for the API to produce a minimum and then each project can go beyond
    • metagov → strike team to host an API
    • contract to basically work as a REST API
    A:
    • would not having the membership mechanism in the credential is basically the same as what’s already on the chain?
    M
    is there a mechanism for that?
    A
    • dao tooling uses the contract info
    M
    • the proposal is to tying attestations to an ethereum address
    • privacy question about privacy and richer metadata points
      • issue attestations to members will start to get specific
    F
    • might not want to reveal all the info I have
    • I just want to reveal that I meet the requirements and not just
    M
    • many eth addresses that solve for
    • web2 users might not be able to manage the complexity
    • use ZK tech to provide soverignity
    • identity wallet solves a few problems
     
    James
     
    Discussion on Polygon ID solution around ZK
      but claims are still bound to an address, no?