Atala-Prism planning | 2023-07-26

Agenda:

Reflections

AtalaPrism infra:

for mobile/ thin client
- considered an "EdgeAgent" - some functionality of "FullAgent" but not all
the "Holder" agent only
designed to not be always-online
- communicates / coordinates via always-online Mediator
used:
- not at all
- tried to use this but didn't have methods we wanted, our 1st prototype ended up only using API. This is probably guided only used APIs… and we couldn't get it working easily with the SDK
- Francisco Javier Labrador:
  
  You would use the sdks to accept, receive and store a credential, to establish new connections with PrismAgents, mediators, and also to answer to verification requests when the verifier asks to

role:
- always online message relay
- connection bridge from e.g. holder <–> issuer
used:
- did we use this?
  - we used this with the SDK to set up messaging yes
    - we used a provided mediatorDID.. don't know where or what this was
    - maybe a mediator "hosted by RootsID - a project"
  - for our prototype, we ended up not using the mediator to instead use the API … do those use a mediator under the hood

role:
- issuer
- verifier
- holder (but light version of the agent)
used:
- used API provided in our Ahau POC
in API form is:
- an always online agent
- CRUD on : connections/ offers/ credentials/ proofs/ schemas/ DIDs
assumption:
- designed to be used on a per user basis
  - can be an issuer, holder, verifier… but we don't want everyone to have access to that
  - problem?: all things are available on prism agent. But we don't want Holders to have access to other peoples DiDs/ Credentials
    - at the moment we communicate with a PrismAgent "holder" API, but we need one holder per person
    - with current setup any holder can see all held things?

we don't understand where the "keys" are stored
does the PrismAgent-as-API:
- behave as a Mediator?
- use a common Mediator?
- do the 3 apis you gave us use the same Mediator?
we don't know how to run the API ourselves yet
how to do use VCs yet
- how is the proof executed?
  - is it auto-magic sugar?
how heavy is the "light" client on mobile?

Mix:
- was confused and annoyed the SDK was not a fully functional Agent?
- we have a secure offline-first messaging + storage layer in ssb already, but were unable to extract the messages easily from the atala setup. Felt locked in
- the tools seem really tightly coupled
Ben:
- the tests helped a lot with
- some docs were good, but there were gaps which made understanding hard
- the SDK alone does not serve our Ahau use case. We expect our app users to perform multiple roles/ functions:
  - be a holder
  - be a issuer
  - be a verifier

We have a prototype
Still need to do VC presentation/proof

Project requirements:

community pilot in a production env:
- tribe can issue a credential
- another tribe / entity can verify a credential

Aim to have this done by end of October

a) with tribe for other services/ activities tribe provides
b) register with other tribes that are also using Ahau
- this is people using ahau software, are replicating with group?
c) with a 3rd party
- NOTE: only this case requires a global registry/ lookup

use of DIDs + VCs is exploratory
- can this create value for indigenous/ tribal communities?
we want to minimise the specialised infrastructure required to maintain
- Pataka setup (relay into ssb)
  - Static IP address
  - Port forwarding
  - one application
  - NOTES:
    - the pataka is a "dumb message relay" which supports known peers, there is nothing special about it (dumb in that it doesn't speak … much)
    - you can have multiple pataka
    - pataka are specific to particular communities, not global services

Use VCs to verify to someone that I am in a tribe