๐Ÿš€

Voyager Identity #8

Last Edited Time
May 3, 2022
Created time
Apr 22, 2022
Participants
Created By
Type
Identity WG
Created
Apr 22, 2022
Property
Property 1
ย 
Agenda
  1. 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:
        • ย 
๐Ÿš€

Voyager Identity #8

Last Edited Time
May 3, 2022
Created time
Apr 22, 2022
Participants
Created By
Type
Identity WG
Created
Apr 22, 2022
Property
Property 1
ย 
Agenda
  1. 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:
        • ย