Voyager Identity #8
Last Edited Time
May 3, 2022
Created time
Apr 22, 2022
Participants
Created By
Type
Created
Apr 22, 2022
Zoom Recording
Property
Property 1
Zoom recording: https://stanford.zoom.us/rec/share/8U1NoMpx1zjotYi6DhlZNqSzUyGnFZrN-MCzi6t_4g-uxq38mt_qjAF_ZB03VHs.NLDqFXsjz2BaS5oP
Attendees
- Mendes
- David Sneider
- Balazs Nemethi
- Brian Petes
- Victor Leipnik
- Cent Hosten
- Josh Tan
- Aaron
Agenda
Meeting Primer
Voyager Identity #5 Meeting Summary
ย
Agenda
- Introductions
ย
AIs
- Bring in Isaac to discuss security issues
Meeting Minutes
Introductions
- Lonis
- Founder at Dework
- Previously involved in Citidale
ย
Review of Membership as Attestation Working Paper
- Josh
- Presented at Schelling point in Amsterdam
ย
Recapping Membership Primer
- Josh
- What is the next step with this work?
- Aaron and Mendes
- Letโs try this in action
- Letโs try this with the DAO*1 group
- Should we be editing in public?
- Josh:
- Yes
- Cent:
- How should we move forward with testing this with the DAO*1 group?
- Josh
- Bring in Isaac and have this brought into the subgraph.
- Have an acitive endpoint that we can queery against
- Ask an issuer like dework or station to issue JSON-LD attestations.
- Mendes
- Releasing Closer in private beta
- Want to include a public endpoint that returns a public schema for this
- Do we want to go into any type of end point where an issuer might provide a keys/metadata for issuing their attestation?
- This is a way of considering that any one might get hacked and previous keys may not be valid anymore.
- How do we provide this endpoint and people can ensure that the attestations are not from someone else
- Issuers might need to implement an endpoint separate from the JSON-LD file where the keys are stored
- We should consult someone regarding security considerations for keys in or out of the JSON-LD blob
- Josh
- We should spec out what this looks like
- Aaron
- Letโs test this across the three working groups in DAO*1
- Voyager
- Strike Team
- DAO*1
- Mendes
- One thing that was left open from last meeting: could the issuer be on-chain? Be a DAO contract that issues attestation just by checking if they own the token
- Josh
- Talking about a case where a DAO delegates this to a Smart Contract
- Mendes:
- How do we align on an API
- Josh
- The dao issuer is emitting an API
- The DAO itself as a smart contract implementes this interface, DAO URI
- It is pointing to an offchain object
- It doesnโt matter if the contract is emetting an API, but whether it is pointing to an object with the API
- Mendes
- DAO*1 can act as an API proxy for for onchain issuers
- We will want to provide a template for issuance types
- Josh
- We are currently suggesting that DAOs implement a new interface for implementing the standards
- We are exploring the idea that a DAO can emit an event to public their URI, all on chain
- A contract interaction to emet an event.
- You could do something like a Poster
- Since we think that the DAO URI is integral to a DAO
- The event should be emitted by a contract in the contract space of the DAO
- WE will be specifying an API manager contract
- Need to implement this to manage an off-chain API
- And then implementing a factory contract (not part of standard, but for convenience)
- The factory contract will spin up a fully setup API manager contract along with an event that this is the URI over control of the API
- We chould deuplicate this work for an issuer API
- The API Manager contract might need to be itโs own standard
- 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:
ย